Azure Release Pipeline 能夠延續 Build Pipeline 的工作，
將 Artifacts 發佈至指定伺服器上。
本篇將簡介如何透過 Azure DevOps 建立 Release Pipeline。
前言
每次起手時前言都要想很久，
這次就果斷地切入主題吧！
本篇想談談如何透過 Azure DevOps 建立佈署流水線。
開始前先來談談大家最容易忽略的地方— Artifact。
Artifact
每一條 Release Pipeline 背後都有一份打包好的 Artifact。
你可以使用 Publish Task 或其他第三方工具來產出 Artifact。
順帶一提，使用 Publish Task 預設會儲存到 Azure DevOps 伺服器上。
如果是使用雲端版的 Azure DevOps Service，
那你大可不必擔心儲存容量的問題！
但如果是自架地端的 Azure DevOps Server 時就得另作考慮了。
而筆者的做法會將 Artifact 存到另一台檔案空間內，
這部分只要調整一下 Publish Task 的參數就能夠做到，
雖然有點土炮但也不失為一個經濟實惠的做法！
如果想與其他第三方整合的話也是可以的（如 Jenkins、GitHub...），
大家可依工作環境選擇適用的工具。
建立 Release Pipeline
說了這麼多，讓我們來動手建一條 Release Pipeline吧。
首先點選Pipelines→Releases →New →New Release Pipeline，
然後依使用的專案類型選用預設 Template，
在這邊我們使用 Azure App Service Deployment 作為示範。
接著會請你輸入 Stage 名稱及App Service 連線的基本資訊，
而這邊的 Stage 指的是佈署環境，
通常會依用途區分而建立多個 Stage 環境（如 Dev、Test、Production 等）。
設定好後點選上方 Tab 的 Pipeline，
可以看到 Artifact 被佈署到 Stage 的流程的視覺介面，
整體設計上算是蠻簡潔易懂的。
接下來從左邊點選新增 Artifact ，
在 SourceType 這裡我們選用 Build，
但你也可以使用其他支援的第三方作為 Aritfact 來源。
接著就是輸入一些基本資訊了。
在 Default Version 是這邊我們選用 Latest 作為發行版本。
而右下方會提示目前最新的 Artifact 版本名稱。
設定好 Artifact 後，
我們還少一段 Release Trigger ，
如果沒設定 Release Trigger 的話整個 Pipeline 是不會動的！（除非手動啦）
而在 Azure DevOps 中預設有四種 Release Trigger：
- Continuous deployment triggers
- Scheduled release triggers
- Pull request triggers
- Stage triggers
以下針對自己常用的前面兩者做介紹。
Continuous deployment triggers
需於 Release Pipeline 中設置特定版本的 Artifact，
會於每次 Build Pipeline 結束後觸發佈署流程，
可依分支來源及 Build Tag 進行篩選。
在 Branch Commit 頻率不高的小專案中，
可以使用這種觸發方式佈署至 Dev 環境。
Scheduled release triggers
可於指定時間排程觸發部署流程，
此策略最耳熟能詳的就是Daily Build 了。
通常可用於測試環境的構建，
讓測試人員節省一些手動佈署的步驟，
使其更專注於執行核心價值更高的探索性測試。
另外還有 Pull release trigger 及 Stage trigger，
前者是透過發 PR 來觸發佈署，後者則可在 deploy chain 的狀況觸發。
這兩者我的實務經驗都不是很多，所以就不多做介紹。
最後要介紹的是 Pre-deployment approvals，
你可以在每個 Stage 設定 Trigger 的地方找到它（點選閃電圖示）。
接著加入個人或群組作為審核對象，
並設定這個佈署的審核期限。
而 Approval Policies 還有兩個設定：
1.The user requesting a release or deployment should not approve it
翻成白話就是我們是否允許「自己能夠審核自己發起的佈署」。
2.Skip approval if the same approver approved the previous stage
這個情境主要是解決「同一個審核人針對兩個 Stage 連續審核兩次」這件事情。
簡單解釋如下：
當兩個 Stage 都是同一個審核人的條件下，
如果前面 Stage 已經審核了，
第二個 Stage 就可以略過審核流程。
結語
最近在撰寫 Azure DevOps 相關的文章，
常常設定某個主題後又覺得篇幅太大，
所以又衍伸出了另一篇文章。
原本能寫部落格的時間就不多了，
這樣遞迴式的結果導致原本設定的主題還沒寫完！
希望下一篇能夠來 Release Pipeline 的簡單實作。
