前言
原文
小結
App service 支援幾種自動和手動的部署方式
Automated deployment (自動部署)
Azure DevOps Services: 作為自家的產品,自然支援 Azure DevOps Services 的,你可以用它來 build, test, generate release, and push to Azure Web App.
GitHub / Bitbucket: 此外,它也支援 GitHub 和 Bitbucket ,你只需要把你的 app slot 連接到相應的 repository branch,然後在該 branch 上更新你的程式碼,那麼相應的 app slot 就會自動被更新了
Manual deployment (手動部署)
Git: 你可以提供一個 Git URL 然後從這個 remote repository 把這個 repository 的 code 推到你的 app
Zip deployment: 你可以用 curl 等工具把裝着程式碼的 zip 檔案推到你的 App Service
FTP/S: 你可以用 FTP 或 FTPS 直接把你的程式碼傳送到 App Services 的檔案系統內
CLI: 你也可以用 webapp up
來部署你的程式碼,和其他方法不同的是,在使用這方法時,如果本來是沒有相應的 App Service 的話,那就自動幫你建立一個
Deployment slots
Standard 或以上的 slot 都支援 deployment slots
你可以快速的 swap staging 和 production slots (把 staging 的推送到 production 或是回滾到上一個 production 版本)
同時也可以利用 swap 來避免 downtime
在 testing, QA, and staging 時,程式碼應該被推送到 staging slot
如果你是使用 custom container 的話,你要先把你的 image 推到 container registry 然後在你的 webapp deployment slot 更新為相應的 image tag
一般都不建議使用 “latest” 作為你的 image tag,因為這樣會很難追查正被使用的是那個版本。
在你更新了 webapp 使用的 tag 之後,deployment slot 就會自動的重啟和取得相應的 container image
文本摘錄
Automated deployment
- Azure DevOps Services: You can push your code to Azure DevOps Services, build your code in the cloud, run the tests, generate a release from the code, and finally, push your code to an Azure Web App.
- GitHub: Azure supports automated deployment directly from GitHub. When you connect your GitHub repository to Azure for automated deployment, any changes you push to your production branch on GitHub are automatically deployed for you.
- Bitbucket: With its similarities to GitHub, you can configure an automated deployment with Bitbucket.
Manual deployment
Manually push your code to Azure:
- Git: App Service web apps feature a Git URL that you can add as a remote repository. Pushing to the remote repository deploys your app.
- CLI:
webapp up
is a feature of theaz
command-line interface that packages your app and deploys it. Unlike other deployment methods,az webapp up
can create a new App Service web app for you if you haven’t already created one. - Zip deploy: Use
curl
or a similar HTTP utility to send a ZIP of your application files to App Service. - FTP/S: FTP or FTPS is a traditional way of pushing your code to many hosting environments, including App Service.
Use deployment slots
For Standard App Service Plan tier or better, you can deploy your app to a staging environment and then swap your staging and production slots.
Continuously deploy code
For testing, QA, and staging, they should be continuously deployed to a staging slot. This allows your stakeholders to easily assess and test the deployed branch.
Continuously deploy containers
For custom containers, deploy the image into a staging slot and swap into production to prevent downtime. The automation is more complex than code deployment because you must push the image to a container registry and update the image tag on the webapp.
- Build and tag the image: As part of the build pipeline, tag the image with the git commit ID, timestamp, or other identifiable information. It’s best not to use the default “latest” tag. Otherwise, it’s difficult to trace back what code is currently deployed, which makes debugging far more difficult.
- Push the tagged image: Once the image is built and tagged, the pipeline pushes the image to our container registry. In the next step, the deployment slot will pull the tagged image from the container registry.
- Update the deployment slot with the new image tag: When this property is updated, the site will automatically restart and pull the new container image.
發佈留言