我總是向別人強調每日構造的重要性，也總是強調要自動化－－自動化到一次雙擊，或者乙個指令碼，就能生成軟體的安裝包，甚至軟體的部署！是的，對於需要部署的軟體來說，安裝包不是終點，每日構造成功的標誌是的部署成功，並且冒煙測試通過。如果這一切任何乙個步驟出了問題，那都意味這心跳驟停！
然而，我的這種宣傳並沒有起到很好的效果，很多人認為，每日構造，就是每日生成release版本的二進位制檔案，email一下構造日誌就ok了。甚至，這種構造和email構造日誌還是人工產生的！！多麼可笑，對於程式設計師來說，這到象是裁縫光屁股開店，鞋匠光腳趕路了。在推銷員吹噓他的產品多麼偉大時，我們必須看看他是如何向自己提供「偉大」的產品的。
對任何乙個有能力的開發組織來說，構造乙個全過程的每日構系統，決不是很困難的。我仍然不是很明白，為什麼那麼多的開發者不能明白這一點？今天再次看到「持續整合」這個詞，似乎有點啟發，每日構造的「構造」意思太過於強調「產生「，也許」持續整合」是個更好的詞彙。我是不是該兩個詞同時使用，以表達我要把構造持續到部署成功和通過冒煙測試的真實意圖？有人說：語言能走多遠，我們的思想就能走多遠。然而我仍然很擔心，別人在聽到的我的建議的時候，把注意力放到整合上，有意或無意地忽略持續呢？或者只是簡單的把「持續」理解為每天都作的事情呢？
有時候，覺得很悲哀，對於每日構造這樣一件簡單而有效的機制，為什麼都需要說那麼多，而不能夠真正做好？在今天，大多數人都會使用ｖｃｓ系統，但是，正確使用的有多少？有多少人能夠在２０分鐘內，回退到任何乙個歷史版本上？多少人已經不再需要手工參與**的備份、驗證、構造、錯誤報告機制當中去？一方面，我們聲稱給別人「最有價值」的程式，另一方面，卻寫不出乙個最簡單的，為自己服務的指令碼，這難道不是諷刺嗎？
外面下著雨，天空是灰色的。軟體的天空也一樣，至少，我所看到的如此之多的地方，都是這樣的。我們一面驚訝，不屑於印度軟體的崛起，一面羨慕，嚮往於美國的軟體技術的發達，另一方面，一邊痛恨自己國家的軟體業陽痿，一面以自己痛恨的方式，寫下自己痛恨的軟體。
嗚呼哀哉！
從持續整合到持續發布
持續整合作為一種很好的軟體工程實踐被很多團隊所採用，和其他一些先進的實踐一樣，它最終的目的一定是服務於產品的。產品的價值最終體現在使用者體驗的提公升，而這個的前提就是產品的每一次更新能夠及時地傳遞給使用者，對於運維團隊來說就是更快地在生產環境中部署最新的產品，對於研發團隊來說就是更頻繁地發布可以工作...
Linux vi從入門到精通（持續更新）
命令模式 vi啟動後預設進入的是命令模式，無論何時按下esc就會馬上切換到命令模式 輸入模式 命令模式下輸入i進入輸入模式 末行模式 命令模式下輸入 進入末行模式 只說乾貨 1.在vi中查詢字串 先按esc，然後使用 string，按enter開始查詢，向下查詢n，反向查詢n 2.在vi中跳轉到指定...
C 從入門到放棄之 多重繼承 鑽石繼承 虛繼承
include using namespace std class base1 int m i class base2 typedef int m i class derived public base1,public base2 int main 1 虛繼承作用 通過虛繼承可以讓公共基類子物件在末...