Mais conteúdo relacionado Semelhante a 導讀持續交付 2.0 - 談當代軟體交付之虛實融合 (20) 導讀持續交付 2.0 - 談當代軟體交付之虛實融合29. ● 團隊
○ 溝通成本
○ 訊息一致性
● 文化
○ 信任
○ 開放
○ 價值
● 目的:共識與一致性
● 問題:協作效率
組織問題
29
協作效率
32. ● 市場是 VUCA
○ Volatility(易變性)
○ Uncertainty(不確定性)
○ Complexity(複雜性)
○ Ambiguity(模糊性)
● 客戶要的是什麼?
○ 客戶要的更多了
○ 市場變化更快了
○ 產品解決客戶什麼問題?
● 問題:混屯的需求與市場
● 目標:成事
● 目的:價值
業務問題
32
價值
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
核心工作原则
62. 探索環 Discovery Loop 是指團隊通過一系列工作環節,能夠識別和定義業務問題,
制定相應的衡量指標,並找出低成本且可快 驗證的最小可行解決方案 Minimum
Viable Solution。這是一個理解真實需求、判斷優先順序、再評價需求的過程。
四個關鍵環節
65
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
核心工作原则
77. 塑 文化四步法
81
第一步: 定義我們想要做的事
第二步: 定義我們期望的做事方式或方法
第三步: 提供相應的培訓,使員工具備完成其工作的能力
第四步: 設計一些必要的機制或措施來強化我們所鼓勵的那些行為
-- 讓員工成功掌握自己工作的方法,進而改變企業文化。
《 精益企業》 - Page 48, From : Jez Humble & Joanne Molesky
80. 架構要求
● design for test
● design for deployment
● design for monitor
● design for scale
● design for faliure
85
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 趕上
絞殺者模式 不會遺漏原有需求
可穩定地提供價值
避免閉門 車
改 時間的跨度大
產生一定的迭代成本
修繕者模式 系統外部無感知
不會遺漏原有需求
可以隨時停下來改
避免閉門 車
改 時間的跨度大
會有更多額外迭代成
本
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
98. Trunk-Based Development (TBD)
● Feature Toggle
● 分支只修復缺陷,不加新
功能
● 新版本發佈有問題,分支
也要修復
103https://paulhammant.com/2013/04/05/what-is-trunk-based-development/
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
核心工作原则
107. 改 前:
● 線上環境出現問題時,各職能角色的抱怨
理由都很充分
○ 運維人員:上前前沒通知,沒文檔
○ 專案經理:這個問題是測試沒測導致
○ 測試人員:太晚拿到測試包,時間被壓縮
○ 開發人員:需求變更太快,重複開發工作太
多
○ 產品:需求早就提了,設計人員不足,太晚出
設計文件
○ ….
二、組織再
113
改 後:
● Feature Team:源自於敏捷開發,由各種職
能角色組成,負責 E2E 交付,有明確業務
目標,是一個 mini-business unit
● 負責業務價值的交付
● 目標:接下來的六個月,用 戶活躍數增加
40%
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
121. 工程的 DevOps (狹義)
127
● 產品、開發、測試三個單位的交付:產品開發團隊 (不含維運)
● 開發、測試、維運的持續交付:開發團隊的 Dev、QA、Ops,也就是 Wikipedia 說
明的交集。
124. Arch
Business
開 (ㄕㄠ)
源 (ㄑㄧㄢˊ)
節 (ㄔㄥˊ)
流 (ㄅㄣˇ)
130
Dev Ops
廣義的 DevOps - 整個企業
CEO
CTO
COO
CxOEngineering
Backend
Frondend
App
QA
HR
MIS
Product
Finance
Legal
VP
Product
Engineering
Architect
BD
SD
MKT
BizOps
SysOps
SRE
Infra Security
127. Arch
Business
Functional Feature
開 (ㄕㄠ)
源 (ㄑㄧㄢˊ)
節 (ㄔㄥˊ)
流 (ㄅㄣˇ)
Func A Func B
Service B
Service A
Service D
Service CFunc C
CM
AM
Infrastructure
133
Product AProduct B
Product D
Product C
Product E
找到你的位置、找到你的價 值
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
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
148. Arch
Business
開 (ㄕㄠ)
源 (ㄑㄧㄢˊ)
節 (ㄔㄥˊ)
流 (ㄅㄣˇ)
154
Dev Ops
廣義的 DevOps - 整個企業
CEO
CTO
COO
CxOEngineering
Backend
Frondend
App
QA
HR
MIS
Product
Finance
Legal
VP
Product
Engineering
Architect
BD
SD
MKT
BizOps
SysOps
SRE
Infra Security