如何使用Jenkins Workflow流程創建具有多個管道的複雜價值流工作流程

Question

如何在Jenkins WorkFlow中實施具有多個管道的複雜價值流？類似你可以使用Go CD：How do I do CD with Go?: Part 2: Pipelines and Value Streams。

對於分佈式系統，我希望每個開發團隊和操作團隊都從自己的交付管道開始。一項變更只需觸發進行變更的團隊的管道。它需要觸發一條新的流水線，需要從團隊的每條管線上取得最新的成功工件並從那裏繼續前進。這意味着來自其他團隊的文物不會被重建或重新測試，因爲它們沒有改變。在Fan In之後，我們可以運行一系列自動化測試來驗證分佈式系統在發生變化時的正確行爲。

在文檔中，我只能發現你可以從多個VCS中獲取數據，但是我認爲每一個變化都會被構建和測試。這是我想避免的。

如果每個交付管道都在它自己的Jenkins作業中。我如何可視化完整的管道，以及從其他管道獲取上一個成功的工件或版本的最佳方法是什麼？

Answer 1

沒有直接相當於詹金斯爲值流，並且工作流作業不在這方面不同的行爲的任何：可以具有上游的工作和與觸發器相關（在這種情況下，build步驟下游的作業，或核心ReverseBuildTrigger ），並使用（例如）Copy Artifact插件將工件傳輸到下游構建。同樣，您可以使用外部存儲庫管理器作爲「真相源」，並根據推送到存儲庫的快照定義作業觸發器。

也就是說，Workflow的目的之一是避免在大多數情況下需要複雜的作業鏈¹，因爲通常使用標準控制流操作符和局部變量來推理，調試和定製單個腳本通常更容易而不是管理一系列相互依賴的工作。如果單個流程的主要問題是您需要避免重建未修改的部分，則一種解決方案是使用類似JENKINS-30412的東西來檢查特定存儲庫檢出的更改日誌，並且如果爲空，則跳過構建步驟。我認爲在一般情況下會有更多的功能需要做出這樣的系統工作，以至於工作區被其他版本破壞或丟棄。

¹確實需要單獨工作的一種情況是，出於安全原因，參與不同項目的團隊必須無法看到彼此的來源或構建日誌。

Answer 2

假設每個開發團隊的工程項目的不同模塊上和「一個變化需要觸發只進行了更改球隊的管道」我會使用Git Submodules：

子模塊允許您將Git存儲庫作爲另一個Git存儲庫的子目錄。

一個回購協議，即成爲主模塊回購的子模塊，每個隊。這對團隊來說是透明的，因爲他們只在他們指定的回購協議中工作。

main模塊也是模塊項目的構建工具的聚合器項目。所以，你有選擇：

• 單獨構建每個回購/管道或
• 在一次建全（主）項目。

包含一個或多個構建作業的構建管道與每個團隊/回購/模塊相關聯。

的主要管道僅僅代表球隊/回購/模塊管道的起點下游作業的集合。

構建觸發器可以是手動，定時或源變化中的任何一種。

的決定，也必須做：

• 你是否版本的模塊進行單獨，使得其他模塊僅依賴於發行版本。
  • 優勢：
    • 其他依靠釋放，通常更穩定的版本。
    • 模塊可以決定他們想要使用哪個版本的依賴關係。
  • 缺點：
    • 唱片集具有用於每個模塊來製備。
    • 可能需要更長的時間才能向其他人提供最新更改。
    • 模塊必須決定他們要使用哪個版本的依賴關係。每當他們需要在新版本中添加功能時，他們必須適應它。

• 或是否使用整個項目（這是由當時的模塊繼承）一個版本：釋放項目時...-SNAPSHOT開發週期，一個發佈版本中。

  在這種情況下，如果有其他模塊是必不可少的，例如，一個核心模塊，它的成功構建也應該觸發依賴模塊的構建，以便儘可能早地識別不兼容性。

  • 優點：
    • 最新變化將立即提供給他人。
    • 只有在交付完成後纔會爲整個項目準備一份發佈。
  • 缺點：
    • 立即提供給他人的最新變化可能會引入不太穩定（快照）代碼。

---

重新「我怎麼能想象的完全流水線」

我不知道可以與目前的工作流程做任何插件。

有原本已經爲構建流創建的Build Graph View Plugin，但現在已經兩年多歲：

下游建立由DownStreamRunDeclarer擴展點進行標識。

• 默認一個使用Jenkins dependencyGraph和UpstreamCause，因此可以檢測到常見的構建鏈。
• 構建流插件有助於呈現流程執行圖
• 某些Jenkins插件稍後可能會提供專用解決方案。

（你知道，「可能」和「後」往往成爲不會和從未發展。）

還有的Build Pipeline Plugin，但它顯然也是不適合工作流程：

此插件提供上游和下游連接作業的構建管線視圖[...]

---

重新「上一次成功文物拉方式」

顯然它不是光滑Gradle：

默認情況下，搖籃沒有定義任何資源庫。

我使用Maven和存在local and remote repositories，其中後者還可以是：

[...]建立在你的公司內部文件或HTTP服務器內部的存儲庫，用於共享開發團隊和發佈之間的私人工件。

您是否考慮過使用二進制存儲庫管理器，如Artifactory或Nexus？

Answer 3

從我所看到的，人們正朝着更小，獨立的代碼交付方式發展，而不是整體部署。但顯然，不同組件之間仍存在依賴關係。例如，如果您至少有一個腳本配置了您的基礎架構，而另一個腳本配置了您的應用程序並構建並部署了該腳本，則需要確保在應用程序部署之前運行了基礎架構更新腳本。另一方面，您的基礎架構不依賴於部署應用程序代碼 - 只要理想地通過一些測試，它就可以按照自己的步調進行更新。

正如在另一篇文章中提到，你真的有兩個選項來完成這種依賴性：

1. 有一個單一的管道（工作流腳本）來自兩個回購簽出的代碼，同時使他們通過相同的管道。任何改變都需要完整的船隻管道。
2. 有兩個管道，這將允許每個人以自己的步調獨立於其他人的行程。這對於基礎結構代碼來說不是問題，但它可能適用於應用程序代碼。如果您未將基礎架構更新先發生，而是將您的應用程序代碼投入生產，則結果可能不盡如人意。

我已經開始處理Jenkins工作流了，它建立了我的流之間的依賴關係。基本上，我聲明一個流程依賴於特定的版本（在這種情況下，只是BUILD_NUM），所以在我進行生產部署之前，我確認其他管道的最後一個成功構建已經完成。我能做到這一點使用詹金斯API爲我流腳本的一部分等待該編譯或更大的成功，像這樣

import hudson.EnvVars 
import hudson.model.* 

int indepdentBuildNum = 16 

waitUntil{ 
    verifyDependentPipelineCompletion("FLDR_CM/WorkflowDepedencyTester2", indepdentBuildNum) 
} 

boolean verifyDependentPipelineCompletion(String jobName, int buildNum){ 
    def hi = jenkins.model.Jenkins.instance 
    Item dep2 = hi.getItemByFullName(jobName) 
    hi = null 
    def jobs = dep2.getAllJobs().toArray() 
    def onlyJob = jobs[0] //always 1 job...I think? 
    def targetedBuild = onlyJob.getLastSuccessfulBuild() 
    EnvVars me = targetedBuild.getCharacteristicEnvVars() 
    def es = me.entrySet() 
    int targetBuildNum = 0; 
    def vars = es.iterator() 
    while(vars.hasNext()){ 
     def envVar = vars.next() 
     if(envVar.getKey().equals("BUILD_ID")){ 
      targetBuildNum = Integer.parseInt(envVar.getValue()) 
     } 
    } 
    if (buildNum > targetBuildNum) { 
     return false 
    } 
    return true 

} 

聲明，我剛開始這個過程，所以我沒有太多真實世界的經驗呢，但是如果我有更多的相關信息會更新這個線程。任何反饋歡迎。