[Agile Tour Hsinchu 2019] Our practice in the DevOps Process for Manufacture Company
•
6 likes•556 views
DevOps雖然是一種文化，但文化建立時也必須透過一些規範與實踐，讓團隊流程能夠合作更順暢， 本次課程以講者本身在製造業為例，分享在DevOps團隊內，建立那些的規範讓能朝向DevOps 之路前進，且同時也能符合企業文化
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to [Agile Tour Hsinchu 2019] Our practice in the DevOps Process for Manufacture Company
Similar to [Agile Tour Hsinchu 2019] Our practice in the DevOps Process for Manufacture Company (20)
More from Edward Kuo
[Agile Tour Hsinchu 2019] Our practice in the DevOps Process for Manufacture Company
- 1. Our Practice In The DevOps Process For Manufacture Agile Tour Hsinchu 2019 Edward Kuo Kingston IT Manager| Microsoft Regional Director| Microsoft Azure MVP
- 2. About Edward Kuo 是開發者、架構師也是團隊的管理者， 也 是 小 小 部 落 客 、 技 術 講 師 與 DevOps學習者 2 ◼ Kingston Technology 資訊處 經理 ◼ 前 友達光電資訊處 工程副理 ◼ Microsoft Regional Director ◼ Microsoft Azure MVP ◼ Certified Scrum Developer ◼ Certified Scrum Master ◼ Certified Product Owner ◼ 2019 台灣 恩智浦半導體 DevOps 培訓講師 ◼ 2019 中原大學 資料科學實務 客座講師 ◼ 2019 .NET Conf Taipei 講師 ◼ 2019 中原大學 資工系 雲端計算平台實務 客座講師 ◼ 2019 DevOps Days Taipei 講師 ◼ 2019 DevOps Expo @Trend Micro 講師 ◼ 2019 翻轉營運契機 Azure DevOps 趨勢與實務研討會 講師 ◼ 2019 Insider Dev Tour 台北站 講師 ◼ 2018 DevOps Days Taipei 講師 ◼ 2018 DOIS DevOps 國際峰會 深圳站 講師 ◼ 2018 Insider Dev Tour 台北站 講師 ◼ 2018 .NET Core Conf 台北站 講師 ◼ 2018 Agile Tour Taichung 講師 ◼ Global Azure Bootcamp 台灣 & 廣州 講師
- 3. Before starting 3 Agile Tour是在當地軟體開發社群中推廣 Agile Practice與Agile 經驗。 今日我將分享在製造業內實踐DevOps於企業內部IT開發團隊的經驗。 DevOps做法並無清楚定義對或錯，而是不斷從自己或是他人的經 驗與過程中，逐步修正這條道路。因此，與其只是知道DevOps， 不如邊做邊修正你的DevOps之路
- 6. 前言
- 12. DevOps 啟動
- 13. DevOps 迷思 DevOps會讓專案加速完成? CI / CD就是DevOps主要的核心? DevOps可以取代Scrum? DevOps可以被當作執行一個專案方式來運作?n個月必須完成? 13
- 16. 16 原則與方向 1 持續交付有價值的功能或協助我們 的用戶提升價值 2 縮短交付到用戶的週期，並持續交付 讓用戶可以提早反饋 3 發現問題、持續改善 4 系統思維，看見全貌 。擴展反饋循 環的範圍 5 能接受失敗並改善和持續不斷學習的 文化
- 20. 我們的實踐 發散與收斂 20
- 21. 雙軌並行 21 ◼ 習慣改變對於製造業是難度高且風險高的挑戰 ◼ 減少歷史包袱，降低團隊轉型的風險 ◼ 建立適合企業文化的DevOps流水線 ◼ 降低被舊包袱干擾程度 ◼ 不影響既有的開發與營運運作，確保運作依舊可以正常 ◼ 現有企業文化與流程加入DevOps元素，兩者相互調整
- 23. 23 1 3 2IT 部門 功能性部門，例如: Network Team, DBA Team Function Team 既有Scrum Team是一個虛擬團隊，分別包 含Develop Team, QA Team 和 PO Team成員， 隸屬三個部門三個主管 Original Team 開發與維運併在同一部門，且同時成員間 具有開發與維運角色，團隊不再區分開發 與維運指標，唯一指標就是讓團隊交付事 項提升 DevOps Team 組織結構
- 27. 27 兩大關鍵點 ◼ 週期變更後，Story切割更可以關注於使用者真正想要或真正有價值的事 物執行，此外，當粒度變小，開會時程也會縮短、測試的時程也會縮短、 上線的頻率也可以增加。 ◼ Story 和 Task切割是整個我們執行DevOps過程與管理最重要的一環 Sprint 週期變更 ◼ 開發人員必須對自己程式碼負責，不在把程式碼品質好壞管控丟給QA ◼ 基於產業特性，降低開發人力與測試人力變成瓶頸站 ◼ 讓自動化測試變成可能 ◼ 團隊資源可以進行動態調配 ◼ 團隊同時具備因應解決各種層面問題的技術含量 Dev + Ops=One
- 28. 28 為了能達到快速佈署，系統架構必須拆解、解耦 類微服務 取消Story Point 、 預估時程…等，只看團隊Story & Task 的Lead Time & Cycle Time做為團隊效率指標 團隊評估指標 為了能快速從失敗中回復，以及持續性佈署與快速更新，降低 佈署頻率增加，而影響到用戶的使用 導入容器化 7 8 9
- 29. 29 DevOps衡量指標 今年Dora DevOps Reports提到四個重要衡量DevOps成熟指標
- 31. 31
- 32. 32 ◼ 來自市場/商業的需求或是使用者 的需求。 ◼ 一個Sprint僅能佔團隊的80%動能 業務需求 (80%) ◼ 建構Infrastructure ◼ 系統的改善或重構項目 ◼ 一個Sprint僅能佔團隊的15~20%動能 工程需求 (20%) ◼ 商業與工程需求必須同時被管理與追蹤， 不能分散在其他看板或是不列入看板中 ◼ Story完成定義是必須上線到生產環境才 算完成 ◼ UI和UX的Story必須先行 ◼ 每個Sprint會定義Story優先權或是重新 排序 Story Flow Backlog
- 33. 33 ◼ 專案開發：歸屬到相對應的Story ◼ 日常維運: 日常維運的Task或是當 天或Sprint間非預期性的Task，也 必須放在同一個看板內管理 Task 類型 ◼ 粒度是獨立一人且能在當天完成 為主的大小 ◼ 團隊能合力完成Sprint內所有的 Task Task 切割 ◼ Planning Meeting列出Story Task ◼ 有缺漏的Task，日常時間填補， 並在Daily Meeting說明 Task 列表 Task
- 34. 34 ◼ 建立符合專案需求的Branch 。 ◼ 建立Branch合併策略，情境與需 求差異的不同，分支切割與合併 策略也會有差異 建立分支 ◼ 無論是修改或是新增的Code，每 次程式碼Check In都必須與Task或 是Story關聯起來 連結工作項目 ◼ 只要是程式碼或是第三方軟體都 要納入版控，如: Database。 ◼ 系統Infrastructure設定、應用程式 環境變數…等，甚至自動化腳本， 都必需納入版控 版控類型 版本控制
- 35. 35 ◼ 先利用手動方式跑過流程後，確認可執行，才會建立CI / CD流 水線 ◼ 80%自動化效益大於100%自動化 ◼ 多次以上需要人工處理的流程或是多次處裡都需要花大量時間， 就必須透過自動化 ◼ 每次運行CI的時間不能太長 ◼ CI / CD 也可作為交付流程的標準化通道與最後交付的把關者 流水線 當我們可以開始如何加快我們的佈署速度，我們將可以有更多的 時間來減少問題或更快的時間完成商業需求，並更快提供商業價 值給你們。同時，若是，進行小批量的完成佈署，我們可以快速 測試且驗證，並且從驗證中得到知識和問題，下一次更新進行改 善，我們不僅可以專注的工作，了解我們正在開發的功能正確性 或是在必要時候進行調整。最後，透過不斷反饋資訊進行修改， 符合商業需求及組織創新 自動化好處 CI / CD Pipeline
- 36. 36 ◼ 系統拆分到耦合性最小，建立共 用性元件或是核心元件 ◼ 團隊能共享或是重複使用相同元 件 ◼ 增加可被測試的機會 系統拆解 ◼ 當系統擴大，編譯時間就會越長， 每次編譯必須拉下所有程式碼， 拉下程式碼又隨著系統越大越耗 費時間，會讓整個CI變慢，循環 回饋也變慢 降低CI / CD 時間 ◼ 每個團隊或個人開發的功能可以 被快速迭代且又不影響他人 ◼ 多團隊下讓團隊擁有自主權。耦 合性降低時，在於持續整合方面 也將會讓速度加快且更好釐清問 題 元件化 解耦合
- 37. 37 ◼ 工程需求 ◼ 開發需求 ◼ 開發與測試完畢，則可以做為 Release版本，等待發布 Release ◼ 商業需求 ◼ 有些情況的佈署，是必須等到產 線停線或是維修才可以進行 Deploy ◼ 生產製造系統 ◼ OA系統 ◼ 核心系統，例如: ERP、MES Core 製造業適合高頻佈署嗎? Release vs. Deploy
- 38. 38 16 34 25 自動化是測試的關鍵 單元測試、整合測試、UI測試 到負載平衡測試是屬於持續測 試一環 使用增量和迭代方式，讓測試 的深度不斷前進 針對主要核心功能或是可被共用的元件或 平台鮮寫測試，而非所有專案的所有程式 碼都一定要先撰寫測試案例 是否合適用TDD方式開發 最好的測試方式，就是增量測 試 別期望一開始就寫好所有測試 案例 測試 Testing: Shift Left from Integration to Unit
- 39. 39 基於現狀與情境，並不適合先寫測 試。如果有寫，也先針對主要核心 功能或是可被共用的元件或平台鮮 寫測試，而非所有專案的所有程式 碼都一定要先撰寫測試案例 如果沒有先開始寫測試 目前作法是透過 監控+ Change Fail速 度來克服此問題，前提是這些Bug並 非是核心功能或是無法讓使用者繼 續使用系統的功能 如果測試不完全，有Bug.. 測試過程中，發現許多Bug，團隊是 否要繼續衝刺需求，還是需要停下 來。這是時候就要考慮Bug Cap 如果測試過程，發現Bug.. 關於測試
- 42. DevOps 評估 42
- 44. 44 1 已經不該只關注個人對於專案的投入時程 且維運時程會影響個人對於專案的消耗， 造成個人Capacity是不易預估 Personal Capacity 2 不在只是注重完成或是消耗Story的曲線表， 因此，這些指標相對性意義只能做為參考 或是忽略 Burndown / Velocity 3 Task花費的時間可能會因為臨時要做維運 的工作被拉長，因此，作為指標也不準確 花多久時間完成 4 開發與維運同時在一個Sprint發生，通常 個人預估Task的完成時間，已經相對不 準確且相對不重要 預估完成時間 取消的一些指標 Sprint期間
- 45. 45 評估團隊 交付時間 從開發到維運，一切都是以團隊做為考量基 準，因此開發與維運的目標，都是要讓團隊 的動能提高 D𝑒𝑙𝑖𝑣𝑒𝑟 𝐼𝑛𝑑𝑒𝑥= (𝑇𝑜𝑡𝑎𝑙 𝐶𝑦𝑐𝑙𝑒 𝑇𝑖𝑚𝑒)/(𝑇𝑜𝑡𝑎𝑙 𝐿𝑒𝑎𝑑 𝑇𝑖𝑚𝑒) Story Cycle Time Task Cycle Time Story Lead Time Task Lead Time
- 46. 總結
- 47. 需要學什麼技術 文化轉變過中，相對應的技術會油然而生 DevOps是進行式 CI / CD 不是全部 擁有 CI / CD不等於已經是一個DevOps團隊 DevOps標準框架 DevOps不會限制團隊必須一定遵守什麼方式或理論進 行軟體開發，或是制定的所謂DevOps標準 循序推進 從小團隊、小專案開始推進、以能優先解決問題的專 案開始，找出合適團隊方法與流程，發現問題，即時 改善 消弭障礙 藉由學習與觀察，發現流程中的浪費，可藉由流程改善 或工具導入，進而解決。找出困難點，進行改善，並重 新檢視與檢討後，再次改進。持續累加這些小改善
- 50. 50 製造業邁入 DevOps ◼ 新專案、新系統，或新團隊開始導入DevOps流程 ◼ 系統架構盡量是低耦合。若許可，架構最好能重新設計或是改善 ◼ 自動化是理想，但並不實際 ; 80% 自動化，20% 人工作業較為合理 ◼ 不要因DevOps工具的流程而建立團隊DevOps流程 ◼ 開發人員與維運人員心態都要轉變 導入模式 人的心態永遠是影響最大的因素 一定會被｢舊｣系統羈絆著，但必須逐步改善 部門間自認為的指標問題 先有敏捷的｢精神｣，再有敏捷的｢流程｣，最後DevOps的｢合作模式｣ DevOps不會讓專案加速，有時候反而變慢，但是使用者感受會變好 Top-Down & Bottom-Up 最好都能支持 提醒要點
- 51. Thank you for watching! Any questions? Blog: medium.com/ek-technology E-mail: Jaigi.kuo@gmail.com FB: www.facebook.com/jaigi.kuo