持續內建(一)-為何采用持續內建

在軟體開發過程中，我們會涉及到配置管理、源碼控制、釋出計劃、審計、符合性和內建，以及建構測試和部署流程、驗收測試、依賴管理和生産環境的建立與管理，很多人認為這些與确定欲求、實作需求、寫代碼相比，這些活動并不那麼重要，它隻為是軟體開發過程很小的一部分并且不需求多大的技術投入。其實不然，恰恰相反它們會消耗大量的時間和精力，而且是成功傳遞軟體的關鍵因素。假如沒有關注這一方面帶來的潛在風險，就可能耗費大量不必要的資金，甚至導緻整個項目嚴重延期。

如果沒有持續內建，我們可能會遇到下列問題：

1. 如何将一個想法以最快的速度傳遞給使用者。

2. 如何協調開發人員、測試人員，以及建構和運維人員在一起高效地工作。

3. 在釋出當天是否遇到很多的問題，釋出過程時候需要很長的時間。

4. 是否在開發完成之後才釋出軟體，失敗後長期的加班。

5. 如何快速的擷取使用者的回報，并讓團隊人員及時的改正。

6. 生産環境是否還是采用的手工部署，還在為不同環境之間的部署煩惱。

7. 在開發過程中，應用程式在相當長的一段時間内無法運作，無法驗證每次修改的正确性。

一行代碼的改動需要花多長時間才能部署上線，處理方式是否可重複且可靠呢？從決定做某種修改到該修改結果正式上線的這段時間稱為周期時間。對任何項目而言，它都是一個極為重要的度量标準。

軟體開發的首要任務是盡早傳遞有價值的軟體并讓客戶滿意，速度是至關重要的，因為未傳遞的軟體就意味着成本。如果不能按時按量的傳遞，就會産生不必要的成本浪費。而為了更好的協調組内人員高效的工作，在整個傳遞過程中，團隊中的每一個成員都必須對每一個傳遞特性負責，無論什麼樣的修改都應該觸發回報流程，回報應該盡快發出，團隊必須接受回報，并依據它作出相應的行動。快速的傳遞使你能夠驗證那些新開發的特性或者修複的缺陷是否真的有用。

為了達到短周期、高品質的傳遞目标，釋出軟體必須自動且頻繁化。

自動化：建構、部署、測試、釋出

頻繁化：頻繁釋出，每個釋出版本之間的差異會很小，大大減少與釋出相關的風險，且容易復原，頻繁釋出也會加快回報速度。每當有人送出代碼，就對整個應用進行建構，執行全面的自動化測試，以驗證其正确性。更重要的是，如果建構或測試失敗了，開發團隊就要停下手頭的工作，立即修複它，時時刻刻都要讓正在開發的軟體一直處于可工作的狀态。

實作持續內建，你需要的：

1. 版本控制，所有涉及産品的都要加入到版本控制中，包括建構與部署腳本。

2. 自動化建構，自動化的建構整個過程，縮短周期時間（Cycle time）。

3. 持續內建系統，Jenkins， ThoughtWorks公司的Go，JeBrains的TeamCity等。

送出代碼必須遵守一下原則：

1. 檢視建構是否成功，如果失敗，停下手頭的工作和團隊中的其他人一起修複。

2. 如果建構且測試全部通過，就從版本控制庫中的代碼更新到自己的開發環境上。

3. 在自己的修改上重新建構，運作所有的測試，確定在自己機器上的代碼都是正确的且工作正常。

4. 如果本地建構成功， 再從版本建構庫中更新代碼到本地， 再做一次建構，如果成功的話，就送出本地的修改到版本庫中。

5. 在遠端持續內建伺服器上再次建構包含你的這次送出的建構結果（通常是自動的）。

6. 如果建構失敗，就停下手中的事，在自己的開發機上修複這個問題後，再重新回到步驟3.。

7. 建構成功，小慶祝一下，并開始下一項任務。

持續內建縮短從想法到商業價值實作的時間，減少時間和降低風險，增加回報，改進負責傳遞的開發、測試和運維人員之間的協作關系。