為什麼會有這一系列文章?

個人運氣相當不錯，11年的 IT 職涯經歷許多不同角色，從開發者、現場工程師、顧問、到目前 SRE 兼服務平台管理者，每一個階段對於 Azure DevOps 服務感受有很大的差異。身為開發者時，DevOps Tool 只要能滿足開發需求、提高生產力且不需要花費太多心力去維護相關設定即可，如：版本管理(如:Git)、自動化建置與測試(如:Pipeline)、自動化佈署 (如:Release Pipeline)。當時使用 Azure DevOps (非TFS) 就非常有感，預設支援 Pipeline Task、提供 Cloud Agent...等，著實省下不少時間。在這個階段學到比較多的是如何使用這個工具，其他對於 Azure DevOps 並沒有更進一步認知。

擔任微軟現場工程師與顧問時，除了專注 DevOps 文化導入與工具使用教學外，最多是如何整合大量工具達到組織目的，如： CI 如何整合 Unit Test, Integration Test, E2E Test 與 Performance Test、CD 如何做到滾動式、藍綠或金絲雀部署 或 如何做到 DevSecOps 的測試左移。因為工作內容包含現場問題處理，對於 Azure DevOps 進階設定與背後運作原理，有比一般開發者更進一步理解。

許多人會以為這階段對於 Azure DevOps 已經有充分的經驗，但對於現場工程師與顧問角色來說，是嚴重缺乏深度使用者與大型組織使用經驗。讀者可能難以理解，但沒有一個組織的 DevOps 是相同，更多的是因為缺乏專業領域所衍生出來使用方式，加上很少有極為專業的IT組織或超大型IT團隊長期聘用顧問，導致多數顧問只能做導入、問題排除與進階規劃，無法提供相當程度的解決方案。 (但沒關係，一般企業的工作也忙不完了)

當身為千人使用 Azure DevOps 管理人員時，又是另一個知識與經驗的衝擊。過往問題排除經驗與遵守最佳實踐原則可能可以讓自己生存下來，但對於五花八門的需求與管理規劃讓人難以招架。如: 需要多少 Agent 才能符合需求、安全掃描的分寸該如何拿捏、如何做到 Knowledge Sharing、過大的持續整合機制該如何更有效率，這些沒有一定的答案。

理所當然，這種類型內容很難寫，寫了也不適用於你的組織，所以相關內容不會在這系列文章出現。

經歷了這三種角色，對於 Azure DevOps 功能與管理的經驗更加完善，想趁記憶猶新的時候彙整遇到的問題、解決方法與最佳實踐。內容會有有簡單的功能說明與除錯技巧，但會附上應用情境與為什麼要這麼做，讓讀者遇到相同問題時，也能知道背後設計的原理。

因為是彙整，所以文章順序可能沒有順序或關聯，等鐵人賽結束後，會再彙整至個人部落格Duran的速寫筆記

理論與實務差異

無論組織內哪一個角色，我們都會問到什麼是 DevOps 與如何做 DevOps? 但對於開發者來說，以文謅謅方式解釋什麼是 DevOps 只會讓開發人員覺得虛無飄渺。正確傳授與告知如何使用生產力工具，並實際執行專案管理流程並檢討，體會到真的能完成一件事情更為重要；支援工程師與平台管理人員需要了解更多功能並具備問題排除能力；顧問則是需要具備提供企業常見解決方案，並與平台管理人員合作，打造成容易維護流程；平台管理人員與管理層必須訂定開發者規範，除了有效有效提升開發者產出品質，並確保每一個步驟皆合規。

文章結構

大致上文章結果除了功能說明與解決方法，會增加前言描述情境與最佳實踐(或其他案例分享)，讓這系列文章盡量不要是工具書形式。

• 前言: 描述使用情境與問題來源，讓讀者先了解能解決什麼問題
• 功能說明與解決方法: 文章本體
• 最佳實踐與其他案例(選擇性): 遇到類似問題的準則、Azure DevOps 好的與差的部分或遇過類似的案例經驗

誰適合閱讀此系列文章

功能說明與解決方法適合開發人員、維運人員與 Azure DevOps 管理者，使用情境與最佳實踐適合擔任 Team Leader、Techical Manager 與技術顧問。此系列文章對象為曾經使用過 Azure DevOps (或類似產品) 讀者，而非初學者。