新一代軟體工程的標配：持續整合
阿新 • • 發佈：2018-12-27
敏捷軟體開發從提出到現在有16年了，經過16年的考驗和沉澱，有些實踐也許已經不再使用，或者仍然存在爭議，而持續整合這個實踐愈發顯示出其突出的位置，可以預見其將成為新一代軟體工程的標準配置。
持續整合最典型場景
在程式碼提交後5分鐘之內，程式碼被編譯並測試通過，程式設計師進入到後續工作，或者程式碼被編譯並測試不通過，程式設計師在約定的15分鐘內修復了，持續整合通過，程式設計師轉入後續工作；或者15分鐘沒有修復，回滾到上個持續整合通過版本，程式設計師在自己本地環境修復，修復後再提交。
在持續交付一書中，總結了如下相關內容
持續整合的前提條件
- 頻繁提交
- 建立全面的自動化測試套件
- 保持較短的構建和測試
- 管理開發工作區
持續整合中必不可少的實踐
- 構建失敗後不要提交新程式碼
- 提交前本地執行所以的提交測試
- 等提交測試通過後再繼續工作
- 回家之前，構建必須處於成功狀態
- 時刻準備著回滾到前一個版本
- 在回滾之前要規定一個修復時間
- 不要將失敗的測試註釋掉
- 為自己導致的問題負責
- 測試驅動的開發
持續整合中推薦的實踐
- 極限程式設計開發實踐
- 若違背架構原則，就讓構建失敗
- 若測試執行變慢，就讓構建失敗
- 若有編譯警告或程式碼風格問題，就讓測試失敗