支付系統(tǒng)基礎(chǔ)設(shè)施建設(shè)一文簡單描述了持續(xù)集成的所需要的基礎(chǔ)軟件。這里我們從軟件過程的角度，詳細介紹這些步驟。 支持持續(xù)集成所需要的基礎(chǔ)軟件，在該文中有介紹，請大家務(wù)必先閱讀。 這里我們以基于jira的過程管理為例來講述。 關(guān)于Jira軟件本身介紹、相對Redmine的優(yōu)勢等問題，請大家自行查閱資料，不在本文介紹范圍。 在介紹這個過程之前，先強調(diào)一個觀點：

- 人管代碼，代碼管機器

- 人管代碼，代碼管機器

- 人管代碼，代碼管機器

一、軟件過程

Jira原是設(shè)計來進行Bug跟蹤的系統(tǒng)，后來系統(tǒng)功能逐步完善后，被廣泛適用于軟件過程管理。Jira優(yōu)勢在于簡單，好用。 這里就不介紹Jira的具體使用。 使用Jira進行軟件項目管理，首先需要定義任務(wù)的處理流程。 以下是一個參考流程：

在這個流程中，需要區(qū)分兩個概念：任務(wù)和子任務(wù)。 每個任務(wù)對應(yīng)一個完整的業(yè)務(wù)需求，比如對賬、對接工行借記卡、獲取個人優(yōu)惠券列表接口。這些業(yè)務(wù)需求每個都是可以獨立測試的。子任務(wù)設(shè)置相對比較簡單，每個子任務(wù)對應(yīng)這在本次任務(wù)執(zhí)行中需要修改的開發(fā)項目。 比如對接工行借記卡，會涉及到：

1. 支付網(wǎng)關(guān)項目調(diào)整;
2. 支付路由項目中增加路由選項;
3. 工行借記卡通道對接。

三個項目的修改，那會對應(yīng)在這個任務(wù)下建立三個子任務(wù)。

• 任務(wù)是用來追蹤項目過程的，這是項目經(jīng)理和產(chǎn)品經(jīng)理關(guān)注的層次。
• 子任務(wù)是用來支持開發(fā)自動化的，這是開發(fā)人員關(guān)注的層次。

這樣，針對任務(wù)和子任務(wù)，會設(shè)置不同的屬性：

1.1 需求管理

Jira也是一個不錯的需求管理工具。產(chǎn)品經(jīng)理可以通過Jira來執(zhí)行需求管理，相對開發(fā)來說，需求管理流程會比較簡單，一般是開發(fā)需求、審核需求、關(guān)閉需求三個環(huán)節(jié)即可。 需要注意的地方是：

1. 需求管理流程需要和開發(fā)流程分離，畢竟這是不同的團隊做的事情。
2. 開發(fā)任務(wù)可以和需求任務(wù)相關(guān)聯(lián)。Jira通過復制任務(wù)來提供這個支持。

一個需求任務(wù)可以對應(yīng)多個開發(fā)任務(wù)，這在實際操作中是很常見的：

1. 為了滿足上線要求，一個需求任務(wù)會被拆分成多個開發(fā)任務(wù)，先完成核心功能開發(fā)并上線，再完成外圍功能開發(fā)。這兩次獨立上線的工作，會被拆分為2個或者更多的開發(fā)任務(wù);
2. 如果對不同平臺，比如Android，IOS，PCweb有不同的上線時間要求和技術(shù)需求，也需要將當前需求按照目標平臺來拆分成開發(fā)任務(wù)。

1.2 創(chuàng)建任務(wù)

如上所述，開發(fā)任務(wù)的來源有兩個：

• 需求任務(wù)，即對應(yīng)產(chǎn)品經(jīng)理提的需求
• 優(yōu)化任務(wù)，這一般是開發(fā)團隊內(nèi)部進行重構(gòu)或者性能優(yōu)化來提的開發(fā)任務(wù)。

那任務(wù)的粒度如何把握? 每個開發(fā)任務(wù)是一個完整的需求，是可以獨立執(zhí)行測試和驗證的。 每個任務(wù)開發(fā)周期控制在1個月以內(nèi)。

1.3 創(chuàng)建子任務(wù)

在接收到開發(fā)任務(wù)后，開發(fā)人員需要對系統(tǒng)實現(xiàn)進行設(shè)計和分解，確定需要新開發(fā)的內(nèi)容以及需要改進的工作。 在微服務(wù)架構(gòu)中，一次任務(wù)開發(fā)會涉及到多個系統(tǒng)的變更。這樣就需要為每個系統(tǒng)建立一個獨立的子任務(wù)，以后，我們將按照這個子任務(wù)的設(shè)置來驅(qū)動開發(fā)流程。 每個子任務(wù)開發(fā)周期盡量限制2天以內(nèi)，不能超過一周。

1.4 啟動主任務(wù)開發(fā)

主任務(wù)啟動開發(fā)流程比較簡單，主要是郵件通知到各相關(guān)人員，可以啟動該任務(wù)。

1.5 啟動子任務(wù)開發(fā)

子任務(wù)的啟動和執(zhí)行，是整個流程的核心工作。

這里如果是使用git/gitlab來做版本控制，整個流程的要點在于：

1. 如果需要新建項目來開發(fā)，則由開發(fā)人員填寫新項目的名稱、類型(Web， RPC， 工具類等)，在git上創(chuàng)建一個項目框架，包含必要的基礎(chǔ)文件。
2. 郵件通知開發(fā)人員需要下載的項目代碼庫地址。
3. 開發(fā)人員簽出代碼到本地，執(zhí)行開發(fā)工作。
4. 開發(fā)人員隨時可以簽入代碼到服務(wù)器上，發(fā)出Merge Request;
5. gitlab在接受簽入前，執(zhí)行靜態(tài)代碼檢查。靜態(tài)代碼檢查的工具有findbugs, PMD, Sonar等。 開發(fā)人員在開發(fā)時也必須自我進行靜態(tài)檢查，這里執(zhí)行檢查是避免開發(fā)人員漏查。
6. 執(zhí)行單元測試;
7. 通知相關(guān)人員進行代碼審核;
8. 執(zhí)行代碼審核;
9. 符合審核條件(如至少有2個人同意)，審核通過， 代碼被自動合并到主干版本。
10. 通知子任務(wù)可以提測。 當然，是否提測，是由開發(fā)人員來決定。

1.6 子任務(wù)和任務(wù)提測

子任務(wù)開發(fā)完成后，即可提測。子任務(wù)提測時，將觸發(fā)Jenkins進行測試環(huán)境部署。 測試有兩種方式：自動測試和人工測試。盡量采用自動測試，使得開發(fā)人員能夠及時發(fā)現(xiàn)問題。 所有子任務(wù)完成后，主任務(wù)可以提測。主任務(wù)提測后，如果是人工測試，則測試人員介入開始執(zhí)行測試任務(wù);如果是自動測試，則開始運行集成測試腳本。

測試通過后， 既可以準備上線。

1.7 預(yù)部署和全部署

一般上線會分為兩步，預(yù)部署和全部署。預(yù)部署的目的是先驗證系統(tǒng)在線上環(huán)境運行是否正常，減少回滾成本。特別是在部署服務(wù)器特別多的情況下，先部署1-2臺機器，可以在線上驗證本次上線是否可以。 驗證通過后，既可以執(zhí)行全部署。 注意，預(yù)部署和全部署都是針對子任務(wù)而言。

少數(shù)公司會要求上線前進行審批，但這樣做是不利于流程自動化的。 一天幾十次上線，誰能知道這是不是可以上。 但有一點很重要，系統(tǒng)上線前，必須通知到相關(guān)的使用方。如果出現(xiàn)問題，使用方可以盡快知悉。

二、項目文件結(jié)構(gòu)

開發(fā)參考目錄結(jié)構(gòu)：

從這個目錄里面我們可以看到，和項目相關(guān)的部署用腳本，需要由項目開發(fā)人員自己來維護，用以保證部署工作能夠自動執(zhí)行。包括驗證項目部署成功的腳本。 驗證項目是否部署成功，一種方式是在日志中打樁，grep到這個日志，即意味著系統(tǒng)成功啟動;一種方式是調(diào)用接口來驗證是否成功。

部署目錄參考：

總之，微服務(wù)項目的管理核心理念在于“自動化”，消除人為因素。人管代碼，代碼管機器，最終目標是要實現(xiàn)自動上線。 消除人工測試，取代以自動化測試;消除人工驗證，取代以自動驗證;消除人工部署，取代以自動化部署。 這樣，再多的項目，也能夠很好的進行管理。

【本文為51CTO專欄作者“鳳凰牌老熊”的原創(chuàng)稿件，轉(zhuǎn)載請通過微信公眾號“鳳凰牌老熊”聯(lián)系作者本人】

戳這里，看該作者更多好文