設定應用程式和虛擬機器
為 Azure 解決方案建置應用程式與其他自訂程式碼是很常見的作業。 自訂應用程式可能包含網站、API 和背景應用程式，這些應用程式執行時不需要任何人為互動。 在此單元中，您將了解如何設計工作流程，以建置和部署應用程式及其基礎結構。
建置應用程式
許多類型的應用程式都必須先進行「編譯」或「建置」後，才可供您使用。 建置流程會取得應用程式的原始程式碼、對其執行一連串的活動，然後建立一組可部署的檔案。
建置流程會將原始程式碼編譯成二進位檔案或可執行檔。 建置流程通常會包含其他活動，包括壓縮要提供給網站使用者的影像檔、對程式碼進行「Lint 分析」以確認其是否遵循良好的程式碼編寫實務，並執行「單元測試」以確認應用程式個別片段的行為。 您也可以執行對檔案進行數位簽署之類的步驟，以協助確保無法修改檔案。
不論這一系列步驟為何，建置程序的輸出都是可部署的成品。 成品通常會儲存至工作流程執行器的檔案系統。 工作流程的後續部分需要使用該成品，以在您的環境加以部署，並在其進展到您於工作流程定義中定義的各個品質閘道時進行測試。
注意
您可能聽過「持續整合」和「持續部署」，或 CI/CD 等術語。 建置流程位於工作流程的持續整合組件內。
工作流程成品
工作流程中產生的成品不會儲存在您的 Git 存放庫中。 其衍生自原始程式碼，但並非程式碼本身，因此不屬於原始檔控制存放庫。 它們建立於工作流程執行器的檔案系統上。 系統會為每個工作流程作業建立新的執行器，因此，您需要一種可在作業與執行器之間共用檔案的方式。
「工作流程成品」可讓您將檔案儲存在 GitHub Actions 中，並將其關聯至工作流程的特定執行。 您可以使用 actions/upload-artifact 工作流程動作，指示 GitHub Actions 從執行器的檔案系統上傳檔案或資料夾，以做為工作流程成品：
- name: Upload folder as a workflow artifact
uses: actions/upload-artifact@v3
with:
name: my-artifact-name
path: ./my-folder
path 屬性是包含作業執行器檔案系統上已編譯程式碼或輸出檔案的位置。 此位置的內容將會上傳至成品。 您可以指定單一檔案、多個檔案或一個資料夾。
每個成品都有名稱，您可以使用 name 屬性來指定。 您稍後會在工作流程中使用成品名稱來參考成品。 後續的工作流程作業可以下載成品，以使用成品 (舉例來說) 將網站部署至其裝載所在的伺服器：
使用 actions/download-artifact 動作來下載所有工作流程成品：
- uses: actions/download-artifact@v3
或者，指定成品名稱，以便僅下載特定的成品：
- uses: actions/download-artifact@v3
with:
name: my-artifact-name
部署應用程式：
應用程式的建置流程會產生並上傳可部署的成品。 工作流程中稍後的作業會部署成品。 應用程式的部署方式取決於您用來裝載應用程式的服務。
部署到 Azure App Service
您的玩具公司會使用 Azure App Service 來裝載其網站。 您可以使用 Bicep 來建立並設定 App Service 應用程式，但在部署應用程式時，有數個選項可將已編譯的應用程式移至裝載基礎結構上。 這些選項會成為 App Service 資料平面的一部分來進行管理。
最常見的方法是使用 azure/webapps-deploy 動作：
- uses: azure/webapps-deploy@v2
with:
app-name: my-app-service
package: my-artifact-name/website.zip
您必須提供幾項資訊，才能將應用程式部署到 App Service。 這些資訊包括 App Service 應用程式的資源名稱 (可使用 app-name 屬性來指定)。 如您上一個單元學到的，您應該將輸出新增至 Bicep 檔案，並使用工作流程變數，透過工作流程傳播應用程式名稱。 您也需要使用 package 屬性來指定要和應用程式一起部署的 .zip 檔案。 這通常是工作流程成品的路徑。
App Service 有自己的資料平面驗證系統可用於部署。 azure/webapps-deploy 動作會自動為您處理驗證流程：
azure/webapps-deploy 動作會使用與您作業的作用中 Azure 工作階段相關聯的身分識別，您可以使用工作負載身分識別 
來登入。 此動作會建立並下載部署 
所需的認證。 然後，其會在與 App Service 資料平面 API 
通訊時使用部署認證。
App Service 也會提供一些其他與部署相關的特徵，包括「部署位置」。 位置可協助您安全地部署應用程式的新版本，而不需要停機。 位置也可協助您先將應用程式的新版本準備好，再將生產流量傳送至其中。 我們不會在此課程模組中使用位置，但會在課程模組的 [摘要] 頁面上提供其詳細資訊的連結。
將應用程式部署到其他 Azure 服務
Azure 提供許多其他選項來裝載您的應用程式，每個選項都有自己的部署方法。
Azure Functions 建置於 App Service 上，並使用與稍早所述類似的部署流程。
如果您部署到虛擬機器，通常需要連線到虛擬機器執行個體，才能安裝應用程式。 您通常需要使用特製化工具 (例如 Chef、Puppet 或 Ansible)，以協調虛擬機器的部署作業。
如果您使用 Kubernetes 或 Azure Kubernetes Service (AKS)，通常會使用略微不同的方法來建置及部署解決方案。 建置您的應用程式之後，工作流程會建立「容器映像」，並將其發佈至「容器登錄」，然後 Kubernetes 叢集會從中讀取資料。 因為容器登錄會保留已編譯的應用程式，所以您通常不會使用工作流程成品。
在此課程模組中，我們將專注於 Azure App Service，以說明相關的工作流程概念。 在課程模組結尾的 [摘要] 頁面上，我們會提供如何部署到其他裝載服務的詳細資訊連結。
在工作流程中測試應用程式
在上一個課程模組中，您已了解從工作流程執行自動化測試的價值和重要性。 當您部署應用程式時，工作流程最好要執行一些測試來叫用應用程式的程式碼。 這類測試可降低應用程式或部署錯誤可能造成停機的風險。 在更進階的案例中，您甚至可以對應用程式執行一組測試案例，例如，叫用 API，或是提交和監視綜合交易。
許多應用程式都會實作「健康情況檢查端點」。 當健康情況檢查端點收到要求時，即會對網站執行一系列檢查，例如，確保可從應用程式環境連線到資料庫與網路服務。 網站傳回的回應會指出應用程式是否狀況良好。 開發人員可以撰寫和自訂自己的健康情況檢查，以符合應用程式的需求。 如果您的應用程式具有健康情況檢查端點，則在部署作業完成後，從工作流程監視該端點是很正常的行為。
您的部署工作流程
在下一個練習中，您將更新部署工作流程，以新增作業來建置網站的應用程式，並將其部署到每個環境：
