（一）持續整合
持續整合的基礎是版本控制、自動構建、自動測試、團隊共識。「持續交付」一般把自動測試放到自動構建中，就是和jenkins這種持續整合工具聯絡在一起，一旦版本變化觸發自動構建，則自動執行**分析、編譯、自動化的單元測試和自動測試集、執行通過的會正式提交到版本庫並部署、發布，否則回退。
這當然只是乙個理想型的過程，實際的軟體研發過程中，對於敏捷團隊要做的持續整合，必須保證頻繁提交（以前覺得每日構建已經非常nb了）、全面的自動化測試套件、較短的構建和測試過程、對依賴的開發環境和第三方庫檔案和元件進行管理。從目前電商領域等網際網路應用中，對持續交付的要求來看，持續整合已經是個必選項了。實際操作過程中，對於持續整合的基本要求就是：團隊成員必須按照一定的規則辦事，這些規則包括：
提交前必須在本地執行所有的提交測試（或者在持續整合伺服器有對應完成該項工作的分割槽） ： 建議在主幹上，首先同步最新的版本，在此基礎上來做本地測試，這要求有簡明的整合到開發環境裡的本地自動化單元測試環境。
構建失敗之後不要提交新**，一般都要求構建失敗立即解決問題
必須要測試通過，當然，這就要求有自動化測試支撐，現在一般都會在本地執行靜態**分析和單元測試，到伺服器去做冒煙測試和自動化基本業務測試
離開公司前，構建必須處於成功狀態，不行的話，應該回滾到上乙個成功狀態
時刻準備著回滾到上乙個成功狀態誰提交，誰負責（保證構建成功）
不允許將失敗的測試注釋掉為每個功能開發對應的覆蓋測試用例：不然，無法檢測到由於其他提交導致該項功能出錯
所以持續整合的基礎可以進一步具體化：
（二）配置管理
現在有很多版本控制工具支援配置管理，但管理活動不只是乙個簡單的系統。
1、管理物件有哪些？
軟體轉起來，其實很重要的東西： 測試指令碼、測試文件、配置檔案、資料檔案等
第三方開發和測試環境： 開發、測試、運維用到的軟體、工具，系統環境，第三方依賴庫檔案（庫檔案的變動帶來的問題是賊多的）
過程記錄，一般應該都資訊化系統裡面保留，不用特意做成檔案放到固定地方了： 會議記錄、問題解決記錄、管理記錄等
重要的外部互動檔案（一般都是成文的）：合同、需求規格、提交件（給外部的ppt、公告、說明書、匯報材料）、會議紀要、郵件等等
正式發布的版本（一般配置庫保留源**和構建檔案，二進位制的以基線或光碟等形式單獨儲存）
2、許可權控制和提交控制
智財權保護，避免乙個人撬走所有知識產品。
提交的管理要求可參見上面持續整合。務必規定並且培訓。例如：主幹與分支處理；提交注釋要求；時間間隔要求。
3、選擇合適的工具和管理人員。
選擇分布式還是集中式vcs。
根據團隊規模和形式，確定是兼職或專職的配置管理員來控制或審計提交過程。
整合與持續整合介紹
簡單來說，就是把開發好的 提交到系統中，就是整合。持續整合就是頻繁的 一天多次 將 整合到主幹。1 快速發現錯誤。每完成一點更新，就整合到主幹，可以快速發現錯誤，定位錯誤也比較容易。2 節省人力成本 3 加快軟體開發進度 4 實時交付 讓產品可以快速迭代，同時還能保持高質量。在整合到主幹之前，先進行...
fastlane與持續整合
如果xcode公升級到了最新版本，請執行sudo gem install fastlane，確保安裝最新版本的fastlane。fastlane會執行一些xcodebuild命令，有可能因超時而失敗，預設的timeout是10秒，retry times是4次，一般只需要把timeout延長就好了，方...
CICD 持續整合與持續交付
持續整合與持續交付是軟體開發和交付中的實踐。我們專案中一直在踐行持續整合 ci continuous integration 持續交付 cd continuous delivery 未能達到理想狀態，只能實踐一部分。這篇文章用於總結ci cd的實踐。什麼是持續整合？軟體開發中，整合是乙個很可能發生未...