4

我們希望在Jenkins生態系統的基礎上建立持續集成和持續部署流程。目前我們正在嘗試將我們所有的Jenkins構建作業(從源代碼到在測試服務器上啓動的幾個端點進程)放在一起。有三種構建/部署過程中我們的情況:詹金斯:構建作業的重要分支鏈條

  1. 大廈從C++項目(其中有些是依賴,其他都是依賴deb包;
  2. 建築圖像從Docker容器;
  3. 啓動端點中的一些進程;

enter image description here

正如你可以看到,我們面臨着相互觸發的工作重支鏈。任何上游項目的更新都必須貫穿整個工作鏈並觸發最終工作(process I)。因此,這將是很好使用某種類型的Jenkins插件,這將爲:

  • 控制的工作如此複雜的結構(我試圖用Build Pipeline Plugin,我得到的印象是,這個工具是適合「線性」作業鏈);
  • 提供乾淨的方式在作業環境之間傳遞參數。

回答

2

那麼,對於傳遞參數,你應該使用Parameterized Trigger Plugin

有關參數的多個異步傳球,你一個使用EnvInject plugin(這對各種各樣的事情是非常有用的,靈活的,考慮到你的複雜性,如果你用它來傳遞參數或沒有可能證明是有用的,無論)

至於控制,研究Workflow plugin。它允許將整個執行流程寫入其自己的Groovy腳本中,並進行細粒度控制。更多鏈接:
官方 - https://jenkins-ci.org/content/workflow-plugin-10
教程 - https://github.com/jenkinsci/workflow-plugin/blob/c15589f/TUTORIAL.md#pausing-flyweight-vs-heavyweight-executors

+0

感謝您的及時回覆!我讀過關於'Gradle'的文章。你怎麼看,這不是更適合這種情況嗎? –

+0

對Gradle沒有經驗,所以不能評論。我的印象是它只是一個構建系統,而詹金斯是整個軟件包,包含監控,通知,存檔和控制。詹金斯有插件來啓用Gradle構建步驟。 – Slav

3

正如@slav提到的,工作流插件應該能夠處理這種複雜控制流程,包括並行處理的子任務,在整個過程中的變量簡單處理(只是Groovy局部變量)和Docker support

你當然可以將這整個過程安排在一個單一的build.gradle(或Makefile就此而言)。如果您不介意在同一個Jenkins從服務器上運行所有步驟,並且不需要在構建過程中以任何特定方式與Jenkins進行交互或向Jenkins報告,那將是合適的。