軟體開發為何採用持續整合

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

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

　　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、構建成功，小慶祝一下，並開始下一項任務。

　　持續整合縮短從想法到商業價值實現的時間，減少時間和降低風險，增加反饋，改進負責交付的開發、測試和運維人員之間的協作關係。