一、提出
整合軟體
的過程不是新問題，如果專案開發的規模比較小，
比如乙個人的專案，如果它對
外部系統
的依賴很小，那麼軟體整合不是問題，但是隨著軟體專案複雜度的增加（即使增加乙個人），就會對整合和確保
軟體元件
能夠在一起工作提出了更多的要求
-要早整合，常整合
。早整合，頻繁的整合幫助專案在早期發現專案風險和質量問題，如果到後期才發現這些問題，解決問題代價很大，很有可能導致專案延期或者專案失敗。
二、定義
大師martin fowler對持續整合是這樣定義的:持續整合是一種
軟體開發實踐
，即團隊開發成員經常整合他們的工作，
通常每個成員每天至少整合一次
，也就意味著每天可能會發生多次整合。每次整合都通過自動化的構建（包括編譯，發布，
自動化測試
)來驗證，從而盡快地發現整合錯誤。許多團隊發現這個過程可以大大減少整合的問題，讓團隊能夠更快的開發內聚的
軟體。三、價值
1、減少風險
一天中進行多次的整合，並做了相應的測試，這樣有利於檢查缺陷，了解
軟體的健康狀況，減少假定
2、減少重複過程
3、任何時間、任何地點生成可部署的軟體
持續整合可以讓您在任何時間發布可以部署的
軟體。從外界來看，這是持續整合最明顯的好處，我們可以對改進
軟體品質和減少風險說起來滔滔不絕，但對於客戶來說，可以部署的軟體產品是最實際的資產。利用持續整合，您可以經常對
源**進行一些小改動，並將這些改動和其他的**進行整合。如果出現問題，專案成員馬上就會被通知到，問題會第一時間被修復。不採用持續整合的情況下，這些問題有可能到交付前的
整合測試
的時候才發現，有可能會導致延遲發布產品，而在急於修復這些缺陷的時候又有可能引入新的缺陷，最終可能導致專案失敗。
四、常用工具
持續整合簡介
想起我剛畢業後，進入一家以軟體外包為主的外企做開發。它使用傳統的瀑布式的軟體開發流程，沒有使用任何的敏捷實踐。我每天上班開啟電腦，拿到自己的任務，然後從版本控制更新 開啟工程按下build，準備進行今天的開發任務。突然發現build失敗 通常是編譯不過 大喊一聲 誰break build啦 也沒有人...
持續整合 CI
引子 記得剛加入趨勢開始開發工作 的時候曾被告知，趨勢有一套auto build的系統，會每天夜裡自動把當天check in的 進行構建，生成qa可測試 的build。每個rd都得小心提交code，因為專案結束的時候會看auto build的失敗率。可是構建失敗總是在所難免，尤其是每次要提交cand...
持續整合簡介
一 持續整合 持續整合是一種軟體開發的實踐，即團隊開發成員經常整合他們的工作，通常每個成員每天至少整合一次，也就意味著每天可能會發生多次整合。每次整合都通過自動化的構建 包括編譯，發布，自動化測試 來驗證，從而盡快地發現整合錯誤。許多團隊發現這個過程可以大大減少整合的問題，讓團隊能夠更快的開發內聚的...