在我們的上一篇文章中，我們討論了三種不同程度的連續交付軟體。我們討論了持續整合，持續交付和持續部署。你希望將這些視為彼此之間的構建塊。它們中的每一個都依賴於正確實施和採用的前一步驟（持續整合->持續部署->持續交付）。為了開始這個視訊，讓我們回到Jez和Dave的指導，讓我們的軟體始終保持工作。在本文，我們將介紹六種我們認為對於實現持續整合（Continuous Integration ，CI）至關重要的實踐。

       在持續整合構建系統中，在每次提交時，都有一個自動觸發的構建，它自動拉程式碼，進行構建，執行所有單元測試，和其他程式碼驗證步驟，並在最後打包工件（artifact）以及構建狀態和生成一個日誌。如果測試失敗，則整個團隊的構建都會中斷。要修復構建，需要新更改執行完全相同的過程。持續整合為任何程式碼缺陷生成快速反饋迴圈，促進自動化測試的編寫，並減少返工。在進行持續整合時，我認為有六種做法很重要。

        讓我們來看看他們。第一種做法，所有構建都應該通過咖啡測試。構建應該花費比獲得一杯咖啡所花費的時間更少的時間。現在，我不是在談論這些時代潮人們的冷飲，而且我不是咖啡師，所以出於實際目的，讓我們稱之為五分鐘。構建時間越長，人們自然會等待更多的更改，這會增加您的工作進度。第二中做法，小量修改提交。尋求每次提交提交最少量的程式碼。團隊中的每個人都可以輕鬆地進行小改動。

       它還可以更容易地隔離故障。哦，是的，失敗。第三做法，不要讓構建破壞。當您使構建中斷時，您將阻止交付。我經常建議團隊聚在一起，簽訂協議，你想推遲會議或停止所有其他工作，直到修改版本為止。現在，這純粹是一個文化問題，以及如何處理破碎的構建，為您的其他交付文化奠定基調。好吧，談到文化，這將引導我們進入第四個做法。

        您希望使用基於主幹的開發流程。現在，我知道這對某些人來說實際上是一個熱門話題，但無論如何我都會去那裡。人們在開發，分支和基於主幹時使用兩種主要做法。基於主幹的意味著沒有長時間執行的分支，並且主幹（也稱為主分支）始終整合在所有開發人員的本質上。現在，所有開發人員都在使用trunk進行工作，並且每天多次提交回trunk。現在，開發人員不是保持單獨的程式碼分支，而是分支程式碼並使用功能標誌。

        我曾在基於分支和基於主幹的樣式中工作過，我強烈建議使用這種基於主幹的方法。它有助於將工作保持在正在進行的有限工作中，確保經常檢查和檢查程式碼，並減少浪費和容易出錯的返工，尤其是在您嘗試合併分支時。 DevOps報告狀態明確指出這種做法是高績效團隊的標誌。好吧，讓我們繼續介紹第五種做法，不要讓有問題的測試通過，而是修復它們

        你無法知道你是否真的可以信任這個版本。說到信任，這將帶我們介紹第六種做法，構建應返回狀態，日誌和工件。狀態應該是簡單的通過/失敗或紅色/綠色。構建日誌是執行的所有測試和執行的所有結果的記錄。應該上傳工件並使用內部版本號標記。這增加了信任，確保了可聽性以及工件的不變性。好的，這就是六種做法。希望這些可以幫助您開始持續的整合工作。