Jenkins在使用基於trunk的開發時構建

Question

我聽到很多關於基於trunk的開發的信息。我不明白如何在進行基於主幹的開發時與Jenkins持續集成。我們使用git進行組織中的版本控制。

詹金斯的工作是設置爲輪詢Git的任何變化，如果檢測到踢任何構建和一旦構建成功開始部署。

所有的開發人員都可以訪問jenkins，並且可以將構建配置爲在不同的分支上啓動。然後將此代碼部署到dev實例中進行測試。如果開發人員認爲它沒問題，那麼他們重新配置jenkins以構建主指向。這是手動的，由開發人員來完成。

有一個管道作業定期運行並用標準作業覆蓋Jenkins作業。所以，即使開發者留下了螺絲釘的配置，仍然Jenkins設法保持構建狀態。

現在我的問題在工作功能/錯誤修復分支與多個提交，CI/CD過程的最佳做法是什麼？

a）開發人員將在他們的每個提交之後指向他們的分支並將其部署到開發實例。據我所知，這是手動的，開發人員很容易忘記這一點。

b）開發人員將Jenkins構建到其分支，然後再提出Pull請求並將其部署到開發實例。如果有多個提交，則由於任何提交，構建/部署可能會失敗。這也是手動的，對於調試可能很痛苦。

c）開發人員將在本地運行構建以確保測試通過。部署是一個黑暗的藝術，將留給其他人弄清楚。拉申請後，詹金斯將運行構建，以確保所有測試通過。這是自動的。現在，如果構建/部署失敗，開發人員將會發現哪裏出了問題。

Answer 1

這聽起來像你的c）是正確的路要走，但我沒有完全掌握情況。對於基於主幹的開發，您的CI/Jenkins應該只在合併之前使用，而不是用於每次提交（即不能代替本地構建機制）。您的開發人員應該通過手動運行測試並在出現任何問題時進行調試來在本地構建和測試其代碼。

在合併時，您可以執行預合併或合併後生成運行。對於預合併，您將Jenkins配置爲針對每個拉取請求分支運行，並且如果所有測試都通過，則合併拉取請求。這個好處是配置非常簡單。缺點是構建不考慮中繼分支中的新更改，因此即使測試在pull-request分支中傳遞，中繼在合併後可能會被中斷。

對於合併後，您可以從您的主幹分支簽出工作區，從您的拉取請求分支執行「混帳合併」，然後在工作區中運行構建。只有所有測試都通過，您纔會提交併將更改推送到中繼。好處是它保證了行李箱不會被打破。缺點是你一次只能運行一個版本，所以它會減少你的合併帶寬。

您也可以同時進行預合併和後合併。樹幹可能仍然會因合併而中斷，但您可以從合併後的構建中快速捕獲並立即修復它。