持續(xù)集成（CI）是在將代碼合并到master分支之前自動進行代碼構建和測試的實踐。這使開發(fā)人員可以及早的發(fā)現錯誤和頻繁地合并代碼，同時降低了將新錯誤引入主源代碼存儲庫的風險。

代碼運行CI之后，在實時環(huán)境中部署和運行測試很重要。從CI過渡到持續(xù)交付和部署（CD）是DevOps成熟的下一步。再次部署然后進行測試，可以將一個項目中的代碼與其他組件和服務一起進行測試，而其他組件和服務可以在其他項目中進行管理。

為什么需要驗證代碼關聯的其他組件 ？

一個很好的例子可能是微服務架構。通常，在不同的項目中管理不同的微服務-每個微服務都有自己的存儲庫和管道。不同的團隊負責不同的微服務及其管道配置也很常見。作為開發(fā)人員，您將需要確認您的代碼更改不會破壞從屬微服務的功能。因此，除了項目測試之外，您還需要在那些微服務上執(zhí)行測試。

跨項目管道

在運行項目管道時，您還希望觸發(fā)跨項目管道，該管道最終將部署并測試所有相關微服務的最新版本。為了實現此目標，您需要一種簡單，靈活和方便的方式來觸發(fā)其他管道，并將其作為項目CI的一部分。通過在CI配置文件中簡單地添加觸發(fā)作業(yè)，GitLab CI/CD提供了這種運行跨項目管道的簡便方法。

GitLab CI/CD配置文件

在GitLab CI/CD中，在每個項目的.gitlab-ci.yml文件中定義了管道及其組件作業(yè)和階段。該文件是項目存儲庫的一部分。它具有完整的版本，開發(fā)人員可以使用他們選擇的任何通用IDE對其進行編輯。他們是自助服務，因此不必要求系統(tǒng)管理員或DevOps團隊對管道配置進行更改。該.gitlab-ci.yml文件定義管道的結構和順序，并確定使用GitLab Runner（運行作業(yè)的代理）執(zhí)行哪些操作，以及在遇到特定條件（例如流程成功或失?。r做出哪些決定。

添加跨項目管道觸發(fā)作業(yè)

從GitLab 11.8開始，GitLab提供了新的CI/CD配置語法，用于觸發(fā)跨項目管道。以下代碼說明了配置bridge作業(yè)以觸發(fā)下游管道：

//job1 is a job in the upstream project
deploy:
 stage: Deploy
 script: this is my script

//job2 is a bridge job in the upstream project which triggers cross-project pipeline
Android:
 stage: Trigger-cross-projects
  trigger: mobile/android

在上面的示例中，一旦部署作業(yè)在部署階段成功完成，則將啟動Android作業(yè)。該作業(yè)的初始狀態(tài)為待定。GitLab將在mobile/android項目中創(chuàng)建一個下游管道，一旦創(chuàng)建管道，Android作業(yè)將成功。在這種情況下，mobile/android是該項目的完整路徑。

創(chuàng)建上游管道的用戶需要具有對下游項目（在這種情況下為mobile/android）的訪問權限。如果找不到下游項目，或者用戶無權在此處創(chuàng)建管道，則Android作業(yè)將被標記為失敗。

從上游管道圖瀏覽到下游

GitLab CI/CD使可視化管道配置成為可能。在下圖中，構建，測試和部署階段是上游項目的一部分。一旦部署作業(yè)成功，將并行觸發(fā)四個其他項目，您將能夠通過單擊下游作業(yè)之一來瀏覽到它們。

在下圖中，可以看到下游管道?，F在，我們可以向左滾動到上游管道，向右滾動回到下游管道，或者選擇另一個下游管道。

指定下游管道分支

可以指定下游管道將使用的分支名稱：

trigger:
     project: mobile/android
     branch: stable-11-2

使用project關鍵字指定下游項目的完整路徑。使用branch關鍵字指定分支名稱。在創(chuàng)建下游管道時，GitLab將使用當前在分支的HEAD上的提交。

將變量傳遞到下游管道

有時您可能想將變量傳遞到下游管道。您可以使用variables關鍵字來執(zhí)行此操作，就像定義常規(guī)作業(yè)時一樣。

Android:
  variable:
    ENVIRONMENT: ‘This is the variable value for the downstream pipeline’
  stage: Trigger-cross-projects
  trigger: mobile/android

ENVIRONMENT變量將傳遞到下游管道中定義的每個作業(yè)。當GitLab Runner選擇工作時，它將作為環(huán)境變量使用。

該.gitlab-ci.yml文件定義CI/CD階段的順序，要執(zhí)行的作業(yè)以及在什么條件下運行或跳過作業(yè)的執(zhí)行。在trigger該文件中添加帶有關鍵字的"bridge作業(yè)" 可用于觸發(fā)跨項目管道。我們可以將參數傳遞給下游管道中的作業(yè)，甚至可以定義下游管道將使用的分支。

管道可以是具有許多順序和并行作業(yè)的復雜結構組成，并且正如我們剛剛了解的那樣，有時它們可以觸發(fā)下游管道。為了更容易理解管道（包括其下游管道）的流程，GitLab提供了用于查看管道及其狀態(tài)的管道圖。