一千萬個為什麽

搜索

如何使用Jenkins執行持續集成?



我有關於使用Jenkins的持續集成的基本想法 - 基本項目設置,設置源代碼管理bit-bucket並構建項目。到目前為止,我已經完成了這項工作,並遵循相同的方法,無論何時在bit-bucket中完成任何提交,Jenkins觸發構建並獲得構建狀態。但在我的組織中,沒有專業人員清楚地告訴我們CI工具如何實際使用即時的。所以我們不知道自動化項目在CI工具方面的範圍和擴展。

有人能指導我們了解這一點,並指導我們使用Jenkins管理發布版本嗎?詹金斯管道中的某個地方也讓我困惑,它是什麽以及它為什麽用它?

我正在開發Agile,所以在完成每個sprint後,我們只需在主分支中提交代碼。我們正計劃為每個沖刺創建新的分支。在我的模糊是,我們可以創建新的分支,明智的沖刺,並創建Jenkins作為每個分支,所以在提交新的分支後,詹金斯將觸發該分支的構建。這是正確的方法?

轉載註明原文: 如何使用Jenkins執行持續集成?

一共有 2 個回答:

持續整合意味著您所說的大致如此。每當發生某些事情時,它都會自動構建並測試,並在最後顯示紅色/綠色指示燈。

連續進行部署會更進一步,每當綠燈亮起時,都會自動部署。

請註意,上面的“測試”可能意味著幾個步驟:冒煙測試(它是否會立即崩潰並燃燒),自動化單元/功能/集成測試,然後,如果您不是非常有信心,也可能是一些最終的手動測試。另外,顯然,對於CD,您的測試設置需要足夠確定,因此您可以放心部署。您也可以首先對內部測試/暫存區域執行全自動部署,然後僅在稍後進行生產部署。

對你的問題:

但在我的組織中,沒有專業人員清楚地告訴我們實時使用CI工具的實際情況。

您需要為自己弄清楚這一點,因為它非常依賴於您正在構建/部署的人員,流程和軟件。起初,只需構建工具,與他們合作,看看會發生什麽。如果一切都很出色,繼續沿著你自己擺設的道路前進;如果你遇到問題,在他們出現時解決它們。

因此,我們不知道自動化項目在CI工具方面的範圍和擴展。

更自動化,更好。自動化不僅意味著在這裏和那裏削減幾分鐘的時間(但這個因素也令人驚訝地快速支付),而且所有自動化的東西都被編入某些腳本或工具中;這意味著如果你的團隊不斷壯大,你對個人的依賴就會減少(可能會生病,超負荷或離開公司)並且規模會變得更好。

使用Jenkins管理版本?

我認為Jenkins比管理版本低一步。在“純粹的”CI/CD中,最後一個階段將不再有任何發布,因為每個提交都會直接並實時地結束生產。在頻譜的另一端,你每年有3次發布,其中每個都遲到2個月;)。每個項目都會在這個範圍內的某個地方,這是由環境決定的(並非最重要的是您的利益相關者和可用的資金 - 運行非常快速的CI/CD並不是免費的)。

詹金斯管道術語讓我困惑,它是什麽以及它為什麽用它?

“管道”只是說你承諾 - 構建 - 測試 - 部署。這只是形象地說。圖像是您將提交放入管道的一端,另一端則獲得正在運行的生產服務器。

因此,在提交新分支之後,Jenkins將觸發該分支的構建。這是正確的方法?

當然,如果你有足夠的資源,在每個分支上進行每一次測試都是值得的。它可以讓你確切地知道哪個構建打破了一切。再加上非常小的提交,這是一個非常強大的工具。

另一個有用的觸發器是不建立每個提交,但是Jenkins每隔15分鐘左右查看一次存儲庫,如果還有一個更多的新提交,則建立它。如果您的測試套件運行時間較長,並且您沒有無限數量的可定期旋轉的測試環境,則這可能更為現實。

(順便說一句,如果你對所有這些都是全新的,包括“敏捷”和分支,那麽也許你會選擇一個現有的分支策略,例如Gitflow,這樣你也不會使事情復雜化很大程度上是由於(重新)在同一時間發明太多東西。)

我們計劃為每個沖刺創建新的分支。

應該指出的是,這並不意味著持續集成,而只是瀑布偽裝成CI,也被稱為 CI劇院

您提到的每個分支都不過是一個孤島,並將其合並到主分支中可以使孤島中獲得的結果以及迄今在主分支中獲得的結果無效。

從敏捷的角度來看,你會不斷創建技術債務 - 需要將筒倉分支合並為主,重新驗證合並結果,確定並解決合並後出現的任何問題。從未知道可以量化的工作,因為您無法立即知道哪個分支提交是負責任的。

正確的做法是不拉這樣的分支,而是每個提交都應該在主分支上完成。你只有一個Jenkins設置 - 在這個主分支上,每次提交後執行驗證。沒有必要的分支合並,一旦CI執行成功完成,每個提交都可能準備好交付/部署。