前期我們談了持續(xù)集成。當持續(xù)集成完成后，會涉及集成的版本做什么?那必然會說到持續(xù)交付。
持續(xù)交付，就是時時可持續(xù)地編譯、測試、評審、部署、發(fā)布的一系列活動集。當然這種交付策略可以是定期或是新特性觸發(fā)，采用一系列自動化工具按照已制定的交付策略快速、準確地執(zhí)行，從而在質(zhì)量、效率上大幅提高，成本上大幅降低。
本篇文章將從需求分析起，涉及設計、編碼、測試、預發(fā)布、運維等多個環(huán)節(jié)來示意如何用工具集完成這個持續(xù)交付和運維的過程。最后會使用故事地圖的展現(xiàn)形式描述各環(huán)節(jié)、角色、工具與活動的關系。這里還涉及到我們使用的Git Flow，來講述如何在開發(fā)階段進行版本控制。
圖一是使用自動化工具在SCRUM敏捷框架中進行開發(fā)、管理的示意圖。具體的管理流程如下：
1. PO和Team在Confluence上進行故事地圖、史詩和故事的分解和分析。對在分析過程中的討論PO和Team可以在Confluence上展現(xiàn)，并在分析后期對故事地圖、史詩、故事等進行評審。評審完成后進行生成WORD文檔進行基線管理。
2. 在Confluence故事分析的基礎上，將產(chǎn)品故事在JIRA中生成PB，并經(jīng)過迭代計劃評審會的上半期形成SB，在下半期進行估算后再拆分成一個個迭代任務。
3. team在實施每個迭代過程中，會召開站立會議，會議中使用JIRA展現(xiàn)進度看板和迭代燃盡圖，使故事和任務的進展更加直觀，這樣可以加深team的熟知度。而且站立會議期間也可以對迭代任務進行認領并跟蹤。
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上認領任務后，針對自己所要實現(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時將自動與修復的缺陷編碼相關聯(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ā)送信息給相關人員。技術負責人根據(jù)事先定義的標準來判定是否回滾。bbs.mypm.net
下面用故事地圖的形式描述持續(xù)交付的內(nèi)容(詳見圖三)：
圖三項
角色是每個故事中起主導的角色。藍色線上的故事是最小可行產(chǎn)品(即可使用敏捷方式進行過程改進，MVP是可以先做后根據(jù)效果進行完善的最小改進過程)，也是以敏捷思維去考慮持續(xù)交付和DevOps的內(nèi)容。