? ? ? ? ? 持續集成是一種軟件開發實踐，即團隊開發成員經常集成他們的工作，通常每個成員每天至少集成一次，也就意味著每天可能會發生多次集成。每次集成都通過自動化的構建（包括編譯，發布，自動化測試）來驗證，從而盡快地發現集成錯誤。
下面來講講我的持續集成實施方案。
持續集成總體流程說明：
1）開發人員從SVN服務器拉工單或項目分支代碼到本地，然后在本地新增功能或修改bug；
2）本地運行單元測試通過后，提交代碼到SVN服務器；
3）觸發自動編譯，編譯成功后自動執行動態單元測試；
4）動態單元測試通過，執行靜態代碼檢查及安全掃描；
5）靜態代碼檢查及安全掃描通過，將代碼發布到發布服務器；
6）獲取更新通知，調用自動化部署平臺將版本發布到持續集成環境；
7）發布成功，執行集成測試和性能測試；
8）集成測試和性能測試通過，視情況將版本發布到集成測試環境、UAT環境、灰度環境或生產環境。
9）在持續構建的整過程中，能實時查看構建進度、構建狀態、構建結果等詳細信息。
1、代碼和構建產物的配置管理：
全面的配置管理，項目的配置文件、構建腳本、數據庫腳本、部署腳本，依賴庫內容全部納入版本管理。制定有效的分支策略。目前，使用分支開發、分支發布的開發模式進行持續集成工作，目的是先豐富項目單元測試和驗收測試用例。后期逐步轉換到基于主干的開發模式。
構建產物，構建的二進制文件不推薦放到版本庫中。二進制部署包只構建一次，避免多次構建可能產生的差異。
2、環境管理
部署環境標準化。開發、測試環境要向生產環境靠攏，盡量做到類生產環境的配置，包括補丁版本，依賴軟件版本，中間件版本。同時，我們可以考慮使用容器化部署方式統一開發、測試、生產環境。
3、應用的配置管理
使用應用二進制包和配置文件分離的方式，抽離應用與環境相關的配置文件，保證二進制包代碼的一致性。后期，使用統一的配置中心(CMDB)管理維護應用的所有配置信息。
持續構建階段依賴持續集成工具jenkins，分兩階段自動完成構建。第一階段構建完成代碼的編譯及動態單元測試，第二階段構建完成靜態代碼檢查、安全測試，并發布到持續集成環境，然后執行完集成測試、性能測試等，在構建的過程中能實時查看構建進度、構建結果及測試報告等。在構建異常時，需要開發人員快速響應，及時解決，然后重新構建。如下圖所示：
持續構建流程說明：
1）開發人員從主干拉工單或項目分支；
2）每位開發人員在開發新代碼之前，只能從持續集成完全成功的新拉的分支檢出最新代碼；
3）開發新功能或修改bug；
4）運行本地測試，如果有失敗就立即修復，直到測試成功；
5）提交前將分支最新代碼取到本地合并；
6）運行本地測試，確保測試通過；
7）獲取提交令牌；
8）提交代碼到分支，由持續集成服務器再次運行測試。此時只運行動態單元測試。
9）如果執行成功，執行第二階段的構建，執行第10步操作；如果執行失敗，由代碼提交人員查找失敗原因，從第2步開始重新執行構建；
10）每晚定時進行第二階段的持續集成，調用自動化部署平臺將代碼發布到持續集成環境，然后運行靜態代碼檢查、集成測試、安全測試及性能測試用例；
11）第二階段持續集成成功后，可將分支代碼發布到集成測試環境、UAT環境、灰度環境或生產環境。
12）在整個自動構建過程中，構建出現異常，測試出現失敗
自動化測試按照用例運行快慢、對外部環境的依賴程度及業務驗證范圍等維度，將自動化用例分成多層，在自動構建的不同階段分別執行不同層的自動化用例，以保障構建的準確性及構建效率。自動化分層如下圖所示:
自動化分層說明：
1）第一層：單元測試、安全測試。用例運行快，易維護，不依賴外部環境。
2）第二層：集成測試、性能測試。用例運行較慢，依賴外部環境。
3）第三層：驗收測試。全業務線功能驗收，用例運行時間長，依賴外部環境。
自動發布即持續集成工具Jenkins調用自動化部署工具，將分支代碼自動發布到持續集成環境、集成測試環境、UAT環境、灰度環境和生產環境。在自動發布的過程中，應用依據具體的實際環境，動態生成應用配置，自動啟動應用，持續探測應用的存活，并實時生成發布報告。自動化發布流程如下圖所示：
自動發布說明：
1）采用定時發布或手動觸發的方式，調用自動化部署平臺，執行發布；
2）發布成功則執行集成\性能測試，發布失敗則終止流程，生成失敗報告；
3）集成\性能測試通過，則可調用自動化部署平臺，視具體情況，將基線版本發布到集成環境、UAT環境、灰度環境和生產環境等。測試失敗則終止流程，生成失敗報告。
持續發布方案待續。。。。。。
