導讀持續交付 2.0 - 談當代軟體交付之虛實融合

新竹敏捷社群 Meetup

Date: 2019/04/27
Title: 導讀持續交付 2.0 - 談當代軟體交付之虛實融合
Location: 交大工程三館

Blog: https://rickhw.github.io/2019/04/27/DevOps/Introduce-to-Continuous-Delivery-2/
Youtube Playlist: https://www.youtube.com/playlist?list=PL63J1r2PBvohTyGQ7pqAwVEogospMOJ5v

Transcript

1. 導讀持續交付 2.0 談當代軟體交付 之 虛實融合 Rick Hwang 2019/04/27 1 Agile Hsinchu 四月聚會
2. Agenda 一、當代軟體交付面對的問題 二、持續交付 2.0 摘要與導讀 三、從個人開始 四、持續交付與 DevOps
3. 3 Rick Hwang https://www.gtcafe.com • Sr. Manager @ 91APP • 經營管理 • Cloud / AWS / GCP • DevOps / SRE • Distributed Systems • 音樂 吉他 鍵盤 編曲 • 哲學 科幻 金庸 喇賽
4. 調查 4 • 在新竹工作？ • 不是新竹的朋友？ • 開發（寫商業需求）？ • 測試？ • 維運？SRE、DevOps？ • 產品經理、專案經理？
6. 6 一、當代軟體交付面對的 問題 廿一世紀已經過了 十九年的今天 ...
7. 7 https://zh.wikipedia.org/wiki/%E4%B8%89%E4%BD%93%E9%97%AE%E9%A2%98
8. 8 人 (組織) 物 (工程) 事 (業務)
9. 9 人 (組織) 物 (工程) 事 (業務)
10. • 基礎架構：雲端與地端、混合雲、原生雲 (天然雲) ◦ 治理、成本 ◦ 資安、維運 • 全球化的需求：分散式架構、微服務 ◦ 一致性、通訊協議 ◦ 可靠性、規模化 ◦ 巨量資料 當代軟體工程要面對的 10
11. 11 Source: https://www.awsgeek.com/images/Periodic-Table-of-Amazon-Web-Services.png
12. 12 Source: https://xebialabs.com/periodic-table-of-devops-tools/
13. 13 Source: https://landscape.cncf.io/fullscreen=yes&zoom=80
14. 14 可擴展 效率化 複雜度 可靠度 複雜度 效率化
15. 工程的核心問題 • 管理：技術決策、一致性、效率化、成本 • 複雜度：可控性、可擴展、可靠度 15 複雜度
16. 分散式微服務單體架構 16
18. 18 人 (組織) 物 (工程) 事 (業務)
19. 19 錢 (生存) ？ 一個人
20. 20 錢 成就 成長 參考來源：極客時間 面試現場 專欄 一個人
21. 21 錢 (生存) 共同 目標 一群人
22. 22 目標 成就 成長
23. 23 http://bonkersworld.net/organizational-charts 有人的地方就有江湖
24. 24 目標 成就 成長
25. 25 錢 (生存) 一個人和一群人 技能、方法 共識標準 溝通方式 透明程度 價值觀 ... 問題與衝突 目標 成就 成長
26. 26 錢 (生存) 一個人和一群人 信任基礎 開放心胸 溝通機制 連結 目標 成就 成長
27. 27 錢 成就 成長 參考來源：極客時間 面試現場 專欄 個人
29. • 團隊 ◦ 溝通成本 ◦ 訊息一致性 • 文化 ◦ 信任 ◦ 開放 ◦ 價值 • 目的：共識與一致性 • 問題：協作效率 組織問題 29 協作效率
31. 31 人 (組織) 物 (工程) 事 (業務)
32. • 市場是 VUCA ◦ Volatility（易變性） ◦ Uncertainty（不確定性） ◦ Complexity（複雜性） ◦ Ambiguity（模糊性） • 客戶要的是什麼？ ◦ 客戶要的更多了 ◦ 市場變化更快了 ◦ 產品解決客戶什麼問題？ • 問題：混屯的需求與市場 • 目標：成事 • 目的：價值 業務問題 32 價值
33. Rick 接下來要賣哪一本書？ 33
34. 解決問題 35 創 價值
35. 一些觀察到的現象 36
36. 一個問題， 需要問很多團隊、部門之後 才能看到一點點樣貌， 甚至是還不知道狀況 37 組織問題 最嚴重的問題： 1. 大家不覺得這是問題 2. 高層、老鳥一笑置之
37. 公司看起來不錯， 每天上班都很開心（馬照跑、舞照跳）， 但是東西都賣不出去，沒有訂單 老闆一樣每天進來公司 38 業務問題 最嚴重的問題： 1. 這家公司沒目標 2. 老闆是來交朋友的
38. 看起來很小的功能問題， 但是要花很多時間才能解決 類似的問題一再發生 只有某個人知道怎麼做 39 工程問題 最嚴重的問題： 1. 大家都心照不宣 2. 不覺得那是問題
39. 協作、共識 技術管理 複 雜 度 (康 威 定 律 ) x y z Business (Products) Teams (Organization) Engineering (Architecture) https://rickhw.github.io/2019/03/17/Management/Perspective-in-XYZT/ 人 事 物
40. 41 人 (組織) 物 (工程) 事 (業務) 軟體交付的三體問題
41. 工程技術服務 業務 連結兩者的是 團隊 解決問題，創 價值 42
42. 43 人 (組織) 物 (工程) 事 (業務) 科學、技術 架構、數據 文化、信任 連結、希望 需求、商業 未來、方向
44. 45 Agile Hsinchu 四月聚會 二、持續交付 2.0 摘要與導讀
45. 書本整理 個人見解 46 87% 13%
48. 軟體交付的概念 49 • 任何人都可以部署任意版本，到特定環境 ◦ 任何人：開發、測試、支援、維運、業務、老闆、老闆的老闆、掃地的 ◦ 可以部署：be able to -- one button ◦ 任意版本：Artifacts、Configure ◦ 特定環境：Production、Sandbox • 部署流水線 (Pipeline) 也要被測試、優化、監控、維護 (Ops Pipeline) ◦ 部署程式也是程式，要可以在 Local 開發、測試 ◦ Pipeline: Build, Provisioning, Deployment, AutoTasks (Test, Backup …)
50. 任何人都 可以 52 到 特定環境 (包含建置) 部署任意版本
53. 建議閱讀 • 團隊：Developer、QA、SRE • 管理者：Manager、PO • 經營者：CxO、VP、Director 55
54. 56 業 務 工 程 個 人 想 法 與 見 解
55. 底下圖文介紹 部分引用 Ruddy 老師的整理 58
56. 持續交付2.0以業務為導向 需要各團隊之間緊密合作，減少浪費的同時，縮短“8”字環的週期 業 務
57. 第4章 持續交付2.0的組織文化 第5章 持續交付的軟件系統架構 第6章 業務需求協作管理 第7章 部署流水線原則與工具設計 第8章 利於集成的分支策略 第9章 持續集成 第10章 自動化測試策略與方法 第11章 軟件配置管理 第12章 低風險發布 第13章 監測與決策 附錄A 軟件工程的三次進化 附錄B 排序法做相對估算 七巧板三大主要板塊 的工作原則與實踐 價值探索環 快速驗證環 概述持續交付 2.0 實戰案例分析 I II III （1）堅持少做 （2）持續分解工作 （3）堅持快 回饋 （4）持續改善並衡量 第1章 持續交付2.0 第2章 價值探索環 第3章 快 驗證環 第14章 大型互聯網團隊的FT化 第15章 小團隊逆襲之旅 第16章 研發推動的DevOps 核心工作原则
58. WE ARE HERE! 我們在哪里? 问题是什么?
59. 價值探索 快 驗證
60. 快 驗 證
61. 價值探索 快 驗 證 識別及定義業務問題， 並制定出最小可行解決方案。 探索環目的:
62. 探索環 Discovery Loop 是指團隊通過一系列工作環節，能夠識別和定義業務問題， 制定相應的衡量指標，並找出低成本且可快 驗證的最小可行解決方案 Minimum Viable Solution。這是一個理解真實需求、判斷優先順序、再評價需求的過程。 四個關鍵環節 65
63. 四個關鍵環節 66 一、 提問：通過有針對性的提問與討論，找出團隊期望達成的業務目標或者希望 解決的業務本質問題。 二、 錨定：針對該問題進行資訊收集，經過分析，去除干擾資訊，得到適當的 指標項，並用其描述現在的狀況，以及我們希望的結果。 三、 共創：通過深入討論，找到列出所有可能的解決方案。它是一個深入理解和 驗證問題的環節。 四、 精煉：結合實際情況，進行評估，篩選出最小可行性解決方案或方案的集合， 以作為驗證環的輸入。並等待它的真實回饋，再做價值判斷。
64. 量化式影響地圖 量化式影響地圖是在影響地圖的基礎上，通過增加量化因數，從而 提醒團隊成員該解決方案可能對哪些價值指標產生影響。 Page 20
65. 個 人 想 法 與 見 解 68 現實 理想 我們想的 客戶要的 問題是什麼？ 所有的功能 有在用的功能
66. 69 Source: 頂尖業務 vs. 平凡業務 個 人 想 法 與 見 解
67. 個 人 想 法 與 見 解 70 TED: 人們不會買你買什麼；他們買你的為什麼 (08:24 - 11:06)
68. 產品的風險假設 71 • 用戶假設：提供的產品針對某些潛在用戶人群的需求假設 • 問題假設：目標用戶存在痛點需要解決的假設 • 解決方案：提供解決方案可以解決這些痛點貨問題
69. 72 Source: https://www.continuousdelivery20.com/%E5%AE%9E%E8%B7%B5%E6%96%B9%E6%B3%95%E7%AF%87 重點：提早收到回饋，提早修正 分解並快 試錯
70. 價值探索 快 驗證 識別及定義業務問題， 並制定出最小可行解決方案。 探索環目的: 是以最快速度交付最小可行方案， 並可靠的收集真實回饋， 並分析及驗證業務問題的解決效果。 驗證環目的: 最小可行方案
71. 價值探 索 快 驗證 是以最快速度交付最小可行方案， 並可靠的收集真實回饋。 驗證環目的:
73. 第4章 持續交付2.0的組織文化 第5章 持續交付的軟件系統架構 第6章 業務需求協作管理 第7章 部署流水線原則與工具設計 第8章 利於集成的分支策略 第9章 持續集成 第10章 自動化測試策略與方法 第11章 軟件配置管理 第12章 低風險發布 第13章 監測與決策 附錄A 軟件工程的三次進化 附錄B 排序法做相對估算 I II III （1）堅持少做 （2）持續分解工作 （3）堅持快 回饋 （4）持續改善並衡量 第1章 持續交付2.0 第2章 價值探索環 第3章 快 驗證環 第14章 大型互聯網團隊的FT化 第15章 小團隊逆襲之旅 第16章 研發推動的DevOps 核心工作原则
74. • 價值觀 (Values)、使命 (Mission)、願景 (Vision) • 價值觀是什麼？ 組織文化 (企業文化) 是什麼？ 78
75. 尊重、認同、踏實、誠信、當責、責任、專業、影響、 積極、樂觀、愛、信仰、信任、果斷 79
76. 行為決定文化 80 • 尊重員工 • Facebook：沒有什麼問題是別人的問題 • 豐田：Stop-the-line Ando (安燈系統) • Google: 品質文化 老闆、主管的行為 決定文化
77. 塑 文化四步法 81 第一步: 定義我們想要做的事 第二步: 定義我們期望的做事方式或方法 第三步: 提供相應的培訓，使員工具備完成其工作的能力 第四步: 設計一些必要的機制或措施來強化我們所鼓勵的那些行為 -- 讓員工成功掌握自己工作的方法，進而改變企業文化。 《 精益企業 》 - Page 48, From : Jez Humble & Joanne Molesky
79. 持續交付的軟體架構 • 架構的要求 • 常見的架構模式 • 如何改 架構 • 架構跟組織 84
80. 架構要求 • design for test • design for deployment • design for monitor • design for scale • design for faliure 85
81. 拆分原則 • 大系統小做 • 每個組件或服務都要有清晰的職責定義，職責分離 • 『高內聚、低耦合』，讓系統容易維護，減少需要通訊 • 系統容易建構與測試 • 團隊成員溝通更加順暢 86
82. 常見架構模式 - Microcore Architecture • 又稱 Plugin Architecture • Eclipse、VSCode、Firefox、Chrome、 Mobile App • 優點： ◦ 良好的延展性 (Extensibility) ◦ 容易發布 ◦ 容易測試，隔離性佳 ◦ 可以漸進式開發、逐步增加功能 • 缺點： ◦ 擴展性差 (Scability)，不適合分散式系統 ◦ 開發難度高 ◦ 高度依賴框架 87
83. 常見架構模式 - Monolithic Architecture • 獨立完整的體系 • 優點： ◦ 利於開發與整合測試 ◦ 架構簡單 ◦ 部署簡單 ◦ 容易擴展 • 缺點： ◦ 對整體要熟悉，否則容易 污染整個應用 ◦ 很難與新技術共存 ◦ 只能維持整體的擴展 ◦ 持續部署很困難 88
84. 常見架構模式 - Microservices Architecture • 單一應用劃分成的小服務，透過彼 此的協作、通訊等機制，達到整體運 作 • 優點： ◦ 擴展性佳，服務之間低耦合、高 內聚 ◦ 容易部署、開發 ◦ 容易單獨驗證 • 缺點： ◦ 原子性操作變得複雜 (2PC) ◦ 網路通訊消耗大 ◦ 服務複雜，除錯不易 ◦ 測試時需要部署多個服務 ◦ 共用函式庫管理問題 89
85. 如何改 既有的架構 90 模式 優點 缺點 案例 拆遷者模式 與舊版沒有瓜葛 沒有歷史包袱 可以依照預期進行架構設計 業務需求遺漏 市場環境變化 人力資源消耗大 閉門 車 成功：HP 雷射印表機韌體架構改 ，耗時 3 年 失敗：Netscape 改 企業軟體， 被微軟 IE 趕上 絞殺者模式 不會遺漏原有需求 可穩定地提供價值 避免閉門 車 改 時間的跨度大 產生一定的迭代成本 修繕者模式 系統外部無感知 不會遺漏原有需求 可以隨時停下來改 避免閉門 車 改 時間的跨度大 會有更多額外迭代成 本
86. 91 https://udn.com/news/story/7239/3777131
87. 92 https://www.chinatimes.com/newspapers/20190426000271-260202
88. 個 人 想 法 與 見 解 工程 vs 組織 Microservices create organizational problems? or Organization creates microservices architecture? 93
89. 組織與架構 94 人 (組織) 物 (工程) 事 (業務) 個 人 想 法 與 見 解
90. 95 架構與團隊 Storage Web API Database Internal GW External LB Whatever Service 架構 Backend APP QA SRE PO / PM Mission Impossible Team 團隊 Manager 個 人 想 法 與 見 解 • 演講：從緊急事件 談 SRE 應變能力的培養 • 事件管理與康威定律
91. 96 End User Private Public Protected ACL 架構與團隊 BlackForest SwordBearer ShelterEra Internal Users Production (SaaS) ThreeBody ChaoticEra Gravity Naming: 三體中英文對照表 Dweller 個 人 想 法 與 見 解
93. 交付流水線 98
94. 個 人 想 法 與 見 解 99 Source Build Artifact Repository Programmers Continuous Integration Continuous Deployment Production QA R&D Deploy WebAPI v2.1.0 WebAPI v2.1.0 Test: Function, Regression, Performance Go Production Build, Pack Code Quality, Unit Test Source WebAPI 20190323_v2.1.0 CI / CD 的全貌 Config Infrastructure Provisioning Source: 聊聊軟體交付的濫觴 談產出物管理 (Artifacts Management)
95. 個 人 想 法 與 見 解 100 Source Build Artifact Repository Programmers CH09 Continuous Integration Continuous Deployment Production QA R&D Deploy WebAPI v2.1.0 WebAPI v2.1.0 CH10 Test: Function, Regression, Performance CH12 Go Production Build, Pack Code Quality, Unit Test Source WebAPI 20190323_v2.1.0 CI / CD 的全貌 Config Infrastructure Provisioning CH08 分支策略 CH11 軟體配置管理 CH07 部署流水線的原則與工具設計 CH11 軟體配置管理 CH13 監測與決策 Source: 聊聊軟體交付的濫觴 談產出物管理 (Artifacts Management)
96. 第八章 利於整合的分支策略 • 主幹開發、主幹發布 (Trunk-Based Development & Release) • 主幹開發、分支發布 (Trunk-Based Development & Branch-based Release) • 分支開發、主幹發布 (Branch-Based Development * Trunk-based Release) 101
97. 分支策略 102 策略 特性 案例 主幹開發 主幹發佈 管理簡單（沒有分支管理） 低頻率交付衝突問題多 主幹開發 分支發佈 (TBD) 主幹提交活動頻繁，有淺在風險 分支只修復缺陷 主幹有問題，分支也要合併 (合併 Alive 的版本) 需要 Feature Toggle Google、Facebook 分支開發 主幹發佈 從主幹拉分支 發佈的分支要合併回主幹 在主幹修復問題，太久會很容易衝突 團隊可以自由開分支 Open Source Git Flow
98. Trunk-Based Development (TBD) • Feature Toggle • 分支只修復缺陷，不加新 功能 • 新版本發佈有問題，分支 也要修復 103 https://paulhammant.com/2013/04/05/what-is-trunk-based-development/
99. 我的選擇：主幹開發、分支發布 104 個 人 想 法 與 見 解 • 考慮：以終為始，交付的產出物 (Artifact) 只有一個，例如： ◦ 新版本：2.0.0 -- 開發 ◦ 舊版本：1.9.0 -- 維運 • 開發： ◦ 每次的 commit 都 build 得過 ◦ 功能透過 Feature Toggle 控制 • 測試： ◦ 部署是同一個 • 交付流水線：單一化 • 挑戰： ◦ 開發人員必須有良好的 Config 設計與 DI / IoC 概念 ◦ 架構的耦合性要低
101. 第4章 持續交付2.0的組織文化 第5章 持續交付的軟件系統架構 第6章 業務需求協作管理 第7章 部署流水線原則與工具設計 第8章 利於集成的分支策略 第9章 持續集成 第10章 自動化測試策略與方法 第11章 軟件配置管理 第12章 低風險發布 第13章 監測與決策 附錄A 軟件工程的三次進化 附錄B 排序法做相對估算 I II III （1）堅持少做 （2）持續分解工作 （3）堅持快 回饋 （4）持續改善並衡量 第1章 持續交付2.0 第2章 價值探索環 第3章 快 驗證環 第14章 大型互聯網團隊的FT化 第15章 小團隊逆襲之旅 第16章 研發推動的DevOps 核心工作原则
102. • 大型互聯網桌面產品團隊，經歷一年的持續交付改進計畫 • 多條產品線 • 三百多個人：產品策劃、產品營運、軟體開發、品質保證、維運團隊 第十四章 大型互聯網團隊的 FT 化 (Feature Team) 108
103. 改進步驟 1. 成立內部變革小組 2. 改產品線的負責人掛帥，成員包含外部顧問、核心管理層 3. 評估現狀，定義目標 4. 成立變革小組後，評估面臨問題 a. 定義改進目標：激發整體活力，提升 產品研發效率 b. 目標：每個月準時發布一個高質量的全網版本，沒有延期 5. 識別具體問題，制定短期目標 6. 制定解決方案，並實施 7. 再實施過程中，根據真實反饋，不斷優化直到實現短期目標 8. 返回 (3) 持續進行，直到完成最初目標 109
104. 改 階段 1. 架構解偶階段：透過拆遷者模式，將架構改成『微核架構模式』 2. 組織解偶階段：打破各個職能部門的牆，建立了解業務導向的多角色全功能團隊 3. 研發流程再 ：定義新產品發布策略，改進多團隊的分支管理方式 4. 自動化提升效率階段：透過自動化工具，提升各環節的效率 110
105. 一、架構解偶 111
106. 112 合併的時間點
107. 改 前： • 線上環境出現問題時，各職能角色的抱怨 理由都很充分 ◦ 運維人員：上前前沒通知，沒文檔 ◦ 專案經理：這個問題是測試沒測導致 ◦ 測試人員：太晚拿到測試包，時間被壓縮 ◦ 開發人員：需求變更太快，重複開發工作太 多 ◦ 產品：需求早就提了，設計人員不足，太晚出 設計文件 ◦ …. 二、組織再 113 改 後： • Feature Team：源自於敏捷開發，由各種職 能角色組成，負責 E2E 交付，有明確業務 目標，是一個 mini-business unit • 負責業務價值的交付 • 目標：接下來的六個月，用 戶活躍數增加 40%
108. 三、研發流程再 1. 多版本發布的目的與原則 2. 虛擬主幹的混合分之模式 3. 建立統一製品庫 4. 兩級發布體系 5. 版本品質管理機制 6. 多業務協同發布機制 7. 編譯建構雲平台 114
109. 四、自動化一切 115
110. 改進步驟 1. 成立內部變革小組 2. 改產品線的負責人掛帥，成員包含外部顧問、核心管理層 3. 評估現狀，定義目標 4. 成立變革小組後，評估面臨問題 a. 定義改進目標：激發整體活力，提升 產品研發效率 b. 目標：每個月準時發布一個高質量的全網版本，沒有延期 5. 識別具體問題，制定短期目標 6. 制定解決方案，並實施 7. 再實施過程中，根據真實反饋，不斷優化直到實現短期目標 8. 返回 (3) 持續進行，直到完成最初目標 116
111. 工作原則 （1）堅持少做 （2）持續分解工作 （3）堅持快 回饋 （4）持續改善並衡量 117
113. 三、從個人開始 一個人的持續交付
114. 快 驗 證
115. 自我探索 快 實踐
116. 122 1. 把『寫文章』換成其他想做的事情 2. 把『聽眾』換成『客戶』、『使用者』 3. 『Blog』換成其他形式，例如 Wiki or Evernotes
117. Working Backwards 123 1. Start by writing the Press Release: 先寫 Release 新聞稿 2. Write a Frequently Asked Questions document: 寫 FAQ 文件 3. Define the customer experience: 定義客戶體驗 4. Write the User Manual: 寫使用手冊 AWS CTO Werner Vogels: Working Backwards
118. 124 https://ruddyblog.wordpress.com/tag/3-3-%E7%9A%84scrum/
120. 四、持續交付與 DevOps
121. 工程的 DevOps (狹義) 127 • 產品、開發、測試三個單位的交付：產品開發團隊 (不含維運) • 開發、測試、維運的持續交付：開發團隊的 Dev、QA、Ops，也就是 Wikipedia 說 明的交集。
122. Arch Business 開 (ㄕㄠ) 源 (ㄑㄧㄢˊ) 節 (ㄔㄥˊ) 流 (ㄅㄣˇ) 128 Dev Ops 狹義的 DevOps - 開發團隊 (大部分) Product Team Backend Frondend App DevOps SRE DBA Infra HD AE QA
123. 組織角度的 DevOps (廣義) 129 • 產品開發團隊 (Dev)：產品 ＋ 開發 ＋ 測試 • 企業營運團隊 (Ops)：行銷 ＋ 業務 ＋ 維運 ＋ IT ＋ 人資 ＋ 財務 ＋ 法務 ….
124. Arch Business 開 (ㄕㄠ) 源 (ㄑㄧㄢˊ) 節 (ㄔㄥˊ) 流 (ㄅㄣˇ) 130 Dev Ops 廣義的 DevOps - 整個企業 CEO CTO COO CxO Engineering Backend Frondend App QA HR MIS Product Finance Legal VP Product Engineering Architect BD SD MKT BizOps SysOps SRE Infra Security
125. 沒有要貶抑誰 只是角度差異 131
126. 132 業 務 工 程
127. Arch Business Functional Feature 開 (ㄕㄠ) 源 (ㄑㄧㄢˊ) 節 (ㄔㄥˊ) 流 (ㄅㄣˇ) Func A Func B Service B Service A Service D Service C Func C CM AM Infrastructure 133 Product A Product B Product D Product C Product E 找到你的位置、找到你的價 值
128. DevOps 如何走向業務 Water - Scrum - Fall 让敏捷跨出开发团队 是一条艰困的路程 影響地圖 Impact Mapping
129. 135 虛 實
130. 136 人 (組織) 物 (工程) 事 (業務) 從工程的角度： 實：工程 虛：組織、業務
131. 137 人 (組織) 物 (工程) 事 (業務) 從組織的角度： 實：組織 虛：工程、業務
132. 138 人 (組織) 物 (工程) 事 (業務) 從業務角度： 實：業務 虛：工程、組織
133. 139 人 (組織) 物 (工程) 事 (業務) 科學、技術 架構、數據 文化、信任 連結、希望 需求、商業 未來、方向 軟體交付的三體問題
134. 當代軟體交付 之 虛、實融合 140
135. WE ARE HERE! 我們在哪里? 问题是什么?
136. 第4章 持續交付2.0的組織文化 第5章 持續交付的軟件系統架構 第6章 業務需求協作管理 第7章 部署流水線原則與工具設計 第8章 利於集成的分支策略 第9章 持續集成 第10章 自動化測試策略與方法 第11章 軟件配置管理 第12章 低風險發布 第13章 監測與決策 實 虛 虛實融合 I II III 第1章 持續交付2.0 第2章 價值探索環 第3章 快 驗證環 第14章 大型互聯網團隊的FT化 第15章 小團隊逆襲之旅 第16章 研發推動的DevOps
137. 在虛、實轉換、融合 143
139. Reacp 145
140. 導讀持續交付 2.0 談當代軟體交付 之 虛實融合 Rick Hwang 2019/04/27 146 Agile Hsinchu 四月聚會
141. 147 人 (組織) 物 (工程) 事 (業務) 科學、技術 架構、數據 文化、信任 連結、希望 需求、商業 未來、方向 軟體交付的三體問題
142. 協作、共識 技術管理 複 雜 度 (康 威 定 律 ) x y z Business (Products) Teams (Organization) Engineering (Architecture) https://rickhw.github.io 人 事 物
143. 價值探索 快 驗證
144. 個 人 想 法 與 見 解 150 Source Build Artifact Repository Programmers CH09 Continuous Integration Continuous Deployment Production QA R&D Deploy WebAPI v2.1.0 WebAPI v2.1.0 CH10 Test: Function, Regression, Performance CH12 Go Production Build, Pack Code Quality, Unit Test Source WebAPI 20190323_v2.1.0 CI / CD 的全貌 Config Infrastructure Provisioning CH08 分支策略 CH11 軟體配置管理 CH07 部署流水線的原則與工具設計 CH11 軟體配置管理 CH13 監測與決策
145. 一個人的持續成長：Working Backwards 151 1. Start by writing the Press Release: 先寫 Release 新聞稿 2. Write a Frequently Asked Questions document: 寫 FAQ 文件 3. Define the customer experience: 定義客戶體驗 4. Write the User Manual: 寫使用手冊 AWS CTO Werner Vogels: Working Backwards
146. 152 錢 成就 成長 參考來源：極客時間 面試現場 專欄
147. Arch Business 開 (ㄕㄠ) 源 (ㄑㄧㄢˊ) 節 (ㄔㄥˊ) 流 (ㄅㄣˇ) 153 Dev Ops 狹義的 DevOps - 開發團隊 (大部分) Product Team Backend Frondend App DevOps SRE DBA Infra HD AE QA
148. Arch Business 開 (ㄕㄠ) 源 (ㄑㄧㄢˊ) 節 (ㄔㄥˊ) 流 (ㄅㄣˇ) 154 Dev Ops 廣義的 DevOps - 整個企業 CEO CTO COO CxO Engineering Backend Frondend App QA HR MIS Product Finance Legal VP Product Engineering Architect BD SD MKT BizOps SysOps SRE Infra Security
149. Arch Business Functional Feature 開 (ㄕㄠ) 源 (ㄑㄧㄢˊ) 節 (ㄔㄥˊ) 流 (ㄅㄣˇ) Func A Func B Service B Service A Service D Service C Func C CM AM Infrastructure 155 Product A Product B Product D Product C Product E