微服務開發的軟件過程
支付系統基礎設施建設一文簡單描述了持續集成的所需要的基礎軟件。這里我們從軟件過程的角度，詳細介紹這些步驟。 支持持續集成所需要的基礎軟件，在該文中有介紹，請大家務必先閱讀。 這里我們以基于jira的過程管理為例來講述。 關于Jira軟件本身介紹、相對Redmine的優勢等問題，請大家自行查閱資料，不在本文介紹范圍。 在介紹這個過程之前，先強調一個觀點：
- 人管代碼，代碼管機器
- 人管代碼，代碼管機器
- 人管代碼，代碼管機器
一、軟件過程
Jira原是設計來進行Bug跟蹤的系統，后來系統功能逐步完善后，被廣泛適用于軟件過程管理。Jira優勢在于簡單，好用。 這里就不介紹Jira的具體使用。 使用Jira進行軟件項目管理，首先需要定義任務的處理流程。 以下是一個參考流程：
在這個流程中，需要區分兩個概念：任務和子任務。 每個任務對應一個完整的業務需求，比如對賬、對接工行借記卡、獲取個人優惠券列表接口。這些業務需求每個都是可以獨立測試的。子任務設置相對比較簡單，每個子任務對應這在本次任務執行中需要修改的開發項目。 比如對接工行借記卡，會涉及到：
- 支付網關項目調整;
- 支付路由項目中增加路由選項;
- 工行借記卡通道對接。
三個項目的修改，那會對應在這個任務下建立三個子任務。
- 任務是用來追蹤項目過程的，這是項目經理和產品經理關注的層次。
- 子任務是用來支持開發自動化的，這是開發人員關注的層次。
這樣，針對任務和子任務，會設置不同的屬性：
1.1 需求管理
Jira也是一個不錯的需求管理工具。產品經理可以通過Jira來執行需求管理，相對開發來說，需求管理流程會比較簡單，一般是開發需求、審核需求、關閉需求三個環節即可。 需要注意的地方是：
- 需求管理流程需要和開發流程分離，畢竟這是不同的團隊做的事情。
- 開發任務可以和需求任務相關聯。Jira通過復制任務來提供這個支持。
一個需求任務可以對應多個開發任務，這在實際操作中是很常見的：
- 為了滿足上線要求，一個需求任務會被拆分成多個開發任務，先完成核心功能開發并上線，再完成外圍功能開發。這兩次獨立上線的工作，會被拆分為2個或者更多的開發任務;
- 如果對不同平臺，比如Android，IOS，PCweb有不同的上線時間要求和技術需求，也需要將當前需求按照目標平臺來拆分成開發任務。
1.2 創建任務
如上所述，開發任務的來源有兩個：
- 需求任務，即對應產品經理提的需求
- 優化任務，這一般是開發團隊內部進行重構或者性能優化來提的開發任務。
那任務的粒度如何把握? 每個開發任務是一個完整的需求，是可以獨立執行測試和驗證的。 每個任務開發周期控制在1個月以內。
1.3 創建子任務
在接收到開發任務后，開發人員需要對系統實現進行設計和分解，確定需要新開發的內容以及需要改進的工作。 在微服務架構中，一次任務開發會涉及到多個系統的變更。這樣就需要為每個系統建立一個獨立的子任務，以后，我們將按照這個子任務的設置來驅動開發流程。 每個子任務開發周期盡量限制2天以內，不能超過一周。
1.4 啟動主任務開發
主任務啟動開發流程比較簡單，主要是郵件通知到各相關人員，可以啟動該任務。
1.5 啟動子任務開發
子任務的啟動和執行，是整個流程的核心工作。
這里如果是使用git/gitlab來做版本控制，整個流程的要點在于：
- 如果需要新建項目來開發，則由開發人員填寫新項目的名稱、類型(Web， RPC， 工具類等)，在git上創建一個項目框架，包含必要的基礎文件。
- 郵件通知開發人員需要下載的項目代碼庫地址。
- 開發人員簽出代碼到本地，執行開發工作。
- 開發人員隨時可以簽入代碼到服務器上，發出Merge Request;
- gitlab在接受簽入前，執行靜態代碼檢查。靜態代碼檢查的工具有findbugs, PMD, Sonar等。 開發人員在開發時也必須自我進行靜態檢查，這里執行檢查是避免開發人員漏查。
- 執行單元測試;
- 通知相關人員進行代碼審核;
- 執行代碼審核;
- 符合審核條件(如至少有2個人同意)，審核通過， 代碼被自動合并到主干版本。
- 通知子任務可以提測。 當然，是否提測，是由開發人員來決定。
1.6 子任務和任務提測
子任務開發完成后，即可提測。子任務提測時，將觸發Jenkins進行測試環境部署。 測試有兩種方式：自動測試和人工測試。盡量采用自動測試，使得開發人員能夠及時發現問題。 所有子任務完成后，主任務可以提測。主任務提測后，如果是人工測試，則測試人員介入開始執行測試任務;如果是自動測試，則開始運行集成測試腳本。
測試通過后， 既可以準備上線。
1.7 預部署和全部署
一般上線會分為兩步，預部署和全部署。預部署的目的是先驗證系統在線上環境運行是否正常，減少回滾成本。特別是在部署服務器特別多的情況下，先部署1-2臺機器，可以在線上驗證本次上線是否可以。 驗證通過后，既可以執行全部署。 注意，預部署和全部署都是針對子任務而言。
少數公司會要求上線前進行審批，但這樣做是不利于流程自動化的。 一天幾十次上線，誰能知道這是不是可以上。 但有一點很重要，系統上線前，必須通知到相關的使用方。如果出現問題，使用方可以盡快知悉。
二、項目文件結構
開發參考目錄結構：
從這個目錄里面我們可以看到，和項目相關的部署用腳本，需要由項目開發人員自己來維護，用以保證部署工作能夠自動執行。包括驗證項目部署成功的腳本。 驗證項目是否部署成功，一種方式是在日志中打樁，grep到這個日志，即意味著系統成功啟動;一種方式是調用接口來驗證是否成功。
部署目錄參考：
總之，微服務項目的管理核心理念在于“自動化”，消除人為因素。人管代碼，代碼管機器，最終目標是要實現自動上線。 消除人工測試，取代以自動化測試;消除人工驗證，取代以自動驗證;消除人工部署，取代以自動化部署。 這樣，再多的項目，也能夠很好的進行管理。
【本文為51CTO專欄作者“鳳凰牌老熊”的原創稿件，轉載請通過微信公眾號“鳳凰牌老熊”聯系作者本人】
