前期我們談了持續(xù)集成。當(dāng)持續(xù)集成完成后，會(huì)涉及集成的版本做什么?那必然會(huì)說到持續(xù)交付。
持續(xù)交付，就是時(shí)時(shí)可持續(xù)地編譯、測(cè)試、評(píng)審、部署、發(fā)布的一系列活動(dòng)集。當(dāng)然這種交付策略可以是定期或是新特性觸發(fā)，采用一系列自動(dòng)化工具按照已制定的交付策略快速、準(zhǔn)確地執(zhí)行，從而在質(zhì)量、效率上大幅提高，成本上大幅降低。
本篇文章將從需求分析起，涉及設(shè)計(jì)、編碼、測(cè)試、預(yù)發(fā)布、運(yùn)維等多個(gè)環(huán)節(jié)來示意如何用工具集完成這個(gè)持續(xù)交付和運(yùn)維的過程。最后會(huì)使用故事地圖的展現(xiàn)形式描述各環(huán)節(jié)、角色、工具與活動(dòng)的關(guān)系。這里還涉及到我們使用的Git Flow，來講述如何在開發(fā)階段進(jìn)行版本控制。
圖一是使用自動(dòng)化工具在SCRUM敏捷框架中進(jìn)行開發(fā)、管理的示意圖。具體的管理流程如下：
1. PO和Team在Confluence上進(jìn)行故事地圖、史詩和故事的分解和分析。對(duì)在分析過程中的討論P(yáng)O和Team可以在Confluence上展現(xiàn)，并在分析后期對(duì)故事地圖、史詩、故事等進(jìn)行評(píng)審。評(píng)審?fù)瓿珊筮M(jìn)行生成WORD文檔進(jìn)行基線管理。
2. 在Confluence故事分析的基礎(chǔ)上，將產(chǎn)品故事在JIRA中生成PB，并經(jīng)過迭代計(jì)劃評(píng)審會(huì)的上半期形成SB，在下半期進(jìn)行估算后再拆分成一個(gè)個(gè)迭代任務(wù)。
3. team在實(shí)施每個(gè)迭代過程中，會(huì)召開站立會(huì)議，會(huì)議中使用JIRA展現(xiàn)進(jìn)度看板和迭代燃盡圖，使故事和任務(wù)的進(jìn)展更加直觀，這樣可以加深team的熟知度。而且站立會(huì)議期間也可以對(duì)迭代任務(wù)進(jìn)行認(rèn)領(lǐng)并跟蹤。
4. 當(dāng)?shù)瓿烧匍_迭代評(píng)審會(huì)時(shí)，可以使用JIRA展現(xiàn)產(chǎn)品燃盡圖。
5. 在迭代回顧會(huì)上，對(duì)管理問題進(jìn)行討論、分析并用JIRA進(jìn)行記錄、排序，確定哪些需要在下個(gè)迭代中需要改進(jìn)并以任務(wù)形式進(jìn)行跟蹤。
具體在每個(gè)迭代的期間作為一個(gè)開發(fā)人員如何使用工具進(jìn)行開發(fā)、測(cè)試、版本管理，這里以Git工具為例說明開發(fā)過程各項(xiàng)活動(dòng)和版本管理內(nèi)容(見圖二)：
圖二
1. 在項(xiàng)目初始期(有的項(xiàng)目將其定為：Sprint 0)，將創(chuàng)建Git配置庫，并建立master基線并從master中拉出develop分支。
2. team人員從JIRA上認(rèn)領(lǐng)任務(wù)后，針對(duì)自己所要實(shí)現(xiàn)的不同特性，拉出多個(gè)不同的特性分支，這些特性的分支是在開發(fā)者本地。
3. 開發(fā)人員在本地實(shí)現(xiàn)特性后，使用TestNG進(jìn)行單元測(cè)試，測(cè)試通過后使用Gerrit提交代碼評(píng)審請(qǐng)求。代碼評(píng)審人收到申請(qǐng)后對(duì)代碼進(jìn)行評(píng)審，評(píng)審?fù)ㄟ^,這段代碼才能進(jìn)入到Git 服務(wù)器并并入到develop分支。
4. 當(dāng)Git有新特性分支的內(nèi)容合并到develop分支后， Jenkins將進(jìn)行自動(dòng)化編譯，并使用Clover等靜態(tài)測(cè)試工具進(jìn)行靜態(tài)測(cè)試并使用Sonar進(jìn)行規(guī)范性檢查以及整合出具測(cè)試報(bào)告
5. 編譯、靜態(tài)測(cè)試、規(guī)范檢查通過后，將從develop分支并入到release分支，并自動(dòng)部署在測(cè)試服務(wù)器上。
6. 對(duì)該版本進(jìn)行自動(dòng)化測(cè)試，很多自動(dòng)化測(cè)試都是根據(jù)自己的產(chǎn)品自行開發(fā)的自動(dòng)測(cè)試框架和系統(tǒng)。測(cè)試缺陷錄入JIRA進(jìn)行跟蹤。
7. 對(duì)缺陷修改的代碼提交到Git時(shí)將自動(dòng)與修復(fù)的缺陷編碼相關(guān)聯(lián)，明確該代碼是為修復(fù)哪些缺陷而提交的。每次提交前都要執(zhí)行第3步。
8. 測(cè)試通過后，將release分支合并到master主干上并做基線標(biāo)識(shí)。主干上的產(chǎn)品在質(zhì)量上應(yīng)該是可以隨時(shí)對(duì)外發(fā)布的。
以下內(nèi)容為開發(fā)與運(yùn)維分界線：
9. 將master主干上的產(chǎn)品代碼直接自動(dòng)部署至預(yù)發(fā)布環(huán)境。這時(shí)預(yù)發(fā)布系統(tǒng)將由運(yùn)維人員接手，進(jìn)行部署和驗(yàn)證。這里的驗(yàn)證標(biāo)準(zhǔn)應(yīng)與后期的實(shí)際運(yùn)營標(biāo)準(zhǔn)一致。
10. 產(chǎn)品在預(yù)發(fā)布環(huán)境驗(yàn)證通過后，將自動(dòng)部署(升級(jí))至真實(shí)的運(yùn)營環(huán)境。
以下內(nèi)容為運(yùn)維內(nèi)容：
11. 對(duì)于toB的產(chǎn)品，我們可以使用JIRA對(duì)客戶開放，將客戶反饋的建議、問題記錄在系統(tǒng)中，并可以讓客戶時(shí)時(shí)看到所提問題的流轉(zhuǎn)狀態(tài)。
12. 當(dāng)對(duì)于SAAS部署的產(chǎn)品發(fā)生嚴(yán)重故障時(shí)(這些故障可以由運(yùn)營系統(tǒng)自動(dòng)監(jiān)測(cè)、判斷)，系統(tǒng)發(fā)送信息給相關(guān)人員。技術(shù)負(fù)責(zé)人根據(jù)事先定義的標(biāo)準(zhǔn)來判定是否回滾。bbs.mypm.net
下面用故事地圖的形式描述持續(xù)交付的內(nèi)容(詳見圖三)：
圖三項(xiàng)
角色是每個(gè)故事中起主導(dǎo)的角色。藍(lán)色線上的故事是最小可行產(chǎn)品(即可使用敏捷方式進(jìn)行過程改進(jìn)，MVP是可以先做后根據(jù)效果進(jìn)行完善的最小改進(jìn)過程)，也是以敏捷思維去考慮持續(xù)交付和DevOps的內(nèi)容。