大咖分享 | ProjectMan是如何煉成的

你們好，我是華爲雲DevCloud 管理與協同域的產品經理恆少，

有句話叫作：「Soda&恆少出品，一定來自雙手沾滿泥的精品實踐」。

隨着DevCloud的客戶逐步瞭解敏捷/DevOps的理念，並實際基於DevCloud進行軟件交付後，更多的客戶提出新的問題：大家能不能分享大家天天都怎麼開發的，大家的團隊組織是怎樣的？有哪些坑?有哪些雷？

爲此本期的「雙手沾滿泥」的精品實踐，特別邀請長期與恆少奮戰的Service Leader，咱們的Soda，親自撰文「Projectman 是如何煉成的」，感謝Soda.

前言

提到ProjectMan，可能不少人沒聽過，可是隻要提到中文名稱：項目管理服務，很多用戶可能會據說。簡單說，ProjectMan是DevCloud的一個服務，提供項目、成員、需求及缺陷管理等功能，是DevCloud使用最頻繁、用戶最多、UV/PV都比較高的服務。

而我就是這個服務的研發團隊負責人。有一次，一個客戶跟我反饋說，他們在研發的過程當中，常常遇到各類各樣的技術問題，而華爲有三十年研發經驗，能不能分享一些技術方面的文檔，讓他們可以參考和學習，提升自身的研發效率，避免走一些彎路。我認爲確實頗有道理，客戶的研發效率提升了，既對客戶有益，也符合華爲的利益。因而我先拋磚引玉，先介紹一下咱們服務，若是效果好，可能會有更多比我經驗更豐富的專家出來分享技術乾貨，但願最後DevCloud不只是提供研發效能的服務，也能造成一個華爲與客戶之間技術分享和交流的平臺。

咱們的故事

不少IT創業公司在最開始的時候，爲了快速搶佔市場，對產品研發的時間要求是很是短的。咱們也同樣，第一個版本要求在一個月內上線。爲了快速開發，咱們調研了不少已有的項目管理工具，最終選擇了基於公司內部的一個已有的架構進行開發。後端使用SpringMVC+ MyBatis框架，MySQL數據庫，前端頁面則使用Angular框架開發。

像大多數系統同樣，第一個版本上線之後，大量的需求蜂擁而至。隨着不斷疊加的功能，代碼的複雜度變得愈來愈高，維護成本也愈來愈大。

去年年末，咱們頂着巨大的壓力，對系統進行重構。爲了使代碼解耦，功能模塊之間能夠獨立升級，咱們把後臺一個微服務拆分紅了四個微服務。同時咱們更換成了功能更強大的Spring Cloud框架。

在系統重構的幾個月裏，咱們並無中斷需求的交付，仍然以每週一個迭代，每一個迭代幾十個需求的節奏運做，一直到今年3月份才完成。重構以後，咱們的代碼結構獲得了優化，不會互相影響，現網的問題比重構前減小了80%以上，並且不一樣功能模塊之間升級互不影響，平均天天至少一個微服務在升級，大幅提升了需求交付效率。接下來我就介紹一下咱們是如何運做的。

團隊運做

1.咱們的團隊是全功能團隊，獨立負責ProjectMan端到端的交付和運維。總共有10名開發人員，包括4名前端和6名後端，由於總共有6個微服務，因此平均不到2我的負責一個微服務。並且，沒有專門的測試和運維人員，全部測試和運維工做所有由開發人員承擔，例如用例、環境部署等，能夠說咱們每一個團隊成員都是集開發、測試、運維能力於一身的全能型人才，每一個角色在主要工做分佈上略有不一樣，做爲Service Leader的我會更多承擔一些服務設計的工做，可是我寫的代碼，也必定是我本身測試，本身部署

​

2.研發流程模式上，咱們採用scrum，固定每週一個迭代，每一個迭代會發布多個版本。爲了打磨咱們的產品，咱們全部的工做都使用DevCloud ProjectMan上來管理，用業界時髦的實踐就是「吃狗糧」。產品經理會將需求按照Epic-Feature-Story的層級整理好，而後經過迭代會議制定迭代計劃，大概的流程圖以下：

​

​

3.分支模式。Projectman有好多個微服務，每一個微服務在開發過程當中，都是採用分支開發，主幹發佈的方式，具體的流程以下：

​

• Master分支要時刻保持可發佈版本的狀態；

• Develop和release分支是測試分支，對應不一樣的測試階段；

• 每一個特性都要單獨拉feature分支開發，併合入Develop和release分支進行測試，測試經過後才能合入master分支；

• 在迭代的過程當中，若是遇到現網問題，則在master分支拉取代碼到hotfix分支，測試經過後再合入master分支發補丁；

• 代碼review只須要在release和hotfix分支合併到master分支時進行就能夠過攔截大多數代碼缺陷

這樣的分支管理方式，每一個特性完成開發後，測試經過便可發佈上線。一個需求完成以後無需等待統一版本，能夠靈活發佈。4月份，咱們總共發佈了40多個版本，平均每一個工做日2個版本。

持續發佈，持續監控

既然發佈版本這麼頻繁，若是沒有一個高效的發佈工具，是萬萬辦不到的。這個工具就是DevCloud上的流水線，及其調用的代碼檢查、編譯構建、部署等任務。每一個微服務會建立一條流水線，上面集成了代碼檢查、編譯構建、部署、自動化測試等任務。並且一條流水線會將全部環境串聯起來，研發環境測試經過以後，才能執行下個環境，最後是生產環境。雖然華爲的研發流程比較複雜，發佈到生產環境以前要在其餘4個環境測試經過，可是因爲這些都由流水線自動完成，因此總共只須要20-30分鐘便可完成版本發佈。

在現網，咱們使用了不少華爲雲的其餘資源，系統是部署在華爲雲的ECS上，總共幾百臺虛擬機實例，數據庫使用RDS，文件存儲使用SFS等等。得益於自動化運維平臺，這些資源，咱們開發人員本身能夠維護。咱們不只能夠在全部節點查看日誌、下載文件，還能批量在虛擬機上執行腳本等等。不只如此，爲了能快速響應現網問題，咱們採用監控平臺對現網的報錯進行監控。一旦報錯，哪怕只是一個錯誤碼，或者拋個異常，都會被監控平臺捕捉到，而且會精確到哪行代碼出了問題，而後給負責人發短信提醒。除了對異常的監控，咱們對性能指標、資源使用狀況等都有監控。

結束語

做爲一個Service Leader，業務交付的效率，服務的質量，用戶的增加和活躍，架構和技術可否持續健康，甚至控制服務運行所消耗的資源成本，如何削峯填谷，都是須要平衡考慮的。這裏麪包含了不少的思考和實踐，咱們會根據你們的反饋，陸續分享一些內容。