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