上一個

下一個

設定應用程式和虛擬機器

4 分鐘

為 Azure 解決方案建置應用程式與其他自訂程式碼是很常見的作業。自訂應用程式可能包含網站、API 和背景應用程式，這些應用程式執行時不需要任何人為互動。在此單元中，您將了解如何設計管線，以建置及部署應用程式與其基礎結構。

建置應用程式

許多類型的應用程式都必須先進行「編譯」或「建置」，才可供使用。建置流程會取得應用程式的原始程式碼、對其執行一連串的活動，然後建立一組可部署的檔案。

建置程式會將原始程式碼編譯成二進位檔案或可執行檔，但通常也包含其他活動：

壓縮提供給網站使用者的圖像檔案。
Linting 您的程式碼以確認其遵循良好的程式碼撰寫做法。
執行單元測試，以驗證應用程式個別項目的行為。

除了這些步驟外，您也可以執行對檔案進行數位簽署之類的步驟，以協助確保無法修改檔案。

不論這一系列步驟為何，建置程序的輸出都是可部署的成品。成品通常會儲存至管線代理程式的檔案系統。管線的後續階段需要使用成品，以透過您的環境進行部署，並在其進展到您在管線定義中定義的各個品質閘道時進行測試。

注意

您可能聽過持續整合與持續部署，或 CI 與 CD 等術語。建置程序位於您管線的持續整合組件內。

管線成品

管線中產生的成品不會儲存在 Git 存放庫中。其衍生自原始程式碼，但並非程式碼本身，因此不屬於原始檔控制存放庫。其會建立到管線代理程式的檔案系統上。系統會為每個管線作業建立新的代理程式，因此您必須有辦法在作業與代理程式之間共用檔案。

管線成品可讓您將檔案儲存在 Azure Pipelines 中，而且其會與管線的特定執行相關聯。您可以使用 PublishBuildArtifacts 內建管線工作來指示 Azure Pipelines，讓其將檔案或資料夾從代理程式的檔案系統發佈為管線成品：

- task: PublishBuildArtifacts@1
  displayName: Publish folder as a pipeline artifact
  inputs:
    artifactName: my-artifact-name
    pathToPublish: '$(Build.ArtifactStagingDirectory)/my-folder'

pathToPublish 屬性是包含管線代理程式檔案系統上已編譯程式碼或輸出檔案的位置。此位置的內容將會發佈至成品。您可以指定單一檔案或資料夾。

每個成品都會有名稱，您可以使用 artifactName 工作屬性來加以指定。您稍後會在管線中使用成品名稱來參考成品。後續的管線作業和階段可以下載成品，以使用成品 (舉例來說) 將網站部署至其裝載所在的伺服器：

Diagram that shows pipeline stages to build and deploy that refer to an artifact named Website.

當您使用部署作業時，系統預設會自動下載管線成品。如果您使用一般作業，請使用 DownloadBuildArtifacts 工作來下載管線成品：

- task: DownloadBuildArtifacts@0
  inputs:
    buildType: current
    downloadType: single
    artifactName: my-artifact-name
    downloadPath: '$(System.ArtifactsDirectory)'

部署應用程式：

應用程式的建置程序會產生並發佈可部署的成品。管線的後續階段會部署成品。應用程式的部署方式取決於您用來裝載應用程式的服務。

部署到 Azure App Service

您的玩具公司會使用 Azure App Service 來裝載其網站。您可以使用 Bicep 來建立和設定 App Service 應用程式。但在部署應用程式方面，有數個選項可將已編譯的應用程式移至裝載基礎結構上。這些選項會成為 App Service 資料平面的一部分來進行管理。

最常見的方法是使用 AzureRmWebAppDeployment Azure Pipelines 工作：

- task: AzureRmWebAppDeployment@4
  inputs:
    azureSubscription: MyServiceConnection
    ResourceGroupName: MyResourceGroup
    WebAppName: my-app-service
    Package: '$(Pipeline.Workspace)/my-artifact-name/website.zip'

您必須提供幾項資訊，才能將應用程式部署到 App Service。這些資訊包括 App Service 應用程式的資源群組和資源名稱 (可使用 ResourceGroupName 與 WebAppName 輸入來指定)。如上一個單元所學到的，您應該將輸出新增至 Bicep 檔案，並使用管線變數來透過管線傳播應用程式名稱。您也需要使用 Package 輸入來指定要部署應用程式的 .zip 檔案，這通常是管線成品的路徑。

App Service 有自己的資料平面驗證系統可用於部署。 AzureRmWebAppDeployment 工作會自動為您處理驗證程序：

Diagram that shows the credential exchange process.

AzureRmWebAppDeployment 工作會使用與您的服務連線相關聯的服務主體，自動建立及下載部署的必要認證。然後，其會在與 App Service 資料平面 API 通訊時使用部署認證。

App Service 也會提供一些其他與部署相關的特徵，包括「部署位置」。位置可協助您安全地部署應用程式的新版本，而不需要停機。位置也可協助您先將應用程式的新版本準備好，再將生產流量傳送至其中。我們不會在此課程模組中使用位置，但會在課程模組結尾的 [摘要] 頁面上提供其詳細資訊的連結。

將應用程式部署到其他 Azure 服務

Azure 提供許多其他選項來裝載您的應用程式，每個選項都有自己的部署方法。

Azure Functions 建置於 App Service 上，並使用與稍早所述類似的部署流程。

如果您部署到虛擬機器，通常需要連線到虛擬機器執行個體，才能安裝應用程式。您通常需要使用特製化工具 (例如 Chef、Puppet 或 Ansible)，以協調虛擬機器的部署作業。

如果您使用 Kubernetes 或 Azure Kubernetes Service (AKS)，通常會使用略微不同的方法來建置和部署解決方案。應用程式建置好之後，管線會建立容器映像，並將其發佈至容器登錄，然後 Kubernetes 叢集會從中讀取資料。因為容器登錄會保留已編譯的應用程式，所以您一般不會使用管線成品。

在此課程模組中，我們將焦點放在 Azure App Service，以說明涉及到的管線概念。在課程模組結尾的 [摘要] 頁面上，我們會提供如何部署到其他裝載服務的詳細資訊連結。

在管線中測試應用程式

在上一個課程模組中，您已了解從管線執行自動化的測試的價值與重要性。當您部署應用程式時，管線最好要執行一些測試來叫用應用程式的程式碼。這類測試可降低應用程式或部署錯誤可能造成停機的風險。在更進階的案例中，您甚至可以對應用程式執行一組測試案例，例如，叫用 API，或是提交和監視綜合交易。

許多應用程式都會實作「健康情況檢查端點」。當健康情況檢查端點收到要求時，即會對網站執行一系列檢查，例如，確保可從應用程式環境連線到資料庫與網路服務。網站傳回的回應會指出應用程式是否狀況良好。開發人員可以撰寫和自訂自己的健康情況檢查，以符合應用程式的需求。如果您的應用程式有健康情況檢查端點，則在部署階段完成後，從管線監視該端點是很正常的行為。

您的部署管線

在下一個練習中，您將更新部署管線，以新增作業來建置網站的應用程式，並將其部署到每個環境：

Diagram that shows the revised pipeline, including a new build stage and an application deployment step.

繼續