持續整合（continuous integration）一直被認為是敏捷開發的重要實踐之一，但也有專業人士開始挑戰這種觀點。yegor bugayenko是teamed.io的聯合創始人和cto，他在最近的一篇部落格中毫不客氣地指出：「持續整合已死」。
\\ 持續整合的目的簡單而明確。當有人向**庫的主分支提交**的時候，後台的持續整合伺服器會嘗試去構建整個產品，包括編譯、單元測試、整合測試、質量分析等等。結果只有兩種：成功或失敗。如果結果失敗了，那就說明有人提交了對產品有害的**。
\\ 單從技術上講確實如此，但bugayenko認為，從整個組織的角度來講，這卻是不合時宜的。他認為最大的問題在於：
\\
\\\如果構建失敗，整個開發團隊必須停下手裡的工作，立刻修復他們的錯誤。
\
誰願意停下來呢？產品經理盯著產品早日上市，而專案經理，需要為專案的最後期限負責，被壓力趕著走的程式設計師更不會了。bugayenko描述了他所見到的真實情況：
\\
\\\我們開始忽略持續整合的狀態，不管是成功還是失敗。我們還是埋頭幹我們手裡的事情。也許明天，也許周一，等我們有空的時候再修復構建的錯誤。
\
bugayenko也嘗試了用嚴格的紀律來保證團隊及時修復錯誤，但這樣也有問題：
\\
\\\如果這樣做，你的最終結局就是得到一種「由恐懼驅動的開發模式」。程式設計師會害怕提交**到倉庫中，因為他們知道如果導致構建錯誤，他們至少要道歉。
\
嚴格的紀律只會使情況更糟糕，程式設計師更願意把**保留在本地以免犯錯，從而拖慢了開發流程。等到必須要提交的時候，一次提交很多**，如果出錯，又很難回溯。
\\ 對於這種困境，bugayenko給出了他認為可行的方案：「對主分支實行唯讀策略」。這種方式禁止開發人員直接向主分支提交任何**，取而代之的是乙個指令碼，它會在合併**前做一系列測試，確保無錯才允許提交。這樣做解決了前面的兩個問題：主分支永遠是「乾淨」的；程式設計師也不用再擔心犯錯，因為他們最多就是被指令碼拒絕提交而已。
\\感謝郭蕾對本文的審校。
\
另一種尊重
上中學的時候，有一節課印象非常深刻。老師問我們如果無意闖入乙個房間，發現房間裡有一位女士正在洗澡，這時應該怎麼辦？有同學回答就當什麼也沒看見，退出房間。還有同學回答 說聲對不起！女士。然後退出去。老師笑了笑說，還有更好的答案，那就是 對不起，先生！有一對結婚多年的夫妻，有一次出差在外的妻子有一件急事...
另一種勝利
另一種勝利 written by allen lee 剛才我的扣殺，出界了5.3厘公尺。雖然很可惜，但還是出界了，請確認下吧。幹 真是的，那些任性的傢伙！但是，到最後還只顧自己網球原則的正直笨蛋，和一定要用迴旋蛇標打中單人區的笨蛋，給我們看了場好比賽啊。龍崎 海棠和幹他們雖然輸了這場比賽，但他們堅持...
另一種table排序
click on the table header to sort in ascending order.last name first name birthday siblings smith john 7 12 1978 2johnson betty 10 15 1977 4henderson ...