前些天在評審項(xiàng)目的年度過程改進(jìn)策劃方案時，討論了軟件開發(fā)中的一個重要指標(biāo)“版本發(fā)布周期”，這個指標(biāo)年年討論芝硬。我也覺得這是一個非常重要的指標(biāo)，一直也有些自己的看法轧房，這次把自己的看法完整的寫出來拌阴，歡迎大家一起探討。需要說明的是锯厢，出于信息安全的考慮皮官，整個文章中不會有任何與公司相關(guān)的敏感信息，是純技術(shù)問題的探討和思考实辑。本文包括如下內(nèi)容：

• 基本概念
• 分析現(xiàn)狀
• 詩和遠(yuǎn)方-持續(xù)發(fā)布
• 如何實(shí)現(xiàn)持續(xù)發(fā)布
• 小結(jié)

一捺氢、基本概念

在軟件開發(fā)中，“版本發(fā)布周期”簡單的說剪撬，就是我們多長時間可以交付一個可用的版本摄乒。
需要說明的是，版本發(fā)布和版本上線是兩個概念，尤其在交付類項(xiàng)目中馍佑。我們通常說的版本發(fā)布是指研發(fā)人員將用戶需求轉(zhuǎn)換為可運(yùn)行的軟件版本的過程斋否；版本上線指將可運(yùn)行的版本部署到生產(chǎn)環(huán)境的過程，包括全新部署拭荤、版本升級茵臭、或打補(bǔ)丁。
一個需求（或想法）只有經(jīng)過研發(fā)人員發(fā)布出可用的版本舅世，并且在生產(chǎn)環(huán)境上線后旦委，其價值才真正得到實(shí)現(xiàn)。所以從客戶價值去考慮雏亚，版本上線才算真正的交付缨硝，因此一個完整的交付周期是由”版本發(fā)布周期+等待周期+上線周期“組成的。
不同的行業(yè)對交付周期會有不同的要求罢低，比如互聯(lián)網(wǎng)應(yīng)用查辩，企業(yè)內(nèi)部的IT系統(tǒng)，交付周期越短越好网持；比如銀行宜岛、電力、電信等行業(yè)的業(yè)務(wù)系統(tǒng)翎碑，它們的版本上線有嚴(yán)格的要求谬返，并不是那么頻繁。
對于我們研發(fā)來說日杈，重點(diǎn)關(guān)注的是”版本發(fā)布周期“，那么”版本發(fā)布周期“多少適合呢佑刷？是越短越好莉擒，還是適中就好？這個問題先不討論瘫絮，后面再說涨冀。

二、分析現(xiàn)狀

我們現(xiàn)在大多數(shù)項(xiàng)目都在使用敏捷開發(fā)中的Scrum方法來組織自己的研發(fā)交付麦萤，scrum方法有兩個關(guān)鍵特征：
1鹿鳖、基于迭代和增量的開發(fā)和版本發(fā)布
2、自組織壮莹、跨職能的特性團(tuán)隊(duì)翅帜。
實(shí)際的情況，在這兩個關(guān)鍵特征上我們都做的不夠好命满，下面簡單解釋下涝滴。
理想的迭代開發(fā)，指每個迭代都能交付可用的版本，真能做到的話歼疮，我們根本不需要討論”版本發(fā)布周期“杂抽，迭代的周期就是”版本發(fā)布周期“。但是我們做不到韩脏，核心問題就是我們無法做到在一個迭代內(nèi)交付可用的版本缩麸，主要是質(zhì)量過不了關(guān)，現(xiàn)在有個更高的產(chǎn)品安全要求赡矢，更過不了關(guān)了匙睹。所以我們就推出了所謂的”x+y“的發(fā)布模型，也就是一個發(fā)布周期包含x開發(fā)迭代+y個系統(tǒng)測試迭代济竹，y目前大都是1痕檬。實(shí)際上很多項(xiàng)目，把這由多個迭代組成的發(fā)布周期做成了小瀑布的開發(fā)方式送浊，背離了敏捷開發(fā)的原則梦谜。
上面提到scrum的第二個關(guān)鍵特征”自組織、跨職能的特性團(tuán)隊(duì)“袭景，雖然我們比以前有了進(jìn)步唁桩，但遠(yuǎn)遠(yuǎn)不夠，其實(shí)看到所謂的”x+y”模型耸棒，就知道我們做的還不夠好荒澡。

我覺得我們應(yīng)該回歸迭代開發(fā)的初心，把目標(biāo)定在如何實(shí)現(xiàn)真正的迭代交付∮胙辏現(xiàn)在達(dá)不到?jīng)]關(guān)系单山，可以慢慢努力去達(dá)到，但如果不朝這個方向去努力幅疼，再怎么努力米奸，也不可能達(dá)到目標(biāo)∷瘢可我們現(xiàn)在是沿著另一個方向去努力悴晰，即如何把x+y模型做的更好,我覺得，方向有點(diǎn)錯了（聲明下逐工，這是個人觀點(diǎn)铡溪，不一定正確，僅供參考）泪喊。

三棕硫、詩和遠(yuǎn)方-持續(xù)發(fā)布

雖然我們連scrum方法的實(shí)施還沒有達(dá)到理想的狀態(tài)，但這不代表我們不可以暢想下詩和遠(yuǎn)方（這個遠(yuǎn)方僅代表我個人觀點(diǎn)）窘俺。
在本文的開頭饲帅，我拋出了問題：”版本發(fā)布周期“多少適合复凳？這里直接給出我的個人觀點(diǎn)：越短越好，理想的方式是按需持續(xù)發(fā)布灶泵。
比如對于已經(jīng)上線的一個產(chǎn)品育八，如果我們需要改一行代碼，從開發(fā)人員在本地改這行代碼開始赦邻，一直到在生產(chǎn)環(huán)境下生效髓棋，這個過程和周期是什么樣的？理想的情況是惶洲，有這樣的一個流水線按声，開發(fā)人員提交代碼，觸發(fā)自動編譯恬吕，代碼質(zhì)量檢查签则，安全檢查，版本生成铐料，測試環(huán)境部署渐裂，自動化測試，試運(yùn)行環(huán)境部署钠惩，生產(chǎn)環(huán)境上線柒凉。
如果是一個新增需求，經(jīng)過需求分析和拆分后篓跛，可能會分解到多人共同開發(fā)膝捞，這里有一個協(xié)同的過程，一旦大家代碼編寫完成后愧沟，一樣通過流水線完成發(fā)布和上線蔬咬。

這里有兩個關(guān)鍵的兩點(diǎn)：
1、全自動化的流水線
2央渣、通過Devops完成版本上線的最后一公里计盒。
我們傳統(tǒng)的產(chǎn)品開發(fā)中，開發(fā)基本上只關(guān)注到版本發(fā)布芽丹，也就是把版本做出來即可。而版本何時上線卜朗，如何上線則是另外一件獨(dú)立的事“蔚冢現(xiàn)在要把這兩件獨(dú)立的事情打通，形成一個貫穿的流水線场钉。

需要說明的是蚊俺，全自動化不代表一定沒有人工參與，就如同現(xiàn)在的物流快遞行業(yè)逛万，中間很多操作是人工操作泳猬，但它的流程是全自動化的。用戶一旦下單后，會有一個全流程的工單流程得封，有了這個流程埋心，就會保證物品按照既定的路徑和時間點(diǎn)被送達(dá)用戶，有哪些人在哪些路徑參與忙上。在軟件開發(fā)和發(fā)布中拷呆，有些也需要人參與，典型的如用戶體驗(yàn)的驗(yàn)收疫粥，我們要做的是把這個人工環(huán)節(jié)納入到整個流水線中茬斧，一旦觸發(fā)了，就會自動觸發(fā)相應(yīng)的人去執(zhí)行這個動作梗逮，而不是依賴臨時的安排项秉。

四、如何實(shí)現(xiàn)持續(xù)發(fā)布

要想實(shí)現(xiàn)上面說的按需持續(xù)發(fā)布慷彤，是需要很多前提條件的娄蔼。
首先，不能使用Scrum方法了：
因?yàn)镾crum方法的迭代周期是一個固定的時間盒瞬欧，有一些固定的規(guī)則（如4會）贷屎，它這個迭代周期不能太短，太短了就無法操作了艘虎。

其次唉侄，要實(shí)現(xiàn)開發(fā)運(yùn)維一體化，即實(shí)施DevOps：
最適合持續(xù)發(fā)布的軟件產(chǎn)品是一個公司內(nèi)部自研的IT軟件系統(tǒng)和自運(yùn)維的互聯(lián)網(wǎng)產(chǎn)品野建；比較困難的是對外交付類產(chǎn)品属划，即開發(fā)者和所有者不是一個公司的；特別難的是為如電信候生、電力同眯、銀行等傳統(tǒng)行業(yè)開發(fā)交付的產(chǎn)品。
因?yàn)閷τ诠緝?nèi)部自研的IT軟件系統(tǒng)和自運(yùn)維的互聯(lián)網(wǎng)產(chǎn)品唯鸭，開發(fā)者和運(yùn)維者都是一個公司的须蜗，可以最大程度的發(fā)揮DevOps的優(yōu)勢，可以比較容易實(shí)現(xiàn)從代碼提交到發(fā)布目溉、部署上線的一站式流水線操作明肮。
而對外交付類產(chǎn)品，開發(fā)者和所有者是兩個公司的缭付，而且交付的周期和方式往往受合同的限制柿估。這時我們首先要做到的是具備持續(xù)發(fā)布的能力，比如能發(fā)布到測試環(huán)境或試運(yùn)行環(huán)境上且能通過驗(yàn)收陷猫，也就是用戶要不要是一回事秫舌，我們能不能做到是另一回事的妖。另外牢記敏捷宣言四句話之一的”客戶合作勝過合同談判“，多與客戶溝通足陨，引導(dǎo)客戶嫂粟，把DevOps的理念和好處告訴給他們。

最后钠右，需要有強(qiáng)大的研發(fā)能力赋元，比如：
1、高質(zhì)量的開發(fā)能力
想想飒房，如果我們無法進(jìn)行高質(zhì)量的開發(fā)搁凸，每新增或修改需求，就引入一堆問題狠毯，這個無論如何能快不起來护糖。

2、松耦合的系統(tǒng)架構(gòu)設(shè)計(jì)能力
如果我們系統(tǒng)是一個緊耦合的系統(tǒng)嚼松，比如是包含很多模塊（或功能）的單體架構(gòu)嫡良。哪怕我們的研發(fā)能力再強(qiáng)，當(dāng)有一個變更時献酗，都需要考慮對其它模塊潛在的影響寝受。還有復(fù)雜的升級問題。想快也快不起來罕偎。好在虛擬化很澄、微服務(wù)給我們帶來了希望。

3颜及、需求分析和分拆能力
用戶的需求往往是不清晰的甩苛，顆粒度可能也是比較粗的，涉及到的模塊（或功能）可能也比較多俏站。為了能快速的發(fā)布讯蒲，需要我們能進(jìn)行很好的需求分析和拆分，將用戶需求轉(zhuǎn)化工作量可控的且相對獨(dú)立的各個產(chǎn)品需求肄扎，并能做好波及分析墨林，這個是能快速開發(fā)和交付的基礎(chǔ)。

3犯祠、高水平的自動化測試能力
在軟件開發(fā)中萌丈，有一個常見的名詞叫“回歸測試”，如果沒有完善的自動化測試雷则，我們很難保證變更帶來的波及影響。只有具備完善的自動化測試肪笋，我們才可以放心的去修改代碼月劈。

5度迂、制定有效分支策略的能力
如果我們要做到實(shí)時發(fā)布，我們就不能像以前一樣每個發(fā)布版本對應(yīng)一個分支猜揪，必須要有新的代碼分支策略惭墓。比如單分支的策略是演進(jìn)方向之一。

6而姐、完善的基礎(chǔ)設(shè)施能力
從開發(fā)到上線腊凶，要求全流水線，做到最大程度的自動化拴念，一旦有問題钧萍，還能無風(fēng)險的回退能力。這就要求我們有很強(qiáng)大的基礎(chǔ)設(shè)施和完善的Devops工具鏈政鼠。

7风瘦、很強(qiáng)的團(tuán)隊(duì)協(xié)作能力
我們希望有自組織的、跨職能的團(tuán)隊(duì)公般，大家一起來進(jìn)行研發(fā)交付万搔，其中人是核心。團(tuán)隊(duì)成員如何有效的合作官帘，是一切的基礎(chǔ)瞬雹，是持續(xù)成功的關(guān)鍵。正如敏捷宣言中另外一句話”個體和交互勝過過程和工具“刽虹。

上面只是列出了部分重要的能力酗捌，肯定還不夠。實(shí)際上状婶，我為什么提倡”版本發(fā)布周期“越短越好意敛，因?yàn)檫@個目標(biāo)會牽引上述能力的提升。想想膛虫，即使是采用scrum方法草姻，如果我們要做到單個迭代能夠?qū)ν獍l(fā)布，上面提到的一些能力是都要被牽引著進(jìn)行提升稍刀，否則很難做到按迭代發(fā)布撩独。

五、小結(jié)

本文對軟件開發(fā)中的核心問題之一账月，版本發(fā)布周期進(jìn)行了思考综膀。分析了現(xiàn)狀，暢想了詩和遠(yuǎn)方局齿，認(rèn)為最理想的方式是按需的持續(xù)發(fā)布剧劝，并淺顯的分析了如果要做到這點(diǎn)需要具備哪些能力。
總結(jié)下抓歼，我認(rèn)為縮短”版本發(fā)布周期“是牽引項(xiàng)目研發(fā)過程改進(jìn)的一個比較好的出發(fā)點(diǎn)讥此，我們當(dāng)前的改進(jìn)目標(biāo)應(yīng)該放在如何實(shí)現(xiàn)迭代版本的真正可交付拢锹，并在這基礎(chǔ)上不斷縮減”版本發(fā)布周期“。觀點(diǎn)不一定正確萄喳，大家一起探討卒稳！