了解工作流程作業
工作流程可讓您自動執行部署程序中的步驟。 程序中可能包含數個您想要執行的作業邏輯群組。 在本單元中，您將了解工作流程作業，以及如何使用其將品質控制流程新增至 Bicep 部署。
什麼是工作流程作業？
作業可協助您將工作流程分割成多個邏輯區塊。 每個作業可以包含一或多個步驟。
您可以在工作流程中使用作業來標示關注點分離。 例如，當您使用 Bicep 程式碼時，驗證程式碼與部署 Bicep 檔案是不同的考量。 當您使用自動化工作流程時，組建和測試程式碼通常稱為持續整合 (CI)。 在自動化工作流程中部署程式碼通常稱為持續部署 (CD)。
在 CI 作業中，您會檢查對程式碼所做的變更是否有效。 CI 作業提供品質保證。 這些作業可以執行，而不會影響實際執行環境。
在許多程式設計語言中，必須先建置程式碼，才能加以執行。 部署 Bicep 檔案後，它會從 Bicep 轉換或 轉譯 為 JSON。 此工具會自動執行此程序。 在大部分情況下，您不需要手動將 Bicep 程式碼組建至工作流程內的 JSON 範本。 不過，當我們討論 Bicep 程式碼時，我們仍會使用「持續整合」一詞，因為 CI 的其他部分仍適用，例如驗證程式碼。
成功執行 CI 作業之後，您也應更加確信您所做的變更也會成功部署。 在 CD 作業中，您會將程式碼部署到每個環境。 您通常會從測試和其他非實際執行環境開始，然後再移至實際執行環境。 在此課程模組中，我們將部署至單一環境。 在未來的課程模組中，您將了解如何擴充部署工作流程，以部署到多個環境，例如非實際執行環境和實際執行環境。
依預設，作業會以平行方式執行。 您可以控制每個作業的執行方式和時間。 例如，您可以設定 CD 作業，只在 CI 作業成功執行之後執行。 或者，您可能有多個 CI 作業需要依序執行，例如組建程式碼，然後加以測試。 您也可以包含只有在先前的部署作業失敗時才會執行的復原作業。
左移
藉由使用作業，您可以在部署程式碼之前驗證程式碼的品質。 此流程有時稱為左移。
請考量您在撰寫程式碼時所執行之活動的時間表。 時間表從規劃和設計階段開始。 然後移至組建和測試階段。 最後，您會部署且必須支援解決方案。
在軟體開發中，一個眾所皆知的規則是，您在程序越早發現錯誤 (越接近時間表左邊)，就能更容易、更快速、更便宜地修正錯誤。 您在流程中越晚發現錯誤，修正就會變得越加困難且越加複雜。
因此，目標是將問題的探索往上圖的左側移動。 在本課程模組中，您將了解如何在工作流程進行時新增更多驗證和測試。
您甚至可以在部署開始之前先新增驗證。 當您使用 GitHub 之類的工具時，提取要求通常會代表小組上某人想要對主要分支上的程式碼所做的變更。 建立另一個工作流程，以在提取要求的檢閱流程期間自動執行 CI 步驟會很有幫助。 這項技術有助於驗證即使發生建議的變更，程式碼是否仍可運作。 如果驗證成功，您就確信變更不會在合併至主要分支時造成問題。 如果檢查失敗，您就知道提取要求準備好要合併之前還有更多工作要做。 在未來的課程模組中，您將深入瞭解如何使用提取要求和分支策略，來設定適當的發行流程。
重要
自動化驗證和測試只會與您撰寫的測試一樣有效。 請務必考量您需要測試哪些項目，以及需要執行哪些步驟，以確保部署正常。
定義工作流程作業
每個工作流程至少包含一個作業，而且您可以定義其他作業以符合需求。 依預設，作業會以平行方式執行。 您擁有的 GitHub 帳戶類型會決定當您使用 GitHub 裝載的執行器時，可以同時執行的作業數目。
假設您建置了需要部署兩次的 Bicep 檔案: 一次是在美國的基礎結構，一次是在歐洲的基礎結構。 您也想要在工作流程中驗證 Bicep 程式碼。 以下是定義類似流程的多重作業工作流程圖例：
請注意，此範例有三個作業。 驗證作業類似於 CI 作業。 然後，執行部署美國和部署歐洲作業。 每個階段分別會將程式碼部署至其中一個環境。 依預設，作業會以平行方式執行。
以下是工作流程 YAML 檔案中作業的定義方式：
name: learn-github-actions
on: [push]
jobs:
validate:
runs-on: ubuntu-latest
steps:
- run: echo "Here is where you'd perform the validation steps."
deployUS:
runs-on: windows-latest
steps:
- run: echo "Here is where you'd perform the steps to deploy to the US region."
deployEurope:
runs-on: ubuntu-latest
steps:
- run: echo "Here is where you'd perform the steps to deploy to the European region."
控制作業順序
您可以新增作業之間的相依性，以變更順序。 繼續上述範例，如下所示，您可能想要在執行部署作業之前驗證程式碼：
您可以使用 needs 關鍵字，來指定作業之間的相依性：
name: learn-github-actions
on: [push]
jobs:
validate:
runs-on: ubuntu-latest
steps:
- run: echo "Here is where you'd perform the validation steps."
deployUS:
runs-on: windows-latest
needs: validate
steps:
- run: echo "Here is where you'd perform the steps to deploy to the US region."
deployEurope:
runs-on: ubuntu-latest
needs: validate
steps:
- run: echo "Here is where you'd perform the steps to deploy to the European region."
當您使用 needs 關鍵字時，工作流程會等候相依作業順利完成，再開始下一個作業。 如果工作流程偵測到已滿足多個作業的所有相依性，則其可以平行執行這些作業。
注意
事實上，只有在您有足夠的執行器同時執行多個作業時，作業才會平行執行。 您可以使用的 GitHub 裝載的執行器數目取決於您擁有的 GitHub 帳戶類型。 如果您需要更多平行作業，您可以購買另一個 GitHub 帳戶方案。
有時候，您想要在先前的作業失敗時執行作業。 例如，以下是不同的工作流程。 如果部署失敗，名為復原的作業之後會立即執行：
您可以使用 if 關鍵字，來指定作業執行之前應符合的條件：
name: learn-github-actions
on: [push]
jobs:
validate:
runs-on: ubuntu-latest
steps:
- run: echo "Here is where you'd perform the validation steps."
deploy:
runs-on: windows-latest
needs: validate
steps:
- run: echo "Here is where you'd perform the steps to deploy."
rollback:
runs-on: ubuntu-latest
needs: deploy
if: ${{ failure() }}
steps:
- run: echo "Here is where you'd perform the steps to roll back a failure."
在上述範例中，當一切順利時，工作流程會先執行測試作業，然後執行部署作業。 其會略過復原作業。 不過，如果測試或部署作業失敗，工作流程會執行復原作業。 您將在此課程模組的後續部分深入了解復原。
Bicep 部署作業
典型的 Bicep 部署工作流程包含數個作業。 工作流程在作業中移動時，目標是要逐漸確信後續的作業會成功。 以下是 Bicep 部署工作流程的常見作業：
- Lint：使用 Bicep Linter 來驗證 Bicep 檔案的格式正確，且不包含任何明顯的錯誤。
- 驗證：使用 Azure Resource Manager 預檢驗證程序來檢查在部署時可能發生的問題。
- 預覽:使用假設狀況命令來驗證對 Azure 環境套用的變更清單。 要求人員手動檢閱假設狀況結果，並核准工作流程以繼續進行。
- 部署：將部署提交至 Resource Manager，並等候其完成。
- 煙霧測試:針對您已部署的一些重要資源執行基本部署後檢查。 我們將這些檢查稱為基礎結構煙霧測試。
您的組織可能會有不同的作業順序，或者您可能需要將 Bicep 部署整合到部署其他元件的工作流程中。 了解作業的運作方式之後，您就可以設計工作流程以符合需求。
每個作業都會在從全新環境啟動的新執行器執行個體上執行。 因此，在每個作業中，您的第一個步驟通常應為簽出原始程式碼。 您也需要在與 Azure 互動的每個作業中登入 Azure 環境。
在此課程模組中，您將深入了解這些作業，並逐漸組建包含每個作業的工作流程。 您也將了解：
- 工作流程如何在任何先前的作業中發生非預期的情況時停止部署流程。
- 如何設定工作流程以暫停，直到您手動驗證先前作業發生什麼情況為止。