IBM Cloud Docs
經典Delivery Pipeline概述

經典Delivery Pipeline概述

IBM Cloud® Continuous Delivery包括經典Delivery Pipeline以可重複的方式建置、測試和部署,而無需人工幹預。 在管線中,階段的序列會擷取輸入並執行工作(例如建置、測試及部署)。

您可以使用瀏覽器,或使用 IBM Cloud CLI Developer Tools(ibmcloud dev)指令,來同時使用 Classic 及 Tekton Delivery 管線。 您也可以使用 Tekton 管線 HTTP API 和 SDK,或使用 IBM Cloud Terraform 提供者,來使用 Tekton 交付管線。 如需 Tekton Delivery Pipeline 的相關資訊,請參閱 使用 Tekton 管線

檢視、修改或執行管線的許可權,是根據擁有管線的工具鏈的存取控制而來。 有關工具鏈存取控制的更多信息,請參閱 管理對資源組中工具鏈的存取

您可以指定 Script 在管線提供的許多工作類型中執行,這樣能讓您直接控制工作執行的內容。 這些 Script 會在 Docker 映像檔中執行,該映像檔包含許多標準開發工具,包括與 IBM Cloud 運行環境互動所需的工具。 如需標準 Docker 映像檔包含內容的相關資訊,請參閱預先安裝的資源。 如果您的工作需要標準映像檔中未提供的開發工具,或是您需要那些工具的不同版本,可以使用自訂映像檔。 如需自訂映像檔的相關資訊,請參閱使用自訂 Docker 映像檔

當管線執行 Script 時,說明工作執行所在環境定義的內容,會藉由環境變數而傳遞給 Script。 例如,作為階段輸入的儲存庫 URL、正在執行的階段及工作名稱、工作類型指定的參數等等。 若要檢視可用環境變數的清單,請參閱預先安裝的資源

您可以在管線層次以及階段層次定義內容。 管線內容會在管線中的所有階段與工作之間共用。 階段內容專屬於特定的階段,並且在該階段中的所有工作之間共用。 如需內容的相關資訊,請參閱環境內容(環境變數)

階段

建置、部署及測試程式碼時,階段會組織輸入及工作。 階段可接受來自來源控制儲存庫(SCM 儲存庫)的輸入,或來自其他階段中之建置工作的輸入。 針對 SCM 儲存庫,輸入是儲存庫中特定分支的內容;針對建置工作,輸入是工作產生的構件。 當您建立第一個階段時,輸入標籤會包含預設設定。

當階段執行時,該階段的輸入將傳遞到該階段中的每個作業。 每個工作都會得到一個全新的容器以便在其中執行。 因此,階段內的工作無法將構件傳遞給彼此。 若要在作業內傳遞工件,請將作業分為兩個階段,並使用第一階段作業的輸出作為第二階段的輸入。 任何建置工作都可以作為輸入傳遞至另一個階段中的任何其他工作。 依預設,會在 ./ 資料夾中建立輸出。 如果您不想要建置工作的輸出,請將資料夾配置成輸出,且不要將任何輸出傳送至該資料夾。

類似於您定義管線內容的方法,您也可以定義階段內容,以便用於特定階段中的所有工作。 例如,您可能會定義 TEST_URL 內容,以將 URL 傳遞給階段中的部署及測試工作。 部署工作會部署至該 URL,測試工作則會測試該 URL 上的執行中應用程式。 階段內容也會藉由使用環境變數傳遞給工作 Script。 如果在管線層次及階段層次都定義了相同的內容,會使用階段內容的值。

在階段中,每次將變更遞送給專案的 SCM 儲存庫時,依預設會自動執行建置及部署。 階段及工作會依序執行;它們讓您能進行工作的流程控制。 例如,您可以在部署階段之前放置了一個測試階段。 如果測試階段中的測試失敗,則不會執行部署階段。

Delivery Pipeline 使用公用和專用工作者節點來執行階段中的工作。 依預設,管線工作是藉由在 IBM 管理的公用共用基礎架構上,使用公用工作者節點來執行。

在某些情境下,您的 Delivery Pipeline 可能需要存取內部或內部部署資源。 在這些情況下,您可以連接及整合「Delivery Pipeline 專用工作者節點」,以在您自己的 Kubernetes 基礎架構上執行。

您可能想要更嚴格地控制特定階段。 如果您不想要每次在輸入發生變更時都執行階段,則可以停用此功能。 在輸入標籤的「階段觸發程式」區段中,按一下只在手動執行此階段時才執行工作

輸入選項卡
輸入選項卡

使用 Git 儲存庫輸入類型的階段可以使用其他階段觸發程式選項。 例如,您可以選擇針對所選擇分支上的 Git 事件自動執行工作。 當選擇此觸發程式類型時,您必須選取下列一個以上的事件類型:

  • 對選取的儲存庫分支進行推送時,當推送確定時即會觸發。
  • 開啟或編輯取回要求或合併要求時,當開啟或更新取回/合併要求時即會觸發。
  • 關閉取回要求或合併要求時,即使沒有相關聯的確定,當關閉取回/合併要求時也會觸發。

輸入選項卡觸發器
輸入選項卡觸發器

如果選取當開啟或更新取回/合併要求時勾選框,則管線的狀態會傳回至 Git 儲存庫。 當取回要求或合併要求觸發您的管線時,行內狀態檢查會顯示在頁面上。 狀態檢查會針對管線中執行的每個階段而顯示,並會提供每個階段之日誌及歷程的鏈結。 當狀態檢查執行時,它會從擱置更新為成功或失敗。 如果您的管線包含多個階段,則每一個階段都會在檢查清單中報告其狀態。

IBM 管理的 GitLab Community Edition 工具也支援此狀態回饋用於合併要求。

您也可以使用 Git 分支保護規則,根據狀態檢查的結果來限制合併。 在建立分支保護規則之後,會封鎖所有合併,直到所有需要的狀態檢查成功為止。

Bitbucket 雲端取回要求

Bitbucket Cloud 目前不支援取回要求的儲存庫參照,這是 Continuous Delivery 服務所需要的。 此特性容許使用下列格式的參照,將取回要求傳送至您要存取的儲存庫: refs/pull/123/…

您可以使用來源儲存庫 URL 來 本端提取並移出取回要求。 不過,如果來源儲存庫是專用分出的儲存庫,則 Continuous Delivery 服務沒有管理取回要求所需的存取權。 若要暫行解決此限制,您必須明確提供對管線 Script 中分出儲存庫的必要存取權。

在下列範例 Bash 管線 Script 中,兩個使用者使用 Bitbucket Cloud,且他們各自具有其主要儲存庫的專用分出 (bitbucket.org/userA/repo-forked-A 及 bitbucket.org/userB/repo-forked-B)。 該 Script 設定為當取回要求開啟事件或來自兩個分出儲存庫之一的更新事件觸發建置工作時,移出取回要求。

case "$BITBUCKET_PR_SOURCE_HOST" in       #BITBUCKET_PR_SOURCE_HOST is an environment exported by pipeline if job is triggered by a bitbucket pull request
  *userA*)                                #userA should be replaced to anything to identify a forked repo's url
    url="https://$username:$password@$BITBUCKET_PR_SOURCE_HOST"    #you need to provide username and password for repo-forked-A
    ;;
  *userB/repo-forked-B*)                  #userB/repo-forked-B should be replaced to anything to identify a forked repo's url
    url="https://$username1:password1@$BITBUCKET_PR_SOURCE_HOST"   #you need to provide username1 and password1 for repo-forked-B
    ;;
esac
git fetch $url $BITBUCKET_PR_SOURCE_BRANCH   #BITBUCKET_PR_SOURCE_BRANCH is an environment exported by pipeline if job is triggered by a bitbucket pull request
git checkout FETCH_HEAD

建置階段

建置階段指定建置器類型,以指出如何建置構件。

建置工作中可用的許多欄位,在多個建置器類型之間是共同的。

以下是可用的「建置器」類型:

建造者類型
建置器類型 說明 支援的工作類型
簡式 保存現行階段的輸入,而不進行修改,以供未來階段使用。 通常,僅當階段的輸入來自 SCM 儲存庫時,此建構器類型才有用。 管線映像檔版本: 使用提供各種內建指令的內建 Docker 映像檔在容器中執行。 若要採用這些指令的較新版本,請使用較新的映像檔版本。
ant 使用 Apache Ant 檔案來管理建置工作。 管線映像檔版本: 使用提供各種內建指令的內建 Docker 映像檔在容器中執行。 若要採用這些指令的較新版本,請使用較新的映像檔版本。

建置 Script: 每當工作執行時,在新的 Ubuntu Shell 中執行。 在 Script 欄位中,輸入儲存在專案來源控制中的 Script 或參照 Script。

工作目錄:指定腳本運行的目錄。

建立存檔目錄:指定包含要存檔以供後續階段使用的作業輸出的目錄。

啟用測試報告:選擇此核取方塊可指定建置作業執行產生 JUnit XML 格式結果檔案的測試。 「工作結果」頁面的「測試」標籤上會顯示以結果檔案為基礎的報告。 如果任何測試失敗,則作業將被標記為失敗。

啟用程式碼覆蓋率報告:選擇此核取方塊可顯示可用於程式碼覆蓋率報告的更多欄位。 您可以指定 Coverage 運行程式(例如JaCoCo,和 Cobertura)、Coverage 結果檔案的位置以及相對於工作目錄的 Coverage 結果目錄。

Container Registry 建立 docker 映像並將其上傳到IBM Cloud Container Registry。 管線映像檔版本: 使用提供各種內建指令的內建 Docker 映像檔在容器中執行。 若要採用這些指令的較新版本,請使用較新的映像檔版本。

API 金鑰: 用來提供帳戶資源許可權的 IBM Cloud API 金鑰。

Container Registry 名稱空間: 您要儲存建置映像檔的名稱空間。

Docker映像名稱:此作業建置並上傳至IBM Cloud Container Registry映像檔的名稱。

建置腳本:每當作業執行時,都會在新的Ubuntu shell 中執行。 在 Script 欄位中,輸入儲存在專案來源控制中的 Script 或參照 Script。

工作目錄:指定腳本運行的目錄。

建立存檔目錄:指定包含要存檔以供後續階段使用的作業輸出的目錄。

啟用測試報告:選擇此核取方塊可指定建置作業執行產生 JUnit XML 格式結果檔案的測試。 「工作結果」頁面的「測試」標籤上會顯示以結果檔案為基礎的報告。 如果任何測試失敗,則作業將被標記為失敗。

啟用程式碼覆蓋率報告:選擇此核取方塊可顯示可用於程式碼覆蓋率報告的更多欄位。 您可以指定 Coverage 運行程式(例如JaCoCo,和 Cobertura)、Coverage 結果檔案的位置以及相對於工作目錄的 Coverage 結果目錄。

自訂 Docker 映像檔 透過使用自訂 Docker 映像檔進行建置,並對節點版本、Java™或其他工具進行細部控制。 Docker映像名稱:此作業建置並上傳至IBM Cloud Container Registry映像檔的名稱。

建置 Script: 每當工作執行時,在新的 Ubuntu Shell 中執行。 在 Script 欄位中,輸入儲存在專案來源控制中的 Script 或參照 Script。

建立存檔目錄:指定包含要存檔以供後續階段使用的作業輸出的目錄。

啟用測試報告:選擇此核取方塊可指定建置作業執行產生 JUnit XML 格式結果檔案的測試。 「工作結果」頁面的「測試」標籤上會顯示以結果檔案為基礎的報告。 如果任何測試失敗,則作業將被標記為失敗。

啟用程式碼覆蓋率報告:選擇此核取方塊可顯示可用於程式碼覆蓋率報告的更多欄位。 您可以指定 Coverage 運行程式(例如JaCoCo,和 Cobertura)、Coverage 結果檔案的位置以及相對於工作目錄的 Coverage 結果目錄。

Gradle 使用 Gradle建置。 管線映像檔版本: 使用內建 Docker 映像檔 (提供各種內建指令) 在容器中執行。 若要採用這些指令的較新版本,請使用較新的映像檔版本。

建置 Script: 每當工作執行時,在新的 Ubuntu Shell 中執行。 在 Script 欄位中,輸入儲存在專案來源控制中的 Script 或參照 Script。

工作目錄:指定腳本運行的目錄。

建立存檔目錄- 指定包含要存檔以供後續階段使用的作業輸出的目錄。

啟用測試報告:選擇此核取方塊可指定建置作業執行產生 JUnit XML 格式結果檔案的測試。 「工作結果」頁面的「測試」標籤上會顯示以結果檔案為基礎的報告。 如果任何測試失敗,則作業將被標記為失敗。

啟用程式碼覆蓋率報告:選擇此核取方塊可顯示可用於程式碼覆蓋率報告的更多欄位。 您可以指定 Coverage 運行程式(例如JaCoCo,和 Cobertura)、Coverage 結果檔案的位置以及相對於工作目錄的 Coverage 結果目錄。

格龍特 使用 Grunt 建置。 管線映像檔版本: 使用提供各種內建指令的內建 Docker 映像檔在容器中執行。 若要採用這些指令的較新版本,請使用較新的映像檔版本。

建置 Script: 每當工作執行時,在新的 Ubuntu Shell 中執行。 在 Script 欄位中,輸入儲存在專案來源控制中的 Script 或參照 Script。

工作目錄:指定腳本運行的目錄。

建立存檔目錄:指定包含要存檔以供後續階段使用的作業輸出的目錄。

啟用測試報告:選擇此核取方塊可指定建置作業執行產生 JUnit XML 格式結果檔案的測試。 「工作結果」頁面的「測試」標籤上會顯示以結果檔案為基礎的報告。 如果任何測試失敗,則作業將被標記為失敗。

啟用程式碼覆蓋率報告:選擇此核取方塊可顯示可用於程式碼覆蓋率報告的更多欄位。 您可以指定 Coverage 運行程式(例如JaCoCo,和 Cobertura)、Coverage 結果檔案的位置以及相對於工作目錄的 Coverage 結果目錄。

Maven 使用 Apache Maven 來建置。 管線映像檔版本: 使用內建 Docker 映像檔 (提供各種內建指令) 在容器中執行。 若要採用這些指令的較新版本,請使用較新的映像檔版本。

建置 Script: 每當工作執行時,在新的 Ubuntu Shell 中執行。 在 Script 欄位中,輸入儲存在專案來源控制中的 Script 或參照 Script。

工作目錄:指定腳本運行的目錄。

建立存檔目錄:指定包含要存檔以供後續階段使用的作業輸出的目錄。

啟用測試報告:選擇此核取方塊可指定建置作業執行產生 JUnit XML 格式結果檔案的測試。 「工作結果」頁面的「測試」標籤上會顯示以結果檔案為基礎的報告。 如果任何測試失敗,則作業將被標記為失敗。

啟用程式碼覆蓋率報告:選擇此核取方塊可顯示可用於程式碼覆蓋率報告的更多欄位。 您可以指定 Coverage 運行程式(例如JaCoCo,和 Cobertura)、Coverage 結果檔案的位置以及相對於工作目錄的 Coverage 結果目錄。

npm 安裝與 Node 套件管理程式的相依關係。 管線映像檔版本: 使用內建 Docker 映像檔 (提供各種內建指令) 在容器中執行。 若要採用這些指令的較新版本,請使用較新的映像檔版本。

建置 Script: 每當工作執行時,在新的 Ubuntu Shell 中執行。 在 Script 欄位中,輸入儲存在專案來源控制中的 Script 或參照 Script。

工作目錄:指定腳本運行的目錄。

建立存檔目錄:指定包含要存檔以供後續階段使用的作業輸出的目錄。

啟用測試報告:選擇此核取方塊可指定建置作業執行產生 JUnit XML 格式結果檔案的測試。 「工作結果」頁面的「測試」標籤上會顯示以結果檔案為基礎的報告。 如果任何測試失敗,則作業將被標記為失敗。

啟用程式碼覆蓋率報告:選擇此核取方塊可顯示可用於程式碼覆蓋率報告的更多欄位。 您可以指定 Coverage 運行程式(例如JaCoCo,和 Cobertura)、Coverage 結果檔案的位置以及相對於工作目錄的 Coverage 結果目錄。

Shell Script 執行 UNIX Shell Script,例如 Bash。 管線映像檔版本: 使用內建 Docker 映像檔 (提供各種內建指令) 在容器中執行。 若要採用這些指令的較新版本,請使用較新的映像檔版本。

建置 Script: 每當工作執行時,在新的 Ubuntu Shell 中執行。 在 Script 欄位中,輸入儲存在專案來源控制中的 Script 或參照 Script。

工作目錄:指定腳本運行的目錄。

建立存檔目錄:指定包含要存檔以供後續階段使用的作業輸出的目錄。

啟用測試報告:選擇此核取方塊可指定建置作業執行產生 JUnit XML 格式結果檔案的測試。 「工作結果」頁面的「測試」標籤上會顯示以結果檔案為基礎的報告。 如果任何測試失敗,則作業將被標記為失敗。

啟用程式碼覆蓋率報告:選擇此核取方塊可顯示可用於程式碼覆蓋率報告的更多欄位。 您可以指定 Coverage 運行程式(例如JaCoCo,和 Cobertura)、Coverage 結果檔案的位置以及相對於工作目錄的 Coverage 結果目錄。

Gradle ( Artifactory、Nexus 或SonarQube ) 使用 Gradle 搭配 Nexus 或 Artifactory 儲存庫來建置及部署。 Gradle 也與 SonarQube整合。 管線映像檔版本: 使用內建 Docker 映像檔 (提供各種內建指令) 在容器中執行。 若要採用這些指令的較新版本,請使用較新的映像檔版本。

儲存庫工具整合實例: 要與此建置工作搭配使用的儲存庫工具整合實例名稱。

儲存庫工具整合類型: 要從中取得 Gradle 資訊的工具整合類型。

SonarQube 整合實例: 要與此建置工作搭配使用的 SonarQube 整合實例名稱。

建置指令: 每當工作執行時要執行的建置指令。 在 Script 欄位中,輸入儲存在專案來源控制中的 Script 或參照 Script。

工作目錄:指定腳本運行的目錄。

建立存檔目錄:指定包含要存檔以供後續階段使用的作業輸出的目錄。

Maven( Artifactory、Nexus 或SonarQube ) 使用 Maven 搭配 Nexus 或 Artifactory 儲存庫來建置及部署。 Maven 也會與 SonarQube整合。 管線映像檔版本: 使用內建 Docker 映像檔 (提供各種內建指令) 在容器中執行。 若要採用這些指令的較新版本,請使用較新的映像檔版本。

儲存庫工具整合實例: 與此建置工作搭配使用的儲存庫工具整合實例名稱。

儲存庫工具整合類型: 要從中取得 Gradle 資訊的工具整合類型。

SonarQube 整合實例: 要與此建置工作搭配使用的 SonarQube 整合實例名稱。

建置指令: 每次執行工作時要執行的建置指令。 在 Script 欄位中,輸入儲存在專案來源控制中的 Script 或參照 Script。

工作目錄:指定腳本運行的目錄。

建立存檔目錄:指定包含要存檔以供後續階段使用的作業輸出的目錄。

npm( Artifactory或 Nexus) 使用 npm 搭配 Nexus 或 Artifactory 儲存庫來建置。 管線映像檔版本: 使用內建 Docker 映像檔 (提供各種內建指令) 在容器中執行。 若要採用這些指令的較新版本,請使用較新的映像檔版本。

儲存庫工具整合實例: 要與此建置工作搭配使用的儲存庫工具整合實例名稱。

儲存庫工具整合類型: 要從中取得 Gradle 資訊的工具整合類型。

SonarQube 整合實例: 要與此建置工作搭配使用的 SonarQube 整合實例名稱。

建置指令: 每當工作執行時要執行的建置指令。 在 Script 欄位中,輸入儲存在專案來源控制中的 Script 或參照 Script。

增量 Snapshot 模組版本: 在發佈步驟的 npm 登錄中,根據 package.json 檔案的內容及現行報告 Snapshot ,在本端增量模組版本,以支援持續交付。

工作目錄:指定腳本運行的目錄。

建立存檔目錄:指定包含要存檔以供後續階段使用的作業輸出的目錄。

部署階段

部署階段指定「建置」階段的輸入。 部署階段中的工作指定部署者類型。 以下是可用的「部署者」類型:

部署者類型
部署器類型 說明 支援的工作類型
自訂 Docker 映像檔 使用自訂 Docker 映像檔進行部署,並對節點版本、Java™或其他工具進行細部控制。 管線映像檔版本: 使用提供各種內建指令的內建 Docker 映像檔在容器中執行。 若要採用這些指令的較新版本,請使用較新的映像檔版本。

API 金鑰: 用來提供帳戶資源許可權的 IBM Cloud API 金鑰。

Docker映像名稱:此作業建置並上傳至IBM Cloud Container Registry映像檔的名稱。

部署 Script: 每當工作執行時執行的部署指令。 在 Script 欄位中,輸入儲存在專案來源控制中的 Script 或參照 Script。

Kubernetes 將應用程式部署至 Kubernetes 叢集,例如在 IBM Cloud Container Service 內找到的那些叢集。 管線映像檔版本: 使用提供各種內建指令的內建 Docker 映像檔在容器中執行。 若要採用這些指令的較新版本,請使用較新的映像檔版本。

API 金鑰: 用來提供帳戶資源許可權的 IBM Cloud API 金鑰。

叢集名稱: Kubernetes 叢集的名稱; 您在其中部署 Kubernetes 元件的平台。

部署 Script: 每當工作執行時執行的部署指令。 在 Script 欄位中,輸入儲存在專案來源控制中的 Script 或參照 Script。

測試階段

測試階段指定測試配置。 測試階段的作業指定測試器類型。 可使用以下測試儀類型:

測試儀類型
測試程式類型 說明 支援的工作類型
簡式 啟動 Shell 指令,以使用選用的測試報告來執行自動化測試。 管線映像檔版本: 未使用。

測試 Script: 每當工作執行時要執行的測試指令。 在 Script 欄位中,輸入儲存在專案來源控制中的 Script 或參照 Script。

工作目錄: 執行測試 Script 的目錄。

啟用測試報告: 未使用。

啟用程式碼涵蓋面報告: 未使用。

自訂 Docker 映像檔 使用自訂 Docker 映像檔,並對節點、Java™或其他工具版本進行細部控制,以進行測試。 Docker 映像檔名稱: 用來執行工作的 Docker 映像檔名稱。 若要確保您的工作在全新環境定義中執行,請在 Docker 儲存器中執行它們。

測試 Script: 每當工作執行時要執行的測試指令。 在 Script 欄位中,輸入儲存在專案來源控制中的 Script 或參照 Script。

工作目錄: 執行測試 Script 的目錄。

啟用測試報告: 未使用。

啟用程式碼涵蓋面報告: 未使用。

Vulnerability Advisor 針對指定的映像檔執行相符性及漏洞檢查,並顯示結果。 如果發現任何問題,此階段將失敗。 管線映像檔版本: 使用提供各種內建指令的內建 Docker 映像檔在容器中執行。 若要採用這些指令的較新版本,請使用較新的映像檔版本。

API 金鑰: 用來提供帳戶資源許可權的 IBM Cloud API 金鑰。

Container Registry 名稱空間: 儲存建置映像檔的名稱空間。

Docker 映像檔名稱: 用來執行工作的 Docker 映像檔名稱。 若要確保您的工作在全新環境定義中執行,請在 Docker 儲存器中執行它們。

Docker映像標籤:顯示在IBM Cloud Container Registry中的Docker映像的標籤。

測試 Script: 每當工作執行時要執行的測試指令。 在 Script 欄位中,輸入儲存在專案來源控制中的 Script 或參照 Script。

工作目錄: 執行測試 Script 的目錄。

啟用測試報告: 未使用。

啟用程式碼涵蓋面報告: 未使用。

Sauce Labs 使用 Sauce Labs 執行JavaScript, Node或Java™測試。 管線映像檔版本: 使用提供各種內建指令的內建 Docker 映像檔在容器中執行。 若要採用這些指令的較新版本,請使用較新的映像檔版本。

服務實例: 選取配置實例或建立配置實例。

已淘汰的工作類型

不建議使用多種作業類型,例如IBM Globalization Pipeline Build 作業、Space Shell Test 作業和DevOps Insights Gate Test 作業。 雖然這些工作類型已淘汰,但您仍可以在使用者介面中載入它們,並具有工作類型已淘汰的指示器。 或者,您的工作可能會回復至另一個仍受支援的工作類型,並發出警告通知。

如果您需要使用來自已淘汰工作類型的配置,請使用下列其中一種方法來存取管線配置。

  • 使用 IBM Cloud Devtool:

    ic dev pipeline-get 7325f511-492a-4c35-a388-5e499e65d6bb -output JSON

  • 使用Delivery Pipeline API:

    curl --location --request GET 'https://devops-api.us-south.devops.cloud.ibm.com/v1/pipeline/pipelines/7325f511-492a-4c35-a388-5e499e65d6bb/stages' \
    --header 'Authorization: Bearer <IAM Bearer token>
    
  • 從 Delivery Pipeline 使用者介面的 網路 標籤中,依管線 ID 過濾以尋找包含已淘汰工作類型資料的管線。

API 金鑰

一些標準管道作業使用IBM Cloud API 金鑰來存取服務,例如部署到Kubernetes。 IBM Cloud Identity and Access Management (IAM) 服務提供兩種類型的 API 金鑰:

  • 使用者 API 金鑰:這些 API 金鑰提供對使用者有權存取的所有服務和資源的完整存取權。
  • 服務 API 金鑰:可以配置服務 API 金鑰,以提供對各種服務和資源的特定存取權。

部分服務無法使用服務 ID API 金鑰。 在此類情況下,管線使用者介面會提示您指定使用者 API 金鑰。

由於管線工作執行的使用者建立的 Script 可能以任意方式使用服務 API 金鑰,因此管線無法確定要套用於特定金鑰的限制集。 在此類情況下,如果要求管線建立 API 金鑰,則它會建立使用者 API 金鑰。 若要保持高度安全,請改為使用其存取權制為只能存取您在 Script 中需要的服務和資源的服務 API 金鑰。 在這種情況下,您必須自行建立 API 金鑰。 如需建立 API 金鑰的相關資訊,請參閱 IBM Cloud API 金鑰

工作

工作是階段內的執行單位。 一個階段可以包含多個工作,並且會循序執行階段中的工作。 根據預設值,如果工作失敗,則不會執行階段中的後續工作。

在一個階段內建置和測試作業
在一個階段內建置和測試作業

工作是在為每一個管線執行所建立之 Docker 容器內的不同工作目錄中執行。 執行工作之前,會將在階段層次所定義的輸入移入其工作目錄中。 例如,您可以具有包含測試工作及部署工作的階段。 如果您將相依關係安裝在某個工作上,則另一個工作無法使用這些相依關係。 不過,如果您在階段的輸入中提供相依關係,則這兩個工作都可以使用這些相依關係。

簡單類型的建置工作除外,當您配置工作時,可以納入含有建置、測試或部署指令的 UNIX Shell Script。 因為工作是在特定容器中執行,所以某個工作的動作無法影響其他工作的執行環境,即使那些工作是相同階段的一部分也是一樣。

範例建置和部署腳本可以在 https://github.com/open-toolchain/commons中找到。

此外,管線工作只能以 sudo 身分執行下列指令:

  • /usr/sbin/service
  • /usr/bin/apt-get
  • /usr/bin/apt-key
  • /usr/bin/dpkg
  • /usr/bin/add-apt-repository
  • /opt/IBM/node-v0.10.40-linux-x64/npm
  • /opt/IBM/node-v0.12.7-linux-x64/npm
  • /opt/IBM/node-v4.2.2-linux-x64/npm
  • /usr/bin/Xvfb
  • /usr/bin/pip

執行工作之後,會捨棄為它所建立的容器。 工作執行的結果可以持續保存,但其執行環境則否。

工作最多可以執行 60 分鐘。 工作超出此限制時,即會失敗。 如果工作超出此限制,請將它分成多個工作。 例如,如果工作執行三個作業,則可能會將它分成三個工作:一個作業一個工作。

若要瞭解如何將工作新增至階段,請參閱將工作新增至階段

建置工作

建置工作會編譯您的專案以準備部署。 它們會產生可傳送至建置保存目錄的構件,不過根據預設值,會將構件放在專案的根目錄中。

從建置工作取得輸入的工作,必須參照在它們建立所在之相同結構中的建置構件。 例如,如果建置工作會將建置構件保存至 output 目錄,則部署所編譯的專案時,部署 Script 會參照 output 目錄,而不是專案根目錄。 您可以在建置保存目錄欄位中輸入目錄名稱,以指定要保存的目錄。 將欄位空白,會保存根目錄。

如果您使用簡單建置器類型,則不會編譯或建置程式碼;會將它包裝並設為供未來階段使用。

部署工作

部署工作會將您的專案當成應用程式上傳至 IBM Cloud,而且可以從 URL 進行存取。 部署專案之後,您可以在 IBM Cloud 儀表板上找到所部署的應用程式。

部署工作可以部署新的應用程式,或更新現有的應用程式。 即使您先使用其他方法來部署應用程式,也可以使用部署工作來更新應用程式。 若要更新應用程式,請在部署工作中使用該應用程式的名稱。

您可以部署至一個或多個地區及服務。 例如,您可以設定 Delivery Pipeline 使用一個以上的服務、在一個地區中測試,然後部署至多個地區進行正式作業。

測試工作

如果您想要要求符合條件,請在建置及部署工作之前或之後包含測試工作。 您可以視需要將測試工作自訂成簡單或複雜。 例如,您可以發出 cURL 指令,並預期會有特定回應。 也可以使用協力廠商測試服務(例如 Sauce Labs)來執行一組單元測試或執行功能測試。

如果您的測試產生 JUnit XML 格式的結果檔案,則會在每個測試結果頁面的測試標籤上顯示根據這些結果檔案的報告。 如果測試失敗,則工作也會失敗。

環境內容(環境變數)

一組預先定義的環境內容讓您能存取工作執行環境的相關資訊。 如需預先定義環境內容的完整清單,請參閱環境內容及資源

您也可以定義自己的環境內容。 例如,您可能定義 API_KEY 內容,以傳遞管線中所有 Script 用來存取 IBM Cloud 資源的 API 金鑰。

您可以新增下列類型的內容:

  • 文字:具有單行值的內容索引鍵。
  • 文字區:具有多行值的內容索引鍵。 也可以使用每一個文字區內容值的 base64 版本。 您可以使用具有尾端 _base641 字尾的內容索引鍵名稱來存取此版本。 您可以輸入 echo "$(echo $multi_base64 | base64 -d)" 來解碼 base64 版本的「文字區」內容並回應它,其中 multi 是您定義的內容索引鍵名稱,multi_base64 是提供的其他內容。 管線基本映像檔包含內建支援,可透通地管理多行編碼。 不過,如果您使用自訂映像檔,則必須附加 _base64 字尾內容,以防止您的值被行尾截斷的問題。
  • 安全:具有單行值的內容索引鍵,並且以 AES-128 加密來保護。 值會顯示為星號。
  • 內容:專案儲存庫中的檔案。 此檔案可以包含多個內容。 每一個內容都必須單獨一行。 若要區隔鍵值組,請使用等號 (=)。以引號括住所有字串值。 例如,MY_STRING="SOME STRING VALUE"

您可以在工作 Script 中執行 env 指令,來檢查管線工作的環境內容。

管線內容

若要定義管線內容,請從「管線」頁面的溢位功能表,選取配置管線

管道溢出菜單
管道溢出菜單

從「管線配置」頁面上的環境內容標籤,設定管線層次的環境內容。

管道屬性頁面
管道屬性頁面

階段內容

若要定義階段內容,請開啟「階段配置」頁面,然後按一下環境內容標籤。

階段屬性頁面
階段屬性頁面

可以使用起始值(或空白值)來定義階段內容,然後藉由匯出環境變數來置換工作中的該值。 藉由置換起始值,階段中的後續工作可以看到新值。 例如,您可以包含以下命令來設定 $API_KEY 屬性並使其可供階段中的另一個作業使用:export API_KEY=<insert API key here>

計算的內容

您可以計算階段之間共用的環境內容值,方法是在階段執行時建立 build.properties 檔,然後讓下一個階段執行檔案。 例如,您的建置工作可能會在建置 Script 中包含下列指令:

echo "IMAGE_NAME=${FULL_REPOSITORY_NAME}" >> $ARCHIVE_DIR/build.properties

執行 build.properties 檔案(如果存在的話),即會啟動所有工作。

建立及使用構件

建置工作會自動提取使用者 Script 執行所在之現行資料夾中的內容。 如果您後續的部署不需要整個 Git 儲存庫內容,則最好配置明確輸出目錄,然後在該處複製或建立相關構件。 工作 Script 是在建置結果(輸出目錄)中執行。

部署至 IBM Cloud Kubernetes Service 的部署工作,需要指定用來執行權限工作之使用者的「平台 API 金鑰」、Dockerfile 以及選擇性地使用 Helm Chart。

工作使用指派給它的「平台 API 金鑰」登入目標環境之後,會執行工作 Script(以便您可以在 Script 中執行 cf pushkubectl 指令)。

範例管線

簡單的管線可能包含三個階段:

  1. 「建置」階段:在應用程式上編譯及執行建置程序。
  2. 「測試」階段:部署應用程式實例,然後對其執行測試。
  3. 「正式作業」階段:部署所測試應用程式的正式作業實例。

此管線顯示在下列概念性圖表中:

管道中階段與作業的概念圖
三階段管道的概念模型

階段都採用其從儲存庫及建置工作的輸入,而且會循序並各自獨立地執行階段內的工作。 在範例管線中,會循序執行階段,即使「測試」及「正式作業」階段都採用「建置」階段的輸出作為其輸入。