持續(xù)集成要求每當有人提交代碼時，就對整個應用進行構建并對其執(zhí)行全面的自動化測試集合。并且假如構建或者測試失敗，開發(fā)團隊就要立刻停下手中的工作去修復。
持續(xù)集成的目標是讓正在開發(fā)的軟件一直處于可使用狀態(tài)。

實現(xiàn)持續(xù)集成

• 準備工作——包括版本控制，自動化構建，團隊共識
  大家以同一個準則使用版本控制與自動化構建快速發(fā)現(xiàn)問題并且在出現(xiàn)問題之后立即修復，縮短解決問題的時間。
• 一個基本的持續(xù)集成系統(tǒng)
  使用持續(xù)集成的工具并進行配置而且所有人都去使用。在準備提交新代碼之前 ，要保證目前是否有構建在運行，并且加入自己更新的代碼是否能夠構建成功，如果能成功，在把自己本地的代碼提交到版本控制工具中。
  這個過程應該就是一直保持當前的軟件可用，讓版本控制工具上的代碼移植處于正確狀態(tài)。

持續(xù)集成的前提條件

• 頻繁提交
• 創(chuàng)建全面的自動化測試套件
• 保持較短的測試和構建過程
• 管理開發(fā)工作區(qū)
  前三點都在之前的章節(jié)里面介紹過，對于管理開發(fā)工作區(qū)，要管理開發(fā)環(huán)境，第三方依賴的配置管理，里面提到的冒煙測試昨天看書的時候還不知道是什么，胡老師的講解——冒煙測試來源于硬件測試，就跟買電器先試試插上會不會冒煙。用最少和最有效的方法驗證系統(tǒng)是工作正常的。僅僅是為了測試冒不冒煙煙，用某種方法證明主要路徑能夠跑通。

使用持續(xù)集成軟件

• 基本操作
• 鈴聲和口哨
  使用持續(xù)集成軟件進行直運行并將運行結果反饋給我們，也可以通過設置一些提醒的方式來告訴我們構建的狀態(tài)是否成功。

實踐

• 構建失敗后不要提交新的代碼
• 提交前在本地運行所有的提交測試，或者讓持續(xù)集成服務器完成
• 提交測試之后再繼續(xù)工作
• 回家之前，構建狀態(tài)必須是成功
• 時刻準備著回滾到前一個版本
• 在回滾之前規(guī)定一個修復時間
• 不要將失敗的測試注釋掉
• 為自己導致的問題負責
• 測試驅動開發(fā)
  既然我們要確保正在開發(fā)的軟件一直處于一個可用的狀態(tài)，那么我們就要保證每一次變更后的代碼都要能夠通過構建測試，不提交錯誤的代碼，并且在提交之前保證提交上去的代碼能夠與上一個版本的代碼能夠構建成功，這種情況下才可以提交代碼。如果構建的狀態(tài)不成功，最好在一定時間內修復好，時刻準備著回滾到上一個正確的版本，也不要把錯誤的代碼留給其他人。通過測試驅動開發(fā)，在開發(fā)新的功能或者修復缺陷時，先寫測試，該測試是該功能的可執(zhí)行規(guī)范。這些測試不僅驅動了應用程序的設計，而且能夠作為回歸測試調用（回歸測試：引入了變化之后，測試是否會導致已有功能異常。胡老師舉得例子：比如不小心摔了一跤，總要爬起來看看自己是否完好無損）。
  對于極限編程以及什么情況下應該讓構建失敗也是為了能夠讓每一個版本的代碼都能夠構建成功。

分布式團隊

使用版本控制工具并且大家按照一定的規(guī)則持續(xù)集成對分布式團隊開發(fā)項目是很有利的，但是由于一些技術問題，使用替代方法也是可以解決的，但是解決方案也不是特別理想。

分布式版本控制系統(tǒng)

使用分布式版本控制系統(tǒng)的團隊應該按照持續(xù)集成的實踐里面講到的提交代碼的方式來提交，保證每一個版本的代碼都是正確的再進行開發(fā)。使用分支的話如果忘記合并到主分支或者一段時間后再去合并，到時候就更容易產生構建失敗或者錯誤，要修復的代價也會比當時直接提交到主分支上的代價高。對于這一部分還不是特別了解。

存在的問題

明白冒煙測試和回歸測試的一些概念，但是還是不清楚應該怎么用。
對于組件的測試和驗收的測試，之前也沒有寫過，接下來再去查一些相關的知識。
對于書中講到的持續(xù)集成的工具也沒有使用過。
還有分布式管理系統(tǒng)的分支應該怎么用。