共用方式為

定義核准和檢查

  • 發行項

Azure DevOps Services

管線是由階段所組成。 管線作者可以藉由定義階段的條件來控制階段是否應該執行。 另一個控制階段何時應該執行的方法是通過 核准和檢查。

yaml 檔案中未定義核准和其他檢查。 修改管線 yaml 檔案的用戶無法在階段開始之前修改執行的檢查。 資源的系統管理員會使用 Azure Pipelines 的 Web 介面來管理檢查。

管線依賴環境、服務連線、代理程式集區、變數群組和安全檔案等資源。 檢查可讓 資源擁有者 控制任何管線中的階段是否可以取用資源。 身為資源的擁有者，您可以定義在取用該資源的階段開始之前，必須滿足的檢查。 例如，在環境上進行手動核准檢查可確保只有在指定的使用者檢閱所部署的變更之後，才會部署至該環境。

階段可以包含許多作業，而每個作業都可以取用數個資源。 在開始執行階段之前，必須滿足該階段中使用的所有資源的所有檢查。 Azure Pipelines 會在每個階段之前暫停管線的執行，並等候所有擱置的檢查完成。

核准和檢查有五種類別，它們會依每個類別內建立的順序執行。 檢查會根據每個檢查中指定的重試間隔重新評估。 如果在指定的逾時之前，所有檢查都未成功，則不會執行該階段。 如果任何檢查終端機失敗（例如，如果您拒絕其中一個資源的核准），則不會執行該階段。

您可以在核准和簽出逾時時重試階段。

靜態檢查會先執行，然後執行預先檢查核准。 依序排列的類別如下：

  1. 靜態檢查：分支控件、必要範本和評估成品
  2. 預先檢查核准
  3. 動態檢查：核准、叫用 Azure 函式、叫用 REST API、上班時間、查詢 Azure 監視器警示
  4. 檢查後核准
  5. 獨佔鎖定

您也可以在 [核准和檢查] 索引標籤上看到執行順序。

重要

您可以在環境、服務連線、存放庫、變數群組、安全檔案和代理程式集區上設定檢查。

服務連線不能由變數指定。

核准

您可以使用核准和檢查，手動控制階段何時應該執行。 這項檢查通常用於控制生產環境的部署。

  1. 登入您的 Azure DevOps 組織，然後瀏覽至您的專案。

  2. 選取 [管線>環境]，然後選取您的環境。

  3. 選取 [ 核准和檢查 ] 索引標籤，然後選取 + 要新增檢查的簽署。

    顯示如何在 Azure Pipelines 中新增核准和檢查的螢幕快照。

  4. 選取 [ 核准]，然後選取 [ 下一步]。

  5. 新增使用者或群組作為您指定的 核准者，並視需要提供 核准者的指示。 指定是否要允許或限制核准者核准自己的執行，並指定所需的 逾時。 如果在指定的逾時內未完成核准，階段會標示為略過。

  6. 完成後，選取 [建立]。

    顯示如何建立新核准的螢幕快照。

  7. 觸發核准檢查之後，會在使用者介面中顯示提示視窗，如下列範例所示。 此視窗提供核准者拒絕或核准執行的選項，以及任何隨附的指示。

    顯示核准提示視窗的螢幕快照。

在核准和檢查開始執行時，可以檢閱核准的使用者清單已修正。 也就是說，在開始執行檢查之後完成核准檢查的使用者和群組清單變更不會被挑選。

注意

如果群組指定為核准者，則群組內只有一位使用者需要核准才能繼續執行。

延遲核准

有一種情況是授與核准的時間，以及部署應該開始的時間不相符。 例如，您可能想要等候部署新版本，直到晚上的低流量時間為止。

若要解決此案例，您可以延遲核准，並設定核准生效的時間。

  1. 選取 [ 延遲核准]。

    當您回應核准要求時，延遲核准選項的螢幕快照。

  2. 設定核准時間。

    設定核准時間的螢幕快照。

您會在 [檢查] 面板中看到核准為預先核准。 核准會在設定時間生效。

分支控制

使用分支控制檢查，您可以確定所有與管線鏈接的資源都是從 允許的 分支建置，而且分支已啟用保護。 這項檢查有助於控制部署的發行整備程度和品質。 如果多個資源與管線連結，則會驗證所有資源的來源。 如果您已連結另一個管線，則會驗證所部署之特定執行的分支以進行保護。

若要定義分支控制項檢查：

  1. 在您的 Azure DevOps 專案中，移至需要保護的資源（例如環境）。

  2. 瀏覽至 [核准和檢查] 以取得資源。

  3. 選擇 [ 分支] 控制項 檢查，並提供允許分支的逗號分隔清單。 您可以強制分支已啟用保護。 您也可以定義檢查其中一個分支的保護狀態是否未知的行為。 如果至少套用了一個原則，則會將分支視為受保護（包括存放庫層級套用的原則）。

    設定分支控制檢查。

在運行時間，檢查會根據允許的清單來驗證執行中所有鏈接資源的分支。 如果任一分支不符合準則，檢查就會失敗，而階段會標示為失敗。

注意

檢查會要求分支名稱必須完整。 請確定分支名稱的格式為 refs/heads/<branch name>

上班時間

如果您想要讓環境的所有部署都只在特定時間範圍中發生，則上班時間檢查是理想的解決方案。 當您執行管線時，會執行使用資源等候上班時間的階段。 如果您有多個執行同時執行，則每個執行都會獨立驗證。 在上班時間開始時，檢查會標示為所有執行成功。

設定上班時間檢查。

如果階段的執行尚未在上班時間結束時開始（由其他檢查保留），則會自動撤銷上班時間核准，並排定第二天重新評估。 如果階段的執行未在針對檢查指定的逾時期間內啟動，且階段標示為失敗，則檢查會失敗。

叫用 Azure 函式

Azure 函式是 Azure 所提供的無伺服器計算平臺。 使用 Azure 函式，您可以執行少量程式代碼（稱為「函式」），而不必擔心應用程式基礎結構。 鑒於高彈性，Azure 函式提供了撰寫您自己的檢查的絕佳方式。 您包含簽入 Azure 函式的邏輯，讓每次執行都是在 HTTP 要求上觸發、運行時間短，並傳回回應。 定義檢查時，您可以剖析回應本文，以推斷檢查是否成功。 您可以在控件選項中使用評估之間的時間設定，定期重複評估。 深入瞭解

設定 Azure 函式檢查。

如果您的檢查未在設定 的逾時內成功，則會略過相關聯的階段。 視其而定的階段也會略過。 如需詳細資訊，請參閱 Azure 函式應用程式工作。

注意

從 Sprint 215 開始，即可存取使用者定義管線變數。

深入瞭解使用叫用 Azure 函式檢查的建議方式。 檢查 必須遵循特定規則 ，視其模式和要符合規範的重試次數而定。

叫用 REST API

叫用 REST API 檢查可讓您與任何現有的服務整合。 定期呼叫 REST API，並在傳回成功的回應時繼續。 深入瞭解

您可以在控件選項中使用評估之間的時間設定，定期重複評估。 如果您的檢查未在設定 的逾時內成功，則會略過相關聯的階段。 視其而定的階段也會略過。 如需詳細資訊，請參閱 叫用 REST API 工作。

注意

從 Sprint 215 開始，即可存取使用者定義管線變數。

深入瞭解使用叫用 REST API 檢查的建議方式。

查詢 Azure 監視器警示

Azure 監視器提供來自 Azure 基礎結構和每個個別 Azure 資源之數據的視覺效果、查詢、路由、警示、自動調整和自動化。 警示是偵測基礎結構或應用程式健康情況問題的標準方法，並採取更正動作。 Canary 部署和分段推出是常見的部署策略，用來降低回歸至重要應用程式的風險。 部署至階段（一組客戶）之後，應用程式會觀察到一段時間。 部署之後應用程式的健康情況是用來決定是否應該對下一個階段進行更新。

查詢 Azure 監視器警示可協助您觀察 Azure 監視器，並確保部署後不會針對應用程式引發任何警示。 如果在評估時未啟動任何警示規則，檢查就會成功。 深入瞭解

評估會在控件選項中的評估設定時間之後重複。 如果階段未在指定的 逾 時期間內開始執行，檢查就會失敗。

必要範本

透過必要的範本檢查，您可以強制執行管線來使用特定的 YAML 範本。 當此檢查就緒時，如果管線未從參考的範本延伸，管線就會失敗。

若要定義必要的範本核准：

  1. 在您的 Azure DevOps 專案中，移至 您想要限制的服務連線 。

  2. 開啟 [編輯] 旁功能表中的 [核准] 和 [檢查]。

  3. 在 [ 新增您的第一個檢查 ] 功能表中，選取 [ 必要範本]。

  4. 輸入有關如何取得所需範本檔案的詳細數據。

    • 存放庫類型：存放庫的位置（GitHub、Azure 或 Bitbucket）。
    • 存放庫：包含範本的存放庫名稱。
    • 參考：必要範本的分支或標記。
    • 必要範本的路徑：範本的名稱。

您可以針對相同的服務連線有多個必要範本。 在這裡範例中，必要的樣本為 production_template.yaml。

設定必要的範本檢查。

停用檢查

偵錯檢查時，您可能會想要暫時停用，然後再次啟用它。 若要停用或啟用檢查：

  1. 在您的 Azure DevOps 專案中，使用檢查前往資源。

  2. 開啟 [ 核准和檢查] 索引標籤 。

  3. 在關係型功能表中，選取 [停用] 或 [啟用]。

    停用核取選項的螢幕快照。

略過檢查

在某些情況下，例如 Hotfix 部署，您可能需要略過檢查。 只有在已定義檢查的資源具有系統管理員許可權時，您才能略過檢查。

若要略過核准、上班時間、叫用 Azure 函式或叫用 REST API 檢查，請在資源等待檢閱時選取 [ 略過檢查 ]。 以下是略過上班時間檢查的範例。

略過上班時間檢查選項的螢幕快照。

當您略過檢查時，您會看到誰略過檢查面板中的檢查。

已略過檢查記錄的螢幕快照。

評估成品

您可以針對自定義原則評估要部署到環境的成品。

注意

目前，這僅適用於容器映射成品

若要定義成品的自定義原則評估，請遵循下列步驟。

  1. 在您的 Azure DevOps Services 專案中，流覽至需要保護的環境。 深入瞭解如何 建立環境。

    檢視環境。

  2. 流覽至 [ 核准] 並檢查 環境。

    將檢查新增至環境。

  3. 選取 [ 評估成品]。

    新增評估成品檢查。

  4. 貼上原則定義，然後選取 [ 儲存]。 深入瞭解 撰寫原則定義。

    新增原則定義。

當您執行管線時，該回合的執行會在進入使用環境的階段之前暫停。 指定的原則會根據可用的影像元數據進行評估。 當原則成功且失敗時，檢查就會通過。 如果檢查失敗，階段會標示為失敗。

檢視通過的檢查。

您也可以從管線檢視查看原則檢查的完整記錄。

檢視傳遞的檢查記錄。

獨佔鎖定

獨佔鎖定檢查只允許從管線執行單一執行，而且可以在階段或管線層級設定。 使用該資源的所有管線執行中的所有階段都會暫停。 當使用鎖定的階段完成時，另一個階段可以繼續使用資源。 此外，只允許一個階段繼續。

屬性 lockBehavior 會決定其他階段如何處理鎖定。 當您指定階段的 lockBehavior 屬性時，會自動為該階段建立鎖定。 有兩個可能 lockBehavior 的值：

  • runLatest - 只有最新的回合會取得資源的鎖定。 runLatest 如果未 lockBehavior 指定 ，則為預設值。
  • sequential - 所有執行都會循序取得受保護資源的鎖定。

若要搭配 sequential 部署或 runLatest使用獨佔鎖定檢查，請遵循下列步驟：

  1. 在環境上啟用獨佔鎖定檢查（或其他受保護的資源）。 獨佔鎖定選項是可用的檢查。

    獨佔鎖定選項 [核准] 索引卷標的螢幕快照。

  2. 在管線的 YAML 檔案中，指定名為 lockBehavior的屬性。 這可以針對整個 管線 或指定 階段指定：

在舞台上設定：

stages:
- stage: A
  lockBehavior: sequential
  jobs:
  - job: Job
    steps:
    - script: Hey!

在管線上設定：

lockBehavior: runLatest
stages:
- stage: A
  jobs:
  - job: Job
    steps:
    - script: Hey!

如果您未指定 lockBehavior ，且在資源上設定鎖定，則會使用的預設值 runLatest 。

獨佔鎖定檢查只允許從管線執行單一執行。 使用該資源的所有管線執行中的所有階段都會暫停。 當使用鎖定的階段完成時，另一個階段可以繼續使用資源。 此外，只允許一個階段繼續。 嘗試進行鎖定的任何其他階段都會取消。

ServiceNow 變更管理

這項檢查需要從 Marketplace 安裝 ServiceNow 變更管理延伸模組

servicenow 變更管理檢查允許整合管線中的 ServiceNow 變更管理程式。 藉由新增檢查，即可在階段開始時自動建立 ServiceNow 中的新變更要求。 管線會等候變更程式在開始階段之前完成。 您可以在這裡了解其他詳細資料。

多個核准和檢查

階段可以包含許多作業，而每個作業都可以取用數個資源。 在開始執行階段之前，必須滿足該階段中使用的所有資源的所有檢查。 Azure Pipelines 會在每個階段之前暫停管線的執行，並等候所有擱置的檢查完成。

單一最終負面決策會導致管線遭到拒絕存取，而階段會失敗。 除了叫用 Azure 函式/REST API 和獨佔鎖定之外，所有核准和檢查的決定都是最終決定。 您可以重新執行成功的叫用 Azure 函式/REST API 檢查。

使用建議方式叫用 Azure 函式/REST API 檢查時，其存取決策也是最終的。

當您指定 叫用 Azure 函式/REST API 檢查的評估 時間為非零時，檢查的決定是非最終的。 此案例值得探索。

讓我們看看範例。 假設您的 YAML 管線具有使用服務連線的階段。 此服務連線已設定兩項檢查：

  1. 名為「已授與外部核准」的異步檢查，會確認已授與外部核准，並以建議的方式設定。
  2. 名為「部署原因有效」的同步檢查，會驗證部署原因是否有效，且您已將評估之間的時間設定為 7 分鐘。

下圖顯示可能的檢查執行。 顯示異步和同步檢查執行時間軸的圖表。

在這裡執行中：

  • 同時叫用「外部核准授與」和「部署原因有效」這兩項檢查。 部署原因有效 會立即失敗，但由於 已授 與外部核准擱置中，因此會重試。
  • 第 7 分鐘會 重試部署原因有效 ，這次會通過。
  • 在 15 分鐘， 外部核准已 授與回呼至 Azure Pipelines 並成功做出決策。 現在，這兩項檢查都會通過，因此允許管線繼續部署階段。

讓我們看看另一個範例，涉及兩個同步檢查。 假設您的 YAML 管線具有使用服務連線的階段。 此服務連線已設定兩項檢查：

  1. 名為同步檢查 1 的同步檢查，可讓您將評估之間的時間設定為 5 分鐘。
  2. 名為 Sync Check 2 的同步檢查，其會將評估之間的時間設定為 7 分鐘。

下圖顯示可能的檢查執行。 顯示兩個同步檢查執行時間軸的圖表。

在這裡執行中：

  • 同時叫用同步檢查 1 和同步檢查 2 這兩項檢查。 同步檢查 1 通過，但重試，因為 同步檢查 2 失敗。
  • 在第 5 分鐘， 會重試同步檢查 1 ，但失敗，因此會重試。
  • 第 7 分鐘， 會重試同步檢查 2 並成功。 通過決策有效期為7分鐘。 如果 同步檢查 1 未在此時間間隔中傳遞， 則會重試同步檢查 2 。
  • 在10分鐘， 會重試同步檢查1 ，但失敗，因此會重試。
  • 在14分鐘， 會重試同步檢查2 並成功。 通過決策有效期為7分鐘。 如果 同步檢查 1 未在此時間間隔中傳遞， 則會重試同步檢查 2 。
  • 第 15 分鐘， 會重試同步檢查 1 並成功。 現在，這兩項檢查都會通過，因此允許管線繼續部署階段。

讓我們看看涉及核准和同步檢查的範例。 假設您已設定同步檢查和服務連線 的核准，且評估 時間介於 5 分鐘之間。 在獲得核准之前，不論決策為何，您的檢查都會每隔 5 分鐘執行一次。

常見問題集

定義的檢查並未啟動。 發生什麼事？

一旦滿足階段條件，就會開始評估檢查。 您應該確認在資源上新增檢查之後開始執行階段，並在階段中取用資源。

如何使用檢查來排程階段？

使用上班時間檢查，您可以控制階段執行開始的時間。 您可以在設計工具版本中的階段上達到與預先定義排程相同的行為。

如何取得未來排程執行階段的預先核准？

您可以啟用此案例。

  1. 上班時間檢查可讓部署至資源的所有階段排程在時間範圍之間執行
  2. 在相同的資源上設定核准時，階段會先等候核准再開始。
  3. 您可以在資源上設定這兩項檢查。 階段會等待核准和上班時間。 完成核准之後，它會在下一個排程的窗口中啟動。

我可以等候完成部署成品的安全性掃描嗎？

若要等候在部署成品上完成安全性掃描，您必須使用如 AquaScan 的外部掃描服務。 部署的成品必須在掃描服務可存取的位置上傳，才能開始檢查，而且可以使用預先定義的變數來識別。 使用叫用 REST API 檢查，您可以新增檢查以等候安全性服務中的 API，並將成品識別碼傳遞為輸入。

如何在檢查中使用先前階段的輸出變數？

根據預設，只有預先定義的變數可供檢查。 您可以使用連結變數群組來存取其他變數。 上一個階段的輸出變數可以寫入變數群組中，並在檢查中進行存取。

深入了解