前期我們談了持續(xù)集成,。當(dāng)持續(xù)集成完成后,，會(huì)涉及集成的版本做什么?那必然會(huì)說到持續(xù)交付。
持續(xù)交付,，就是時(shí)時(shí)可持續(xù)地編譯、測試,、評(píng)審,、部署、發(fā)布的一系列活動(dòng)集,。當(dāng)然這種交付策略可以是定期或是新特性觸發(fā),，采用一系列自動(dòng)化工具按照已制定的交付策略快速、準(zhǔn)確地執(zhí)行，從而在質(zhì)量,、效率上大幅提高,，成本上大幅降低。
本篇文章將從需求分析起,，涉及設(shè)計(jì),、編碼、測試,、預(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ā),、測試,、版本管理，這里以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)行單元測試，測試通過后使用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)測試工具進(jìn)行靜態(tài)測試并使用Sonar進(jìn)行規(guī)范性檢查以及整合出具測試報(bào)告
5. 編譯、靜態(tài)測試,、規(guī)范檢查通過后,，將從develop分支并入到release分支，并自動(dòng)部署在測試服務(wù)器上,。
6. 對(duì)該版本進(jìn)行自動(dòng)化測試,，很多自動(dòng)化測試都是根據(jù)自己的產(chǎn)品自行開發(fā)的自動(dòng)測試框架和系統(tǒng),。測試缺陷錄入JIRA進(jìn)行跟蹤,。
7. 對(duì)缺陷修改的代碼提交到Git時(shí)將自動(dòng)與修復(fù)的缺陷編碼相關(guān)聯(lián)，明確該代碼是為修復(fù)哪些缺陷而提交的,。每次提交前都要執(zhí)行第3步,。
8. 測試通過后，將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)測,、判斷),，系統(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)容,。