Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

[Agile Tour Hsinchu 2019] Our practice in the DevOps Process for Manufacture Company

932 views

Published on

DevOps雖然是一種文化,但文化建立時也必須透過一些規範與實踐,讓團隊流程能夠合作更順暢,
本次課程以講者本身在製造業為例,分享在DevOps團隊內,建立那些的規範讓能朝向DevOps
之路前進,且同時也能符合企業文化

Published in: Technology
  • Login to see the comments

[Agile Tour Hsinchu 2019] Our practice in the DevOps Process for Manufacture Company

  1. 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. 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. 3. Before starting 3 Agile Tour是在當地軟體開發社群中推廣 Agile Practice與Agile 經驗。 今日我將分享在製造業內實踐DevOps於企業內部IT開發團隊的經驗。 DevOps做法並無清楚定義對或錯,而是不斷從自己或是他人的經 驗與過程中,逐步修正這條道路。因此,與其只是知道DevOps, 不如邊做邊修正你的DevOps之路
  4. 4. DevOps的神鬼奇航 2017 4
  5. 5. 5 Contents 1 產業現狀 前言 2 訂定對於DevOps方向 DevOps啟動 3 發散與收斂 我們的實踐 4 評估團隊DevOps狀態 DevOps評估 5 總結
  6. 6. 前言
  7. 7. 製造業IT的宿命 IT屬於支援單位 關於資訊相關的服務永遠是IT的責任 IT人員的編制有一定的企業人數比例 維持企業營運的資訊需求永遠是IT的任務 製造業的系統間是盤根錯節,系統維運與開發的複雜度,不輸其他產業
  8. 8. 8 2 系統會有交付日期,但不會有脫離日期, 因此,系統都會不斷會有需求需要被完成 或是維護壓力 專案沒有終止日期 3 需求優先權,變化莫測 需求範圍大小,不易掌控或清晰 有時修改需求的優先權可能比正在開發新 功能更重要 市場變化大於計畫 4 每個需求範疇不見得大,但是會非常多 依需求開發與產品開發的行為模式是有所不同 系統很少會被終止維護或維運 需求導向,非產品導向 1 大型系統不多,但零星的系統卻是非常多, 且公司越久、系統累積量越多。維運壓力 高 系統眾多、維護成本高 製造產業IT現狀
  9. 9. 9 實踐Scrum開發 2012年就開始進行敏捷式開發的導入,而進行人員的培訓與實踐, 從無到有的不斷修正後,逐步發展一套還符合企業文化的Scrum 流程與作法,然而,Scrum確實帶來的效益,讓需求到成果交付, 可以不斷讓用戶知道並修正與用戶需求的差距,但對於這個產業 的現況來說似乎又缺少什麼
  10. 10. 10 1 3 2 開發與維運對於事情看法的角度不同 開發與維運對於目標的角度不同 角度不同 開發人力變成瓶頸 測試人力變成瓶頸 瓶頸 交付與佈署時間過長 某些時候用戶等待時間是長的 開發、系統變更和維運是會在一個Sprint同時發生且必須同 時處理 時間 Scrum外的問題
  11. 11. 如果開發敏捷了,維運是否也需要敏捷了!? 11
  12. 12. DevOps 啟動
  13. 13. DevOps 迷思 DevOps會讓專案加速完成? CI / CD就是DevOps主要的核心? DevOps可以取代Scrum? DevOps可以被當作執行一個專案方式來運作?n個月必須完成? 13
  14. 14. 14 什麼是DevOps DevOps可說是比Scrum更難被說明、被闡述的一種流程, 已經不僅是開發變革,更是整個團隊的改變。DevOps可以 說是一種團隊文化、團隊模式或是協同合作,但又不是一 種已經有標準公式化或套路的東西
  15. 15. 15 人 流程 工具 千萬不可人跟流程是配合工具的功能或流程特性,讓團隊去配合工 具進行DevOps,團隊文化與工作流程是整個DevOps核心 DevOps是持續向最終用戶交付價值的方式
  16. 16. 16 原則與方向 1 持續交付有價值的功能或協助我們 的用戶提升價值 2 縮短交付到用戶的週期,並持續交付 讓用戶可以提早反饋 3 發現問題、持續改善 4 系統思維,看見全貌 。擴展反饋循 環的範圍 5 能接受失敗並改善和持續不斷學習的 文化
  17. 17. 17 Lean的七大浪費 1.運輸浪費 2.動作浪費 3.加工浪費 4.不良浪費 5.等待浪費 6.過量生產 7.庫存浪費
  18. 18. 18 第一步 消除浪費 1 人員溝通的浪費 2 人工作業的浪費 3 開發流程的浪費 4 找尋問題原因過程的浪費 5 交付成果時程的浪費
  19. 19. 持續迭代、消弭障礙 19 在實踐DevOps流程中,找出困難點與缺失,進行改善。重新檢視成果與反饋後,再次改進,並且持 續積累這些小改善
  20. 20. 我們的實踐 發散與收斂 20
  21. 21. 雙軌並行 21 ◼ 習慣改變對於製造業是難度高且風險高的挑戰 ◼ 減少歷史包袱,降低團隊轉型的風險 ◼ 建立適合企業文化的DevOps流水線 ◼ 降低被舊包袱干擾程度 ◼ 不影響既有的開發與營運運作,確保運作依舊可以正常 ◼ 現有企業文化與流程加入DevOps元素,兩者相互調整
  22. 22. 容易轉型的類型 系統開發的屬性是比較容易進行實踐/轉型DevOps的團隊 類型
  23. 23. 23 1 3 2IT 部門 功能性部門,例如: Network Team, DBA Team Function Team 既有Scrum Team是一個虛擬團隊,分別包 含Develop Team, QA Team 和 PO Team成員, 隸屬三個部門三個主管 Original Team 開發與維運併在同一部門,且同時成員間 具有開發與維運角色,團隊不再區分開發 與維運指標,唯一指標就是讓團隊交付事 項提升 DevOps Team 組織結構
  24. 24. 24 最初想法 持續交付從另一個角度來看是使用最小單位交付產出。 其中可包含: 最小可接受的Backlog 最少可接受的測試完整度 最小交付的單位及最小產出或修改的程式碼 持續交付產出 交付時間延長,或延遲上線,認為就可以有 更多測試時間,認為這樣才是最完整。甚至, 認為要到達需求穩定不在變化時候,才是最 安全的交付點 交付時間延長 !=最安全的交付
  25. 25. 25 擁有敏捷開發精神的團隊是成功執行DevOps關鍵之一 培養敏捷開發流程與精神 變更原本Scrum的Sprint週期,由兩週縮短至一週 Sprint 週期變更 因為週期變短,所以必須更注重交付有價值的需求且 優先處理。Story的粒子大小足以影響佈署頻率與測試 時間 重新切割Story 大小 團隊演進 1 2 3
  26. 26. 26 開發成員與維運成員同屬一個團隊,並且,開發 人員同時也是維運人員,所有起點與延伸技術、 方法都從這開始 Dev + Ops=One 從需求到監控資訊,一律透明化,所有人都可以 知道全部資訊 資訊透明化 進行全面自動化,從整合、測試到佈署。能自動 化則自動化。 持續整合/ 佈署 4 5 6
  27. 27. 27 兩大關鍵點 ◼ 週期變更後,Story切割更可以關注於使用者真正想要或真正有價值的事 物執行,此外,當粒度變小,開會時程也會縮短、測試的時程也會縮短、 上線的頻率也可以增加。 ◼ Story 和 Task切割是整個我們執行DevOps過程與管理最重要的一環 Sprint 週期變更 ◼ 開發人員必須對自己程式碼負責,不在把程式碼品質好壞管控丟給QA ◼ 基於產業特性,降低開發人力與測試人力變成瓶頸站 ◼ 讓自動化測試變成可能 ◼ 團隊資源可以進行動態調配 ◼ 團隊同時具備因應解決各種層面問題的技術含量 Dev + Ops=One
  28. 28. 28 為了能達到快速佈署,系統架構必須拆解、解耦 類微服務 取消Story Point 、 預估時程…等,只看團隊Story & Task 的Lead Time & Cycle Time做為團隊效率指標 團隊評估指標 為了能快速從失敗中回復,以及持續性佈署與快速更新,降低 佈署頻率增加,而影響到用戶的使用 導入容器化 7 8 9
  29. 29. 29 DevOps衡量指標 今年Dora DevOps Reports提到四個重要衡量DevOps成熟指標
  30. 30. 30 無論怎樣團隊,其目標都必須與企業營運目標相同, 團隊目標若與企業目標差異過大,團隊將不易持續前 進或是改變 團隊目標須與企業目標一致 團隊的每個人思維都應該改變,並且成員互相扶持、 相信人人都可以被提升。團隊內的英雄主義是無法讓 團隊向前邁進 不追求英雄主義 資訊透明、互助合作,共同承擔成功與失敗。所有訊 息對於團隊成員必須為第一手消息 訊息透明化 團隊建置核心
  31. 31. 31
  32. 32. 32 ◼ 來自市場/商業的需求或是使用者 的需求。 ◼ 一個Sprint僅能佔團隊的80%動能 業務需求 (80%) ◼ 建構Infrastructure ◼ 系統的改善或重構項目 ◼ 一個Sprint僅能佔團隊的15~20%動能 工程需求 (20%) ◼ 商業與工程需求必須同時被管理與追蹤, 不能分散在其他看板或是不列入看板中 ◼ Story完成定義是必須上線到生產環境才 算完成 ◼ UI和UX的Story必須先行 ◼ 每個Sprint會定義Story優先權或是重新 排序 Story Flow Backlog
  33. 33. 33 ◼ 專案開發:歸屬到相對應的Story ◼ 日常維運: 日常維運的Task或是當 天或Sprint間非預期性的Task,也 必須放在同一個看板內管理 Task 類型 ◼ 粒度是獨立一人且能在當天完成 為主的大小 ◼ 團隊能合力完成Sprint內所有的 Task Task 切割 ◼ Planning Meeting列出Story Task ◼ 有缺漏的Task,日常時間填補, 並在Daily Meeting說明 Task 列表 Task
  34. 34. 34 ◼ 建立符合專案需求的Branch 。 ◼ 建立Branch合併策略,情境與需 求差異的不同,分支切割與合併 策略也會有差異 建立分支 ◼ 無論是修改或是新增的Code,每 次程式碼Check In都必須與Task或 是Story關聯起來 連結工作項目 ◼ 只要是程式碼或是第三方軟體都 要納入版控,如: Database。 ◼ 系統Infrastructure設定、應用程式 環境變數…等,甚至自動化腳本, 都必需納入版控 版控類型 版本控制
  35. 35. 35 ◼ 先利用手動方式跑過流程後,確認可執行,才會建立CI / CD流 水線 ◼ 80%自動化效益大於100%自動化 ◼ 多次以上需要人工處理的流程或是多次處裡都需要花大量時間, 就必須透過自動化 ◼ 每次運行CI的時間不能太長 ◼ CI / CD 也可作為交付流程的標準化通道與最後交付的把關者 流水線 當我們可以開始如何加快我們的佈署速度,我們將可以有更多的 時間來減少問題或更快的時間完成商業需求,並更快提供商業價 值給你們。同時,若是,進行小批量的完成佈署,我們可以快速 測試且驗證,並且從驗證中得到知識和問題,下一次更新進行改 善,我們不僅可以專注的工作,了解我們正在開發的功能正確性 或是在必要時候進行調整。最後,透過不斷反饋資訊進行修改, 符合商業需求及組織創新 自動化好處 CI / CD Pipeline
  36. 36. 36 ◼ 系統拆分到耦合性最小,建立共 用性元件或是核心元件 ◼ 團隊能共享或是重複使用相同元 件 ◼ 增加可被測試的機會 系統拆解 ◼ 當系統擴大,編譯時間就會越長, 每次編譯必須拉下所有程式碼, 拉下程式碼又隨著系統越大越耗 費時間,會讓整個CI變慢,循環 回饋也變慢 降低CI / CD 時間 ◼ 每個團隊或個人開發的功能可以 被快速迭代且又不影響他人 ◼ 多團隊下讓團隊擁有自主權。耦 合性降低時,在於持續整合方面 也將會讓速度加快且更好釐清問 題 元件化 解耦合
  37. 37. 37 ◼ 工程需求 ◼ 開發需求 ◼ 開發與測試完畢,則可以做為 Release版本,等待發布 Release ◼ 商業需求 ◼ 有些情況的佈署,是必須等到產 線停線或是維修才可以進行 Deploy ◼ 生產製造系統 ◼ OA系統 ◼ 核心系統,例如: ERP、MES Core 製造業適合高頻佈署嗎? Release vs. Deploy
  38. 38. 38 16 34 25 自動化是測試的關鍵 單元測試、整合測試、UI測試 到負載平衡測試是屬於持續測 試一環 使用增量和迭代方式,讓測試 的深度不斷前進 針對主要核心功能或是可被共用的元件或 平台鮮寫測試,而非所有專案的所有程式 碼都一定要先撰寫測試案例 是否合適用TDD方式開發 最好的測試方式,就是增量測 試 別期望一開始就寫好所有測試 案例 測試 Testing: Shift Left from Integration to Unit
  39. 39. 39 基於現狀與情境,並不適合先寫測 試。如果有寫,也先針對主要核心 功能或是可被共用的元件或平台鮮 寫測試,而非所有專案的所有程式 碼都一定要先撰寫測試案例 如果沒有先開始寫測試 目前作法是透過 監控+ Change Fail速 度來克服此問題,前提是這些Bug並 非是核心功能或是無法讓使用者繼 續使用系統的功能 如果測試不完全,有Bug.. 測試過程中,發現許多Bug,團隊是 否要繼續衝刺需求,還是需要停下 來。這是時候就要考慮Bug Cap 如果測試過程,發現Bug.. 關於測試
  40. 40. 40 監控與持續學習 這是最重要,但也是最花時間且最難被 實踐的一部份,製造業推行DevOps過 程中,監控可以是最需要優先被導入, 且有助於DevOps過程的推進
  41. 41. 41 16 34 25 系統任何錯誤或是異常資訊皆須回饋 且被記錄 系統效能與資料進出資訊都必須監控 監控資料必須能被作數據分析 團隊隨時隨地可接收問題的反饋 分析用戶使用行為,不僅挖掘潛在需求, 也可以分析系統隱藏的問題 瞭解使用者如何使用系統 所有的訊息必須公開透明且對團隊都 是第一手訊息 監控與持續學習 若是做得好,將有助於降低維運壓力,透過數據解釋維運
  42. 42. DevOps 評估 42
  43. 43. 44 1 已經不該只關注個人對於專案的投入時程 且維運時程會影響個人對於專案的消耗, 造成個人Capacity是不易預估 Personal Capacity 2 不在只是注重完成或是消耗Story的曲線表, 因此,這些指標相對性意義只能做為參考 或是忽略 Burndown / Velocity 3 Task花費的時間可能會因為臨時要做維運 的工作被拉長,因此,作為指標也不準確 花多久時間完成 4 開發與維運同時在一個Sprint發生,通常 個人預估Task的完成時間,已經相對不 準確且相對不重要 預估完成時間 取消的一些指標 Sprint期間
  44. 44. 45 評估團隊 交付時間 從開發到維運,一切都是以團隊做為考量基 準,因此開發與維運的目標,都是要讓團隊 的動能提高 D𝑒𝑙𝑖𝑣𝑒𝑟 𝐼𝑛𝑑𝑒𝑥= (𝑇𝑜𝑡𝑎𝑙 𝐶𝑦𝑐𝑙𝑒 𝑇𝑖𝑚𝑒)/(𝑇𝑜𝑡𝑎𝑙 𝐿𝑒𝑎𝑑 𝑇𝑖𝑚𝑒) Story Cycle Time Task Cycle Time Story Lead Time Task Lead Time
  45. 45. 總結
  46. 46. 需要學什麼技術 文化轉變過中,相對應的技術會油然而生 DevOps是進行式 CI / CD 不是全部 擁有 CI / CD不等於已經是一個DevOps團隊 DevOps標準框架 DevOps不會限制團隊必須一定遵守什麼方式或理論進 行軟體開發,或是制定的所謂DevOps標準 循序推進 從小團隊、小專案開始推進、以能優先解決問題的專 案開始,找出合適團隊方法與流程,發現問題,即時 改善 消弭障礙 藉由學習與觀察,發現流程中的浪費,可藉由流程改善 或工具導入,進而解決。找出困難點,進行改善,並重 新檢視與檢討後,再次改進。持續累加這些小改善
  47. 47. 48 佈署頻率 可以佈署到生產環境頻率 實際佈署到生產環境頻率
  48. 48. 49 商業/技術限制 佈署頻率遭到商業因素或是技術因素, 導致持續佈署頻率失效的比例
  49. 49. 50 製造業邁入 DevOps ◼ 新專案、新系統,或新團隊開始導入DevOps流程 ◼ 系統架構盡量是低耦合。若許可,架構最好能重新設計或是改善 ◼ 自動化是理想,但並不實際 ; 80% 自動化,20% 人工作業較為合理 ◼ 不要因DevOps工具的流程而建立團隊DevOps流程 ◼ 開發人員與維運人員心態都要轉變 導入模式 人的心態永遠是影響最大的因素 一定會被「舊」系統羈絆著,但必須逐步改善 部門間自認為的指標問題 先有敏捷的「精神」,再有敏捷的「流程」,最後DevOps的「合作模式」 DevOps不會讓專案加速,有時候反而變慢,但是使用者感受會變好 Top-Down & Bottom-Up 最好都能支持 提醒要點
  50. 50. Thank you for watching! Any questions? Blog: medium.com/ek-technology E-mail: Jaigi.kuo@gmail.com FB: www.facebook.com/jaigi.kuo

×