說明如何使用 Azure DevOps 實踐現代化系統開發流程，從版本控制、持續整合到持續部署。詳細從 Azure DevOps 的安裝、資料庫設定到 Build Machine 的 Agent 安裝、Deploy Target 的 Deployment Group 安裝，到建立完整的 Pipelines，實證從 Visual Studio Commits 到網站終端呈現完整更新結果的全流程 😎
環境說明
本次要進行的是地端環境 (On-Premises) 的 Azure DevOps Server 安裝，並示範如果整合版本控制、CI & CD，關於 Azure DevOps Server 授權可以參考 Azure DevOps Server License & Price 授權與計價方式。
個人是基於研究的興趣才進行本次專案，不是所有的團隊都需要進行地端環境的部署，使用 Azure DevOps 雲端服務，可以讓您的人生輕鬆許多 (Make Your Life Easier) 😉
這篇文章適合有使用過 Visual Studio 以及建立 ASP.NET 進行應用開發，並且有使用 Visual Studio Git 原始碼控制經驗的朋友。如果沒有使用過 Visual Studio & Git 可以參考 Visual Studio 使用 Git 版本控制 的說明。
地端環境部署相關的伺服器資訊：
| IP | Server |
|---|---|
| 192.168.112.100 | AD Server, DNS Server |
| 192.168.112.120 | Build Machine |
| 192.168.112.40 | DevOps Server |
| 192.168.112.50 | SQL Server |
| 192.168.112.60 | IIS Server |
Azure DevOps Server
首先要先到 Active Directory 建立服務帳戶，提供 Azude DevOps 安裝的過程以及連線資料庫所使用。
安裝的過程包含檔案的下載，大約需要 30 分鐘。
完成安裝後需要進行重新啟動，啟動後就可以看到設置精靈 (Wizard) 出現。
如果是恢復或者升級 Azure DevOps，可以選擇既有的資料庫，否則選擇建立新的 DevOps Server Deployment。
安裝上有基本方案與進階方案選擇，進階方案提供了與 SQL Server Reporting Services 的整合，本次選擇基本方案。
在搜尋選項，可以設定是否要啟動 Collection 層級的搜尋功能，可以用於搜尋 Work Item 以及 Wiki 內容，非常方便，但本次示範為簡化不特別進行設定。
完成設定後進行 Configure 設定，等待完成 (大約 15分鐘左右)
Database
Database 除了 SQL Server Dtabase Engine 外，還需要全文檢索引擎的功能，此外如果搭配進階的 DevOps 方案，還需要安裝 Reporting Services。
將服務帳戶加入 SQL Server Login
在 DevOps 安裝的過程，會建立 AzureDevOps_Configuration 資料庫，用於保存 DevOps 的組態設定。
此外會建立 AzureDevOps_DefaultCollection 資料庫，所有 Default Collection 下的專案都會保存在這個資料庫，而如果建立新的 Collection 會再另外建立新的 Database。因此可以得知 DevOps 是以 Database 來區隔不同的 Collection。
Admin Console
藉由登入 DevOps Server 使用 Admin Console 可以進行相關的組態調整，包含建立新的 Collection 等設定。
可以在 Admin Console 調整 DevOps 使用的 Service Account
DevOps 的資料集中在所使用的資料庫當中，而 Admin Console 提供了備份介面，在正式環境不要忘記定期對資料進行備份。
Azure DevOps
完成設定後，從 DevOps Binding 的網址，就可以進入 DevOps 的頁面囉
Version Control
因為沒有使用 AD Certificate Service，所以沒有辦法自簽憑證使用 HTTPS 的方式發行專案。因此改以 SSH 的方式進行，首先要推送專案的 Client 端必須要先使用 ssh-keygen 產生 id_rsa 以及 id_rsa.pub，產生的結果會儲存在 user 路徑下的 .ssh。
建立的過程會需要指定一組 Password Pharase，之後發次 Commit 專案透過 SSH 都會使用到這組 Pharase。
cd c:\users\developer
ssh-keygen -t rsa -C "developer@sdwh.dev"接著將 id_ras.pub 的內容複製後，到 Azure DevOps 使用者的 SSH 設定加入：
接著在 Visual Studio 專案進行 Git 設定，將遠端位址改為 ssh 路徑，路徑可以由 DevOps 的 Repo 中取得。
完成後就可以將專案由 Visual Studio 推送到 Azure DevOps Repos 囉 🙂
Continuous Integration
Build Machine
如果 Build Machine 使用的 Windows 10 / 11 因為評估版的授權期限較短，可以使用 rearm 重新取得 90 天授權，最多可以使用 2 次，微軟真是佛心來著 😲
slmgr -rearm使用「專案設定 (Project Settings)」在 Pipelines 下選擇「代理程式集區 (Agent Pools)」並由「代理程式 (Agents)」下新增新的代理程式。
為了要註冊 Agent，首先從 DevOps 提示的連結將 vsts-agent-win-x64-2.181.2.zip 進行下載到 Build Machine，接著使用 PowerShell 執行安裝的 Script，稍待一會就可以完成 Agent 註冊：
Add-Type -AssemblyName System.IO.Compression.FileSystem ;
[System.IO.Compression.ZipFile]::ExtractToDirectory(
"C:\Downloads\vsts-agent-win-x64-2.181.2.zip", "$PWD")安裝的過程會詢問是否要註冊為 Windows Service，但不斷 Y、Y、Y 都無法成功，最後只能在完成後用 run.bat 的方式啟動 Agent，很不方便 🤨
後來發現雖然提示是 Y/N 但實際上要輸入的是 true 才是表示輸入 Y 😅
完成 agent 註冊為服務後，可以使用 services.msc 去檢查服務的自動啟動是否有延遲，記得要調整為不要有延遲 😉
而完成 Agent 註冊後，可以到 DevOps 上的代理進行確認：
原本 Build Machine 有安裝 Visual Studio 2022 Community 但在執行 CI 的時候，DevOps 一直報錯說找不到 MSBuild 相關工具，不確定是 VS 2022 尚未支援或者是 Community Edition 的問題？後來改在 Build Machine 上安裝 Visual Studio 2019 Build Tools 後重新啟動就可以了 😁
Setting CI Pipeline
開始建立 CI Pipeline
目前主流的開發方式都是使用 YAML 來設計 Pipeline 以達到 Infra As Code，但筆者目前對於使用 YAML 來設計 Pipeline 完全沒有相關經驗，因此這次的示範是以「傳統編輯器」的方式來設計 Pipeline。
資料來源因為是使用版控在 Azure DevOps 上的 Repos 所以就是 Azure Repos Git
本次使用的是 「ASP.NET Web 應用程式」使用 .NET Framework 4.7.2 設計 ASP.NET MVC 5 的專案，因此選擇 ASP.NET 範本。
這邊需要選擇集區 (Agent Pools) 所以要先完成集區以及代理程式 (Agent) 的建立。
手動執行 Build 後，可以看到編譯過程以及是否有錯誤及警告。
Continuous Deployment
從專案選擇「部署群組 (Deployment groups)」用以建立部署目標伺服器，例如 IIS Server。
只要將 DevOps 上提供的 PowerShell Script 複製到 Target Server 上執行即可 (執行須使用 Administrator 身分並且只有用 PowerShell 不能用 PowerShell ISE)。過程中會需要確認以什麼樣的服務權限來讓 DevOps 進行部署使用，預設是 NT Authority\SYSTEM。
需要注意的是 PowerShell Script 裡面，預設提供的 "Administrator" 使用的雙引號是 U+201C “ 以及 U+201D ”，不是每個作業系統，尤其是中文語系的都吃這一套 🤣 如果執行 PowerShell Script 發生錯誤，記得將雙引號取代為常見的 U+0022 "。
在註冊部署群組的時候，會出現驗證方式，需要輸入 PAT，給予部署群組 讀取與管理權限即可。
另除了 PAT 外，也可以使用 Negotiate ，輸入 AD 驗證的方式進行註冊。
而如果註冊時發生 TF400813 錯誤時，重新輸入的 URL 必須包含 Collection 名稱，例如：
https://devops.sdwh.local/DefaultCollection如果目標伺服器已經註冊為部署集區 (Deployment Pools) 的成員，則可以將目標伺服器所在的集區反向建立為專案的部署群組 (Deployment Groups)，這樣一來就不需要每個專案都重複對相同的 IIS Server 註冊為 Deployment Pool。
完成後可以在 DevOps 上進行確認
Setting CD Pipeline
開始建立 CD Pipeline：
範本選擇「IIS 網站部署」，其他幾個選項都很相似，所以在部署上需要有相當的 IIS、Azure 管理經驗，才能夠將原本的部署作業方式轉換為 Infra As Code 的部署管線方式。
首先要指定成品，成品就是從 CI 階段 Build 無誤的成果，在 CD 階段用以部署到 IIS 伺服器上。
在階段的組態類型，要注意需要建立的是 IIS 站台、Application 或者是虛擬目錄，這個地方很容易因為選錯卡關，具體的差異需要有使用 IIS 的經驗。
本次示範選擇的是 IIS Web Application，要注意的是虛擬目錄必須是 / 開頭。
首先設定 IIS Web App Manage 的相關設定，這邊可以設定是否建立新的集區以及要發佈到 IIS Server 的那個實體路徑：
接著設定 IIS Web App Deploy，這邊可以設定部署是否先將程式離線、刪除已存在檔案等設定對應於以往使用 Visual Studio 發佈到 IIS Server 上的相關設定：
需要注意的是在 Web App Deploy 一定要設定虛擬應用程式的位址，而且必須與 Web App Manage 的虛擬路徑相同，否則會造成 DevOps Deploy 的檔案無法建立成功，但 CD 管線卻正常完成的 Bug (耗費 2 個小時 Debug 的心淚) 😥
建立好發行管線後，還需要建立發行 (Release) 才能夠進行部署。
首先設定發行的成品來源：
點選建立好的發行，並手動按下部署：
讓子彈飛一會兒，很順利的部署完成了，我們可以到 IIS Server 去驗證。
而雖然這次的部署順利的完成了，但過程中可是幾經波折，包括成品的位置不正確、組態類型沒有選擇 Application 等等，反覆測試了很多次，卡關將近一個小時才解決。
這也說明了在做 CD 時，一開始為了將原本部署作業，改為由 Continuous Deployment 會碰到的轉換困難。而如果團隊不僅一種部署方式，這邊會需要下的功夫只會更多，因為需要針對每種部署方式都有對應的設定方式。
Auto CI & CD
完成手動 CI & CD 只完成了一半，接下來要讓整個 CI & CD 過程能夠自動化。
首先到 CI Pipeline 進行設定，啟用持續整合的設定
接著到 CD Pipeline 進行設定，將部署的階段調整為持續部署觸發程序
接著馬上來驗證 CI & CD 是否已經自動化，使用 Visual Studio 進行程式碼設計，並將結果 Commit 到 DevOps Server：
從 CI Pipeline 的資訊，我們可以發現 CI 作業隨著收到最新的 Commit 已經開始自動工作了
CI 完成後，CD 也開始接續工作，將 CI 產生的成品進行部署到伺服器上
順利的完成之後，我們使用瀏覽器瀏覽 IIS Server 的網站，發現更新已經成功了，我們整個自動化 CI & CD 設定完成了！
