介紹

構建依存關系的主題既不重要也不是次要的。 各種構建工具從不同的角度處理此主題，從而提供各種解決方案，每種解決方案都有其優點和缺點。

熟悉發行版和快照依賴項的Maven和Gradle用戶可能不了解TeamCity快照依賴項，或者認為他們與Maven相關（這是不正確的）。 熟悉工件和快照依賴關系的TeamCity用戶可能不知道，除了TeamCity提供的插件之外，添加Artifactory插件還使他們能夠使用工件并建立依賴關系。

上面提到的某些名稱似乎建立得不夠充分，而其他一些則可能需要討論其使用方式。 考慮到這一點，我決定在自己的博客文章中探索每種解決方案，并設定了提供足夠信息的目標，以便人們可以選擇最有效的方法。

第一篇文章探討了 Maven快照和發行版的依賴關系。 這是第二篇文章，其中介紹了TeamCity提供的工件和快照的依賴關系，而第三篇也是最后一部分將介紹TeamCity Artifactory插件提供的工件和構建的依賴關系。

非Maven依賴項

雖然基于Java的Maven依賴關系管理和工件存儲庫在Java中非常普遍并且分布廣泛，但是在某些情況下，您仍然可能發現它們不足或不足以滿足您的需求。 首先，您可能沒有使用Java進行開發，或者您的構建工具可能未提供與Maven存儲庫的內置集成，就像Ant （或它的Gant和NAnt衍生產品）， SCons ， Rake或MSBuild一樣 。 其次，快照Maven依賴項提供了自己的挑戰，這在上一篇博客文章中已涉及到，這使得更難確保在構建鏈中使用正確的快照依賴項。

為了解決這些情況，TeamCity提供了兩種方法來連接相關的構建配置及其結果： 工件和快照相關性。

TeamCity神器依賴項

TeamCity中工件依賴的想法非常簡單：在當前版本開始之前，下載另一版本生成的工件。 將工件下載到指定的文件夾（默認情況下為checkout目錄）之后，您的構建腳本可以使用它們來實現其目標。 您可以在TeamCity文檔中找到配置詳細信息。

自然，此方案不適用于具有自動依賴項管理的構建工具，但它與接受或期望本地路徑（相對于checkout目錄）的構建或shell腳本一起使用時效果很好。 請注意，復制不僅適用于生成的生成二進制文件，而且還適用于任何類型的二進制文件或文本文件，例如上面的屏幕截圖所示的TeamCity覆蓋率報告。

關于指定工件依賴項有一個重要的細節，即“從中獲取工件”配置，在此配置中，您應指定應從中獲取文件的構建類型。 該字段的可能值為“最后成功”，“完成”，“固定”或“標記構建”，以及構建號或“從同一鏈構建”。 盡管大多數值對于理解“上一次成功構建”是默認且普遍適用的選項來說應該是微不足道的，但“相同鏈”構建的定義與TeamCity 快照依賴關系直接相關。

TeamCity快照依賴項

想象一下一個整體的多步驟構建過程（構建，測試，打包，部署），您決定將其拆分為多個較小的構建，依次調用它們，形成執行鏈。 這樣做可以使每個步驟分別配置或觸發，并并行運行某些步驟，以加快流程速度（例如執行測試或構建獨立的組件）。 最重要的是，它使整體維護非常容易。 但是，這樣做時，即使在鏈步驟運行的同時進行了新的提交，也需要確保每個鏈步驟都使用從VCS提取的相同的一致源集。 這就是TeamCity 快照依賴項的目的：它們將多個構建配置連接到稱為執行鏈的單個執行鏈中 ，并且每個步驟都使用相同的源集 ，而與VCS更新無關。 請注意，TeamCity使用術語“快照依賴關系”可能會使熟悉Maven快照依賴關系的人們感到困惑，這是兩個不相關的概念。

快照依賴項的配置類似于工件依賴項。 您可以在TeamCity文檔中找到配置詳細信息。

一起使用工件和快照依賴項

如果適用，建議定義構建配置之間的兩種依賴關系，因為這不僅可以確保在整個鏈步驟中使用一致的源集，而且還可以確保生成的工件始終如一。 現在，上面提到的工件依賴項中的“從同一鏈構建”的定義變得很清楚，因為這是此方案中唯一有意義的選項。

從某種意義上講，您可以考慮在獲取第一個源的“快照”之后，構建鏈步驟與VCS更新隔離地運行。 鏈工件可以從相同來源重新創建，也可以通過與工件相關的鏈步驟傳遞。 這使得鏈接步驟一致，可重現并且始終是最新的（當應用于使用鏈接工件時），而使用Maven快照依賴項則無法輕松實現。

TeamCity 7.0中的構建鏈可見性

TeamCity 7.0通過為構建鏈提供新的UI，使構建鏈的步驟可見并可以重新運行，從而將構建鏈的概念提升到了一個全新的水平。 定義快照依賴關系后，新的“構建鏈”選項卡將出現在項目報告中，以可視化方式表示所有相關的構建鏈，并提供一種方法，使用原始提取的同一組資源手動重新運行任何鏈步驟。

建立鏈觸發

將構建配置與快照相關性相關聯，因此將其構建分組到構建鏈中，不僅使它們在使用的源方面更加一致，還影響將構建添加到構建隊列的方式：觸發某個鏈步驟后，默認行為是除了最初觸發的步驟之外，還添加所有前面的鏈式步驟，并保持其各自的順序。 為了更加清楚，讓我重復一遍： 觸發某些鏈配置會在構建隊列中添加之前的配置（在其左側），而不是在其后的（在其右側）配置 ，盡管乍一看似乎是違反直覺的。 想法是標記鏈執行停止的位置，這恰好是最初觸發的配置。 它成為最后的執行步驟。

要在鏈配置中發現VCS更改時觸發后續鏈步驟，您可以將帶有“快照依賴項更改觸發”選項的VCS觸發器添加到配置中，這將是最后一個執行步驟。 然后，只要更新任何前面的鏈式步驟，就會觸發此配置，從而調度整個鏈式執行。

考慮到此行為，因此，您需要確定自動觸發哪些配置以及應手動運行哪些配置。 通常，VCS觸發器可以自動觸發對外部環境沒有影響的較早的鏈式步驟，但是在人工驗證了先前的鏈式結果之后，會手動調用最終鏈式步驟（可能會修改外部系統）。 手動運行最終鏈式步驟的過程通常稱為“促進”先前完成的構建。

樣本構建鏈：編譯，測試，部署

想象一下連接到構建鏈中的三個示例構建配置： "Compile" ， "Test"和"Deploy" ： "Deploy"是依賴于"Test"的快照，快照依賴于"Compile" 。

在此示例場景中，遵循上面給出的建議，將自動觸發"Compile"和"Test"配置，而手動觸發"Deploy" 。 "Compile"配置中的VCS更改僅觸發該鏈式步驟的執行，而"Test"配置中的VCS更改則觸發"Compile"和"Test"執行（按此順序）。

將"Compile"配置添加到構建隊列后，其源時間戳記將記錄在服務器上，以用于所有后續鏈式步驟。 如果將任何鏈式步驟連接到不同的VCS根，則其源也將根據相同的時間戳拉出。

促進完成的構建

一旦自動鏈執行停止（運行"Test" ），您可以通過單擊未觸發的"Deploy"配置上相應的“運行”按鈕來繼續執行（請參見上面的構建鏈屏幕截圖）。 或者，可以通過其“構建操作”促進完成的"Test"構建，并調用依賴于快照的配置-在這種情況下為"Deploy"配置。

摘要

本文概述了TeamCity工件和快照依賴項，構建鏈，如何觸發其步驟以及如何促進完成的構建。 我希望您現在除了了解構建工具（例如Maven）提供的依賴關系之外，還應該了解其工作原理以及何時（或不適合）使用TeamCity構建依賴關系。

請參考TeamCity文檔以獲取有關此主題的更多信息：

• 依賴構建
• 建立鏈

該系列的最后一篇博客文章將揭示如何使用TeamCity Artifactory插件來實現類似于基于Maven的依賴管理的項目構建鏈的行為。 敬請關注！

參考：來自Goldman ++博客的JCG合作伙伴 Evgeny Goldin的TeamCity構建依賴項 。

翻譯自: https://www.javacodegeeks.com/2012/04/teamcity-build-dependencies.html

總結

以上是生活随笔為你收集整理的TeamCity构建依赖项的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。