[2019 DevOpsDays Taipei]Azure DevOps 建立 DevOps 團隊
•
1 like•93 views
使用Azure DevOps建立一個高績效的DevOps團隊
Recommended
More Related Content
What's hot
What's hot (20)
Similar to [2019 DevOpsDays Taipei]Azure DevOps 建立 DevOps 團隊
Similar to [2019 DevOpsDays Taipei]Azure DevOps 建立 DevOps 團隊 (20)
More from Edward Kuo
More from Edward Kuo (18)
[2019 DevOpsDays Taipei]Azure DevOps 建立 DevOps 團隊
- 1. Azure DevOps 建立 DevOps 團隊 DevOpsDays Taipei2019 Edward Kuo Kingston Technology IT Manager / Microsoft Regional Director
- 2. About Me 2019 DevOps Expo @Trend Micro 講師 2019 翻轉營運契機 Azure DevOps 趨勢與實務研討會 講師 2019 Insider Dev Tour Taipei 講師 2019 Global Azure Bootcamp 廣州 講師 2018 DevOps Days Taipei 講師 2018 DOIS DevOps 國際峰會 深圳站 講師 2018 Insider Dev Tour Taipei 講師 2018 .NET Core Conf Taipei 講師 2018 Agile Tour Taichung 講師 2018 Global Xamarin Day 講師 2018 商周-解碼新製造高效協同關鍵 講師 Microsoft Global Tech Summit 北京 講師 技術社群 講師 Kingston Technology IT Manager Microsoft Regional Director Microsoft Azure MVP 2
- 3. LET’S BEGIN NOW! 2018 年 DevOps Days Taipei 講了上集，今天來講下集。以下內容為個人經驗與實踐，請各位斟酌參考或使用，最後，還是必須以企業和團隊現況為主 3
- 4. 前言 4
- 9. 評估DevOps工具 9
- 11. 雲端平台效益 使用雲端作為DevOps平台是高績效團隊和普通團隊的區別之處，也是驅動高效能的因素之一，按照 National Institution of Standard and Technology 的 軟體交付效能與可用性的預測。雲端計算在5個關鍵能力方面，高績效團隊 團隊是低績效團隊的24倍。 11
- 12. 時間花在創造商業價值，不是建置工具平台 決策指標 1 減少人員對DevOps工具開發和維運的成本 不同屬性的成員，都能用相同工具做事 2 PO、Developer、Tester & Stakeholder 即時因應技術變化，自動不斷擴充功能 3 針對一些技術演進，能自動提供相對應方案或是功能 彈性且有效的整合各種平台 4 能過有彈性擴充、支持第三方平台或是內部整合 12
- 14. 開始玩 Azure DevOps Service 基於雲端優勢和決策指標，再加上團隊現況與實務情境考量下 14
- 15. 15 Azure DevOps 五大功能 Azure Boards 透過電子看板方式讓所有成員一起規劃、追蹤及 討論工作項目，可以使用Agile、Scrum、CMMI 的樣板，建立團隊習慣的專案管理模式。Boards 算是整個工具的核心 Azure Pipelines 可以適用於任何語言、平臺和雲端，建置團隊的 CI/ CD、測試及佈署的流水線。也可以與GitHub 或任何其他Git提供者整合與建置Pipeline Azure Repos 取得無限制的雲端託管的私人Git存放庫，並透過 提取需求和進階檔案管理，讓團隊可以共同作業 以及管理程式碼 Azure Test Plans 使用手動與探勘測試工具，並建置測試流程與規 劃，進行測試及交付。 Azure Artifacts 建立、裝載套件並與團隊成員共用，也可以做為 自己團隊私有的Nuget、npm服務。讓團隊建立 自己專屬的元件庫
- 16. 01 02 03 04 16 計畫 + 追蹤 • Azure Boards 開發 + 測試 • Azure Repos • Azure Pipelines • Azure Test Plans 監控 + 學習 • Azure Boards 交付 • Azure Pipelines • Azure Artifacts DevOps 循環 DevOps
- 20. 實踐DevOps團隊
- 21. 21
- 23. 思維改變 DevOps 實踐第一步 1 做開發和做維運的成員，都必須改變想法與習慣 目標一致 2 團隊運作方向必須與企業文化或目標一致 不追求自我成功或是英雄主義 3 每個人都應該改變，努力讓團隊變得更好 切割Story粒度 4 Story粒度足以影響佈署頻率，但是，這是一門藝術 Git 分支策略的訂定 5 情境與需求差異的不同，分支切割策略也會有所差異 23
- 24. Backlog Practice 商業需求 來自市場/商業的需求或是使用者的需求。一個Sprint中， 僅能佔團隊的80%動能 工程需求 建構Infrastructure、平台、系統的改善或重構項目…等。 非商業的需求。一個Sprint中，僅能佔團隊的15~20%動 能 商業 & 工程 兩者必須同時被管理與追蹤，不能分散在其他看板或是 不列入看板中 定義Story Flow Story完成定義是必須能上線到生產環境才算完成 Story 優先序 定義Story優先權，並用色塊區分。 24
- 25. 25 在 Board 的設定中建立多通道，同時管理不同類型的Story ，並客製化看板流程符 合團隊工作的Story Flow
- 26. 26 在 Board 的設定中，針對 Story 的 Priority 不同，可以分別定義顏色區塊，藉由顏 色差異，快速了解每個Story的重要性。然後，依照 Priority 優先權，決定本週要優 先進行的Story
- 27. Version Control Version Control 我們採用Git，進行版控 連結工作項目 每次Check In，無論是修改或是新增的Code，都必須與 Task或是Story關聯起來 分支 依照公司文化與情境建立分支種類，目前我們有建立了 三種分支和兩種分支類型 無差別版控 任何程式碼或是程式，都必須要納入版控，如:資料庫、 第三方的執行檔…等 IaC 系統Infrastructure設定、應用程式環境變數…等，甚至 一些自動化腳本，都必需納入版控 27
- 28. 28 Azure Repos 程式碼規範 在分支設立進版策略，不僅可確保程式碼進版的 規範和程式碼品質，也可以防不良程式碼流入生 產環境和防止團隊中有人違反進版流程導致問題 強大的程式碼搜尋 直接在線上快速找尋想要的程式碼，以及每個程 式碼和那些工作項目是相關，對於要負責多個專 案的團隊非常適合 Git進行版控 可以從任何編輯器或Git Client 安全地連接程式碼 並將程式碼推送到Git存儲庫中
- 29. 29 Version Control • Git • TFVC Work Item Process Template • Agile • Base • CMMI • Scrum • Customer Process
- 30. 30 Develop: 屬於開發階段，只限於團隊內部人員使用或是系統串接測試使用 QAS : 給USER 或 QA 階段測試的時候使用 Master : 生產環境使用 我們是在三個不同階段是分別佈署在三個不同VM / 環境
- 31. 31 Develop:屬於開發階段，只限於團隊內部人員使用或是系統串接測試使用 Master :給USER 或 QA 階段測試使用，以及後續生產環境使用 採用Container，對於測試到生產環境，僅搬移Container Host和變更環境變數
- 32. 32 訂定Branch規則 • 最少一定要經過多少位的Code Reviewer審核 • 是否有每次修改都有連結到Task 或 Story • 檢查每次Check In是否有加入註解 • 限制Merge類型 • 主要規範分支怎樣合併到主線上 預先編譯 • 在Merge前，會預先編譯後確認成功，才會進行Merge 預先建立Code Reviewer • 預先把該Branch的Code Reviewer建立好 從其他服務或是資訊來批准合併分支 • 透過其他服務或是狀態確認是否可以Merge
- 34. 自動化 1 能在Pipeline解決重複性的流程或動作，就要透過自動化處理 2 多次以上需要人工處理的流程或是每次都需要花大量時間處理，就要自動化 處理 3 任何建置自動化流程前，一定要先用人工方式跑完整個流程 4 建置自動化工作，也必須是一個Task工作，且自動化建置初期是很消耗成本 5 雖然，需要自動化，但我們也不追求100%自動化。而是採用80% 自動化，20% 依 舊是由人工作業是比較合適的 34
- 35. Azure Pipeline 任何語言、任何平 臺、任何雲 任何語言都可以進行建置、測試和佈署動作，並 且可以直接佈署到Azure、AWS、GCP或企業內 部的環境 擴展性 從Market place下載所需要的套件，從編譯、測 試和部署…等都有相關的第三方套件可以使用， 也支持使用Yaml腳本撰寫Pipeline Containers& Kubernetes 輕鬆構建容器並將其推送到容器註冊表，並且能 將容器佈署到各個主機或kubernetes 35
- 36. 36 Continuous Integration 變數管理 除Develop branch外，其他皆透過在CI過程中置換系統 設定參數，並把多個系統會共用的參數，集中化管理 程式碼掃描 與Sonarqube整合，在CI過程中進行程式碼掃描 Container Manager UAT 編譯後，生產環境將不會再次編譯 Container Version Container都會有版號，且不產生 Latest版本，避免增加 運行版本辨識的難度以及加速還原的速度 持續整合時間 盡量讓CI編譯時間不要超過10分鐘，目的是要快速反饋 與快速修正
- 37. 37 在Azure DevOps Service的CI功能取名為Pipeline，CD功能稱作 Release 視覺化方式建立Pipeline或是透過YAML方式建立Pipeline Source Code可以來自Azure Repos、TFVC、GitHub、Subversion和 Bitbucket Cloud 一個Pipeline可以複合式的使用不同Agent建置，例如:雲和地 可以使用Marketplace的Task又或是自訂企業的客製化Task Pipeline
- 38. 38 Our Pipeline 開發+UAT+生產共235條Pipeline 涵蓋範圍從前端、後端、Container到Database 上個月就跑1053次，不算是單月最大量 運行CI的時間不能太長
- 39. 39 模組化設計:將多個Pipeline相同使用的參數，抽出來管理與維護 機密性參數保護:機密性參數可以在Merge到生產環境才注入到系統內 使用 易於管理: 參數管理與維護會相當方便 Library
- 41. 41 使用YAML，建立CI Pipeline YAML檔案會直接納入該專案的版控中。讓Pipeline也能被版控 Pipeline管理、維護和轉移也相當方便 更為彈性、更有效率 可用Template expressions更容易擴展其他Pipeline，減少撰寫Pipeline 時間 Pipeline as Code
- 43. 43 Continuous Test 自動化 自動化是測試的關鍵 持續測試 單元測試、整合測試、UI測試到負載平衡測試都是屬於 持續測試一環 測試深度 使用增量和反覆運算方式，讓測試的深度不斷前進 測試涵蓋率 別期望一開始就寫好所有測試案例，最好的測試，就是 增量測試 測試左移 大多數採用Unit Test居多，整合測試比較少，整合測試 與UI測試是相當消耗資源的
- 45. Continuous Delivery 審核程序 生產環境的佈署，需要透過審核才可以佈署到正式環境 排程發布 部分佈署需要在非工作時間進行，可透過排程的方式佈 署系統 自動化佈署 佈署過程中，除非必要，不然人員都不可以介入 Database的CD 自動產生佈署的SQL Script，再透過人員手動執行Script 45 Container從測試的Host，直接搬移到生產環境Host。僅 透過Docker-Compose File轉換環境變數 Docker環境移轉
- 46. 46 Release Release 採用流程圖的設計方式呈現 視覺化方式建立Release Flow 同時可平行處理多個佈署流程
- 48. 48 Release & Deploy 不同處 Release: 工程需求 & 開發需求 Deploy: 商業需求 排程發布 並非所有系統都能即時發布到生產環境，必要時可以透過排程指定時間進行佈 署
- 49. 49 建立一個Repose，專門管理每個Container的Docker Compose檔案，由CD執 行Docker Compose檔案，不僅是啟動Container，也是作為Docker內應用程 式環境參數的切換 Docker-Compose 管理 UAT 和 PRD的Container運行環境是相同，藉由Compose變更系統啟動變數， 因此，不需要重新跑CI，僅需要轉移Host cUAs UAT to PRD
- 51. 51 系統監控資訊整合到Azure DevOps Service Dashboard。可透過Azure DevOps Service了解目前所有系統資訊狀況
- 53. 53 DevOps過程中，無論是Task建立或是分派，甚至是CI / CD流程的成功或失敗。 都要透過Notification即時通知團隊 Notifications 藉由Service hooks與第三方平台進行溝通，例如Microsoft Teams 或Slack， 將可以傳送通知到這些平台上 Service hooks Facebook
- 55. 55 透過 Azure DevOps Setting 內 Board 的 [Process] 的設定，可以修改 Story & Task Card 欄位，以符合團隊DevOps流程
- 56. 56 Cumulative Flow Diagram Velocity 可以依照工作項目數量或是Story Point繪製圖表 Velocity Diagram
- 57. 57 Burndown類型 • 工作項目數量 • 剩餘工作量 • 完成工作項目的總量 • 估計原始完成數量
- 58. 58 不在關注的 原因 不精準 每次預估時間都不精準 不精準 每次完成時間也不一定準 不重要 個人達標已經不是最重要，整個團隊交付並不達 標，對團隊交付速度並無好處
- 60. 評估團隊效率 衡量Story & Task 持續交付指標 D𝑒𝑙𝑖𝑣𝑒𝑟 𝐼𝑛𝑑𝑒𝑥 = 𝑇𝑜𝑡𝑎𝑙 𝐶𝑦𝑐𝑙𝑒 𝑇𝑖𝑚𝑒 𝑇𝑜𝑡𝑎𝑙 𝐿𝑒𝑎𝑑 𝑇𝑖𝑚𝑒
- 61. Other Features 模組化流程 將眾多CI & CD 流程中需要標準化，建立客製化模組 Azure DevOps CLI 如果不想用介面管理，也可以透過CLI指令方式管理，有 些功能必須透過CLI才可以達成 多樣性的Agent 藉由不同屬性的Agent，擴充佈署與建置可用性與彈性 Dashboards 針對想要管理的指標或狀態，建置團隊Dashboards，方便 了解團隊狀態 61 可以基於Azure DevOps上的數據資料建立相關性報告並 提供給Power BI使用 客製化查詢
- 63. 彈性化配置 地與雲 CI / CD 混合搭配 以產業面來說，並非所有系統都會在雲端，大多數還是在地端機房 可能因為資安考量，並不適合在地端進行CI者 CI所需要相依性套件在地端，但佈署在雲端 同時需要佈署雲端與地端 在不改動Pipeline下，需要做雲和地的彈性化佈署或是轉移
- 64. Agent Pool Microsoft-Host Agent 雲端Agent可以編譯任何平台的Application，如MAC Apps，你將不需要一台實 體MAC，就可以進行編譯 Self-Host Agent Agent可被安裝在任何一個作業系統平台，地端Agent運作不列入收費時間額度 64
- 68. 68 介面 & 功能改版速度 每三週一小改，每三個月一大改，會改善BUG也 會增加功能。但最痛苦是介面異動，往往會找不 到原本的功能，又或是整個操作習慣必須更改。 愛恨糾結的Preview功能 Preview功能會提升或是強化工具使用性，也會 讓整個DevOps流程更順暢，但是，有時候會出 現問題，且不一定有解，因此，又必須退回沒有 Preview的時候 網路品質 簡單說，網路異常或是任何狀況發生。基本上當 天就不需要工作了 團隊中有對岸成員 Azure DevOps Server的Region不得不放在香港， 但香港功能和Bug的更新與修復，想對於其他 Region慢 難懂的意外/錯誤訊息 在CI / CD Pipeline發生錯誤時，提供錯誤訊息， 常常會無法很直覺知道問題在那邊，只能說這是 要有經驗的人才可以容易快速解讀，不然，基本 上會被檯面上的資訊誤導方向 有時，你需要等待 當下你需要某某功能可能會沒有，只能自己找到 其他方案替代，又或是期待下次改版，會不會有 你要的功能 血淚史
- 71. THANK YOU FOR WATCHING! ANY QUESTIONS? FB : https://www.facebook.com/jaigi.kuo Mail : Jaigi.kuo@gmail.com