持續整合已經被公認為極具價值的一項工程實踐。在初始化乙個專案時乙個重要的任務就是搭建持續整合伺服器，編寫構建指令碼。在我工作的所有專案中都引入了持續整合機制。它已經像氧氣一樣成為軟體開發過程中的一項工程活動。
《持續整合》站在理論的角度闡述了持續整合能夠解決什麼樣的問題，如何解決，需要遵循那些原則等。這本書的副標題是-軟體質量改進和風險降低之道（improving software quality and reducing risk）。副標題直指持續整合的兩個好處：提高軟體質量及降低專案風險。
當前軟體開發一直存在兩大難題：一是確定軟體的需求，即確定目標。究竟軟體要做成什麼樣子，在客戶的頭腦裡可能是個三角形，在業務分析員的頭腦中可能是個正方形，在開發者的頭腦中可能是個圓形，而最終出來的產品或多或少都會給客戶帶來「驚喜」。
二是確定目前離目標還有好遠，即確定剩餘的工作量。這個問題就是專案缺少可見性的問題。當乙個程式設計師告訴他的經理說這個功能只剩下20%的工作量時，具體指什麼那？這個20%的比例是怎麼得到的？是還要再花20%的時間？……
持續整合雖然解決不了第乙個問題，但是關於第二個問題，持續整合向我們介紹了一種增加專案可見性，提高開發效率，降低專案失敗風險的有效實踐經驗。
其實持續整合蘊含有哲學思想：分而治之。即我們通常說的 「滴水穿石，矽步千里」。
傳統瀑布方法一般將系統整合放置到開發完成後，這樣會導致一系列的問題。
引入了ci（continuos integration，即持續整合）以後，每個開發人員在提交**的時候都會自動進行構建，包括**審查、編譯、單元測試、打包、功能測試等。這樣保證了開發人員的每次提交都是安全的。打包生成的檔案隨時可以被測試人員拿去測試。如果需要給客戶演示功能，也只需從ci伺服器上直接獲取指定的打包完成的檔案即可。
ci的好處多多。
缺陷的檢測和修復變得更快，讓尋找和修改bug的工作變簡單（只修改系統一小部分，無需看太多**。由於提交後就可以得到反饋，記憶很新鮮，可以進行差異除錯。）同時過早的引入整合，使我們能更好的審視各個模組的介面是否滿足要求，減少專案中的假定。
由於ci將大量的工作給自動化了，那麼可以讓人們有時間做更多的需要動腦筋的、更**值的工作。而且通過對重要過程自動化，克服了專案中某些成員對實現改進的抵制，有利於持續整合的推進。這樣就形成了乙個良性迴圈。
對於客戶來說，可以部署的軟體是最實際的資產。而ci則可以輕鬆做到這一點。
通過對ci伺服器的監控，可以隨時了解專案的趨勢。ci上的紅色或綠色表示了當前專案的健康程度。每乙個功能的交付都經歷了單元測試或整合測試的考驗。
ci可以防止破窗綜合症，讓開發團隊一點點積累起對產品的資訊。
從上述圖中可以看出ci有四個特徵：
當開發者提交**時，就會觸發ci系統的執行。
構建指令碼繼承了審查、編譯、測試、打包、功能測試等環節，保證了產品的質量與可用性。
**變更會觸發構建,保證了ci能夠經常性的執行。
很多團隊說我們引入了持續整合，但是收到的效果並不好。比如遇到了ci持續失敗、沒人關注構建結果、沒有及時修復build等。那是因為開發團隊沒有遵循一定的原則。
持續整合是乙個實踐性很強的工程活動，其實發展到現在也遇到了一些新的挑戰。比如如何減少構建時間、怎樣實現分階段分布式構建、如何應用在有branch的**庫中、從持續整合高階到持續交付等。這本書基本沒怎麼涉及這些話題，畢竟它出版有些年頭了，但這仍不失為一本好書。
如果你理解了持續整合的好處，那麼在應用過程中就不會有牴觸心理，而且也更容易理解持續交付。
讀《程式是怎樣跑起來的》
我們開始學習程式設計最先接觸的是vb，因為vb比較容易看到成果，簡單的 就可以實現好玩的功能。我們有邏輯，並用這種高階語言表達出來時，計算機是怎樣處理的呢，計算機內部是如何儲存傳遞資料的，讀了 程式是怎樣跑起來的 感覺以前寫的 更生動了，可以在你眼前跑來跑去了。本文先來介紹cpu是什麼。cpu 處理...
ci持續整合工程師前景 持續整合CI的好處
不同的測試階段 持續整合 continuous integration，ci 是一種軟體開發實踐，即團隊開發成員經常整合他們的工作，通常每個成員每天至少整合一次，也就意味著每天可能會發生多次整合。每次整合都通過自動化的構建 包括編譯，發布，自動化測試 來驗證，從而盡早地發現整合錯誤。提高開發效率 把...
讀《計算機是怎樣跑起來的》
用了四五天時間抽空把矢澤久雄先生的 計算機是怎樣跑起來的 讀完了，接下來準備讀他的 程式是怎樣跑起來的 再讀之前先寫寫這本書的書評。說實話，這本書沒有我之前推的 網路是怎樣連線的 效果好，可能是因為我期望太高了，不過瑕不掩瑜，這本書也是值得推薦初級程式設計師閱讀的。讀過這本書，你會發現，你之前學習過...