一氢架、持續(xù)交付2.0

1.1軟件工程發(fā)展：

瀑布開發(fā) -> 敏捷開發(fā)

相比瀑布的線性模型，只有在項(xiàng)目交付后期才能看到可運(yùn)行的軟件朋魔，敏捷開發(fā)將一個(gè)交付計(jì)劃劃分為多個(gè)迭代岖研，每個(gè)迭代結(jié)束都可以得到對應(yīng)可運(yùn)行軟件。

1.2 DevOps:

是運(yùn)維與研發(fā)參與整個(gè)軟件生命周期的一組實(shí)踐铺厨，它倡導(dǎo)對構(gòu)建軟件的所有環(huán)節(jié)（從集成缎玫、測試、發(fā)布解滓、到部署和基礎(chǔ)架構(gòu)管理）進(jìn)行全面的自動(dòng)化和監(jiān)控，從而達(dá)到更快筝家、更頻繁地交付更穩(wěn)定的軟件的目的洼裤。

1.3 持續(xù)交付1.0

可持續(xù)地快速發(fā)布軟件服務(wù)。

持續(xù)交付1.0

1.4持續(xù)交付2.0

持續(xù)交付2.0雙環(huán)模型

探索環(huán)：定需求溪王。
驗(yàn)證環(huán)：落地功能腮鞍。

以業(yè)務(wù)為導(dǎo)向，拆解細(xì)化業(yè)務(wù)問題莹菱，快速通過雙環(huán)進(jìn)行探索和驗(yàn)證移国，減少浪費(fèi)的同時(shí)，快速找到業(yè)務(wù)前進(jìn)方向道伟。

二迹缀、價(jià)值探索環(huán)

目的：持續(xù)識別和定義有價(jià)值的假設(shè)，借助價(jià)值驗(yàn)證環(huán)得到數(shù)據(jù)反饋蜜徽，快速把握業(yè)務(wù)前進(jìn)方向祝懂。

4個(gè)關(guān)鍵環(huán)節(jié)：

• 提問：找出業(yè)務(wù)目標(biāo)
• 錨定：收集信息量化指標(biāo)，描述期望的結(jié)果拘鞋。
• 共創(chuàng)：討論出所有可行的解決方案砚蓬。
• 精練：評估出合適方案作為驗(yàn)證環(huán)的輸入。

為了加快探索環(huán)的速度盆色，提出三點(diǎn)工作原則：

• 分解并快速試錯(cuò)
• 一次只驗(yàn)證一點(diǎn)
• 允許失敗

共創(chuàng)與精練環(huán)節(jié)常用的方法：

• 裝飾窗方法： 設(shè)計(jì)一個(gè)用戶能看到但并沒有實(shí)現(xiàn)的新功能入口灰蛙，快速且低成本地驗(yàn)證用戶是否喜歡某個(gè)功能及緊迫程度。
• 最小可行特性法： 產(chǎn)品的從1到N的過程隔躲。拆解任務(wù)摩梧，優(yōu)先實(shí)現(xiàn)用戶最迫切的需求。
• 特區(qū)法：在特定小范圍用戶群內(nèi)驗(yàn)證某個(gè)新功能是否有效蹭越，減少無效或者效果不好帶來的損失障本。
• 定向探索法：對具有特定行為的特定用戶群，針對性設(shè)計(jì)調(diào)查方案，探索其行為動(dòng)機(jī)驾霜，得出功能的定位或者改進(jìn)方向案训。
• 稻草人法：不開發(fā)真實(shí)功能，但是先向用戶提供該功能等價(jià)的真實(shí)效果粪糙。
• 最小可行產(chǎn)品法：產(chǎn)品從0到1的過程强霎。以盡可能少的成本開發(fā)出產(chǎn)品核心功能，獲取用戶蓉冈，并收集真實(shí)數(shù)據(jù)城舞，不斷錨定產(chǎn)品的方向和形態(tài)。

三寞酿、快速驗(yàn)證環(huán)

目的：借助各種方法與工具家夺，讓質(zhì)量可靠的解決方案快速到達(dá)客戶手指，進(jìn)而收集并分析真實(shí)反饋伐弹。

4個(gè)關(guān)鍵環(huán)節(jié)：

• 構(gòu)建：解決方案落地拉馋。
• 運(yùn)行：交付產(chǎn)品，為用戶提供服務(wù)惨好。
• 監(jiān)測：收集數(shù)據(jù)煌茴，并對系統(tǒng)進(jìn)行監(jiān)控。
• 決策：將收集的信息與探索環(huán)的期望目標(biāo)進(jìn)行對比日川，做出決策蔓腐，確定下一步方向。

工作原則：

• 質(zhì)量內(nèi)建：生產(chǎn)過程中的每個(gè)環(huán)節(jié)都開展質(zhì)量保障龄句，而非到后期統(tǒng)一一次大規(guī)模檢查回论。
• 消除等待：提升各環(huán)節(jié)效率，減少浪費(fèi)撒璧。
• 重復(fù)事物自動(dòng)化：重復(fù)性工作通過優(yōu)化流程和自動(dòng)化措施透葛，降低成本。
• 監(jiān)測一切：應(yīng)用健康監(jiān)測卿樱、業(yè)務(wù)健康監(jiān)測僚害。

對持續(xù)交付2.0雙環(huán)模型理解：
價(jià)值探索環(huán)持續(xù)高效產(chǎn)出有價(jià)值的業(yè)務(wù)方案，作為輸入給到快速驗(yàn)證環(huán)繁调。
快速驗(yàn)證環(huán)快速高質(zhì)量完成業(yè)務(wù)落地萨蚕，交付用戶，并收集有效反饋給到加載探索環(huán)蹄胰。
價(jià)值探索環(huán)根據(jù)反饋信息與之前期望進(jìn)行對比岳遥，做出決策，確認(rèn)下一步方向裕寨。
這個(gè)大框架過程中浩蓉，通過一切手段來保證更快的速度和更好的質(zhì)量派继。

四、持續(xù)交付2.0的組織文化

企業(yè)采納持續(xù)交付需要的文化氛圍：安全捻艳、信任與持續(xù)改善驾窟。

五、持續(xù)交付的軟件系統(tǒng)架構(gòu)

持續(xù)交付2.0能力對系統(tǒng)架構(gòu)的要求：

• 可測試性
• 易部署性
• 易監(jiān)測性
• 易擴(kuò)展性
• 對可能失敗的處理

常見架構(gòu)模式：

• 微核架構(gòu)：插件化认轨，常用于客戶端軟件
• 微服務(wù)架構(gòu)：后臺服務(wù)軟件
• 巨石架構(gòu)：單一結(jié)構(gòu)體組成的軟件應(yīng)用

架構(gòu)改造實(shí)施模式：

• 拆遷者模式：重寫一套新框架绅络。
• 絞殺者模式：通過增加新服務(wù)來不斷替代遺留系統(tǒng)功能。
• 修繕者模式：通過迭代嘁字，對原有遺留系統(tǒng)進(jìn)行逐步改造恩急，同時(shí)開發(fā)新的功能。

六纪蜒、業(yè)務(wù)需求協(xié)作管理

產(chǎn)品版本周期主要分為：準(zhǔn)備期和交付期衷恭。分別對應(yīng)持續(xù)交付2.0雙環(huán)模型的探索環(huán)和驗(yàn)證環(huán)。
重點(diǎn)討論如何通過需求拆分帶來更好收益霍掺，降低固定成本匾荆。

傳統(tǒng)瀑布軟件開發(fā)方式是按開發(fā)階段來拆分的，該方案只有等到項(xiàng)目進(jìn)入全面測試階段才能得到可運(yùn)行的軟件包杆烁。我們應(yīng)該盡可能從業(yè)務(wù)視角出發(fā)進(jìn)行需求拆分，將需求按用戶故事進(jìn)行拆分简卧，一批用戶故事構(gòu)成一個(gè)可交付的軟件兔魂，不斷迭代為完整用戶故事構(gòu)成的最終軟件包。

因此合理拆分顯得尤為重要举娩，這里需要遵守INVEST原則：
*independent 用戶故事獨(dú)立

• negotiable 可協(xié)商
• valuable 用戶故事必須是有價(jià)值的
• estimable 必現(xiàn)可估算創(chuàng)建用戶故事的工作量
• small 用戶故事必須足夠小
• testable 用戶故事必須是可被驗(yàn)證的

常用5大拆分方法：

• 按路徑拆分法： 根據(jù)用戶使用場景中的不同路徑進(jìn)行拆分析校，比如：支付場景的微信支付、支付寶支付可以拆分為兩個(gè)用戶故事分別實(shí)現(xiàn)铜涉。
• 按接觸的拆分法：根據(jù)用戶與系統(tǒng)間的交互通道進(jìn)行拆分智玻。比如：移動(dòng)端、pc端芙代。
• 按數(shù)據(jù)類型或格式來拆分：比如統(tǒng)計(jì)工具吊奢，實(shí)現(xiàn)文件上傳。這里可以拆分為csv纹烹、xml页滚、excel分別為三個(gè)上傳功能來實(shí)現(xiàn)。
• 按規(guī)則拆分：業(yè)務(wù)規(guī)則或技術(shù)規(guī)則铺呵」郏基礎(chǔ)需求->完善需求 遞進(jìn)。
• 按探索路徑拆分：將對陌生事物的實(shí)驗(yàn)性探索逐步拆分為不同的探索故事片挂。

團(tuán)隊(duì)協(xié)作管理工具:

• 團(tuán)隊(duì)共享日歷： 團(tuán)隊(duì)時(shí)間管理幻林。
• 團(tuán)隊(duì)回顧：定期復(fù)盤贞盯。
• 可視化故事墻：團(tuán)隊(duì)工作狀態(tài)可視化（todo、doing沪饺、done）躏敢。
• 明確完成的定義：明確好交付的標(biāo)準(zhǔn)。
• 持續(xù)集成：團(tuán)隊(duì)多人并行開展工作随闽，及時(shí)交階段性交付成果持續(xù)集成父丰。
• 故事驗(yàn)證：測試驗(yàn)收標(biāo)準(zhǔn)。

整體這一套團(tuán)隊(duì)協(xié)作管理方案其實(shí)就是敏捷開發(fā)掘宪。

七蛾扇、部署流水線原則與工具設(shè)計(jì)

部署流水線：它是對軟件交付過程的一種可視化呈現(xiàn)方式，展現(xiàn)了從代碼提交魏滚、構(gòu)建镀首、部署、測試到發(fā)布的整個(gè)過程鼠次，為團(tuán)隊(duì)提供狀態(tài)可視化和及時(shí)反饋更哄。

八、利于集成的分支策略

版本控制目的腥寇，回答4個(gè)W

• when 什么時(shí)間
• what 修改了什么內(nèi)容
• who 誰修改的
• why 為什么要修改

主流版本管理系統(tǒng)：

• 集中式：單一的版本管理服務(wù)器成翩。
• 分布式：對個(gè)服務(wù)器共存，每個(gè)人的節(jié)點(diǎn)都是一個(gè)代碼倉庫赦役，所有節(jié)點(diǎn)都平等麻敌。

版本控制系統(tǒng)基本概念：

• codebase 代碼倉庫。
• branch 分支掂摔，選定代碼基線創(chuàng)建的副本术羔。
• master/trunk 主干。
• revision 對應(yīng)某個(gè)分支的一次提交操作乙漓。
• tag 標(biāo)簽级历，某個(gè)分支的某個(gè)版本號的一個(gè)別名。
• head 某個(gè)分支最新一次提交叭披。
• merge 合并分支內(nèi)容寥殖。
• conflict 合入操作引發(fā)的沖突

常見分支開發(fā)模式：

• 主干開發(fā)，主干發(fā)布 基于主干開發(fā)趋观，向主干提代碼扛禽，主干持續(xù)作為功能交付分支。
• 主干開發(fā)皱坛，分支發(fā)布 基于主干開發(fā)编曼，向主干提代碼，從主干拉出交付功能分支剩辟，集成測試并修復(fù)bug掐场，發(fā)布分支往扔。
• 分支開發(fā)，主干發(fā)布 從主干拉出分支進(jìn)行開發(fā)熊户，開發(fā)完成對外交付版本時(shí)才合入主干分支萍膛。

分支模式的演化：

• "三駕馬車”分支模式 開發(fā)分支->預(yù)發(fā)布分支->發(fā)布分支
• Gitflow分支模式 feature->dev->release->master/hotfix
• GitHubFlow分支模式 checkout feature branch from master -> dev on feature branch -> PR -> merge master

版本發(fā)布模式：
項(xiàng)目制發(fā)布模式 固定了版本特性數(shù)量和質(zhì)量要求。
發(fā)布火車模式 大型項(xiàng)目嚷堡，多條產(chǎn)品線蝗罗，各團(tuán)隊(duì)對齊交付時(shí)間節(jié)點(diǎn)。
城際快線模式 固定時(shí)間和質(zhì)量蝌戒，滿足發(fā)布條件的特性有多少就上多少串塑。

選擇分支模式原則：

• 分支越少越好，最好只有一條主干北苟。
• 分支生命周期越短越好桩匪，最好在3天內(nèi)。
• 在業(yè)務(wù)允許的前提下友鼻，發(fā)布周期越短越好傻昙。

九、持續(xù)集成

持續(xù)集成是一種軟件開發(fā)實(shí)踐彩扔，團(tuán)隊(duì)成員頻繁地將他們的工作成果集成在一起妆档，每次提交后，自動(dòng)觸發(fā)運(yùn)行一次包含自動(dòng)化驗(yàn)證集的構(gòu)建任務(wù)虫碉，以便能盡早發(fā)現(xiàn)集成問題过吻。

持續(xù)集成屬于一種質(zhì)量反饋機(jī)制。

持續(xù)集成過程

六步提交法：

• 檢出最近成功的代碼 checkout last build success branch
• 修改代碼 do feature
• 第一次個(gè)人構(gòu)建 build feature
• 第二次個(gè)人構(gòu)建 pull origin branch ,merge code ,build again
• 提交代碼到團(tuán)隊(duì)主干 PR
• 提交構(gòu)建 server build

持續(xù)集成獲得最大收益蔗衡，做到如下六點(diǎn)：

• 主干開發(fā)，頻繁提交代碼乳绕。
• 每次提交都是完整有意義的工作绞惦。
• 提交構(gòu)建階段在10分鐘內(nèi)完成。
• 提交構(gòu)建失敗后洋措，立即修復(fù)济蝉；且其他人不得在修復(fù)之前提交代碼。
• 應(yīng)該在10分鐘內(nèi)修復(fù)失敗菠发，否則回滾引起失敗的代碼王滤。
• 自動(dòng)化構(gòu)建成功后，團(tuán)隊(duì)對軟件質(zhì)量比較有信心滓鸠。