網際網路創業公司基於Gitlab/Jenkins的專案版本管理方案
網際網路創業公司基於Gitlab/Jenkins的專案版本管理方案
關於Gitlab
Gitlab是一個用於倉庫管理系統的開源專案，使用Git作為程式碼管理工具，並在此基礎上搭建起來的web服務。相比SVN，Git管理程式碼工具最大的優勢是允許分支自由拉取、切換與合併。建立一個工程便可管理多個分支，且允許面向同一個產品的不同開發小組並行開發，互不干擾。
關於Jenkins
Jenkins是一個開源軟體專案，是基於Java開發的一種持續整合的工具，用於監控持續重複的工作，旨在提供一個開放易用的軟體平臺，使軟體的持續整合變成可能。Jenkins主要功能有兩個，一個是持續自動的構建/測試軟體專案，另一個是監控軟體開放流程，快速定位處理問題。
關於創業公司侷限性
其實網上已經有許多關於Git的專案版本管理方案，之所以還要寫這篇部落格，是因為許多方案要麼是通識性的，要麼僅適用於大公司，並沒有一套針對創業型公司比較實用的方案。相比大公司，創業型公司有諸多侷限，比如環境資源有限，測試團隊有限，通常無法完美實現Git方案中的並行模式（並行一般意味著需要豐富的資源），而是採用序列+並行結合的方式實現較為高效的管理。本文將展現如何利用最少資源實現相對高效順暢的Git管理，相信大部分創業型公司面臨的都是類似情況。
Git管理方案
六大分支介紹
master
master分支為線上主分支，存放隨時可以在生產環境中部署的程式碼。
該分支由運維人員維護，其他人只有拉取許可權。
生命週期： 伴隨著整個專案的週期，專案結束時結束。
develop
develop分支為開發主分支，所有其他分支修改過的記錄全部要合入該分支，確保develop分支包含所有修改與新增的程式碼。轉測時的bug修改在該分支進行。
該分支由開發人員維護。
生命週期： 伴隨著整個專案的週期，專案結束時結束。
release
release分支為測試主分支，存放轉測程式碼。轉測分兩種狀態：通過與不通過。通過的話則將程式碼同步到master分支準備上線，不通過的話則反饋開發在develop分支上修復bug。
該分支由測試人員維護。
生命週期：
注： 其他版本的管理方案會將bug修改安排在release分支上進行，而我們不採用這樣的方案。一來因為release分支的程式碼是從develop同步過去，在develop上修改bug也是一樣。二來我們認為分支的功能越單一，則管理越高效。release分支僅用於轉測就足夠了，減少了開發人員的分支維護數量。三來其他版本之所以選擇在release分支上修改bug，是為了將develop分支騰出來可以合入新的分支程式碼。這種選擇在有多組測試人員多個環境並行測試的情況下，的確能大大提高效率，快速迭代。但由於創業型公司的測試人數和環境限制，並不能達到並行測試的理想狀態，所以我們在此處做了調整。
feature
featuren分支為迭代開發分支，負責產品主功能迭代。從develop分支拉取，開發完成後再合併回develop分支。
該分支由開發人員維護。
生命週期： 從一個新功能開始，到開發完成合入develop分支結束。
operation
operation分支是我們新增的一個概念，對應的是運營活動分支。其管理模式和feature分支差不多，但因為一些公司的開發團隊和運營團隊是分開的，運營活動和功能迭代也是交錯進行，所以將該分支獨立出來說明。該分支同樣也是從develop分支拉取，開發完成後再合併回develop分支。
該分支由開發人員維護。
生命週期： 從一個新運營活動開始，到開發完成合入develop分支結束。
注： operation分支的開發最好是和featuren分支同步，一起轉測。假如無法同時完成，根據優先順序和完成時間安排先後轉測上線。如果有特別緊急的運營活動，則通過hotfixes分支上線。
hotfixes
hotfixes分支為緊急修復分支，當線上出現嚴重問題或者有特別緊急的需求/運營活動上線，則直接從master分支單獨拉取出來，在該分支修改、測試，然後上線並同步合入develop分支。
該分支由開發人員和測試人員共同維護。
生命週期： 問題出現到問題修復 / 新功能開始到上線
注： hotfixes分支對於所有人來說都是最高優先順序。假如在轉測期間出現了要拉hotfixes情況，則轉測中止，測試環境需要轉去測試hotfixes分支程式碼。測試通過後hotfixes分支的程式碼合入develop分支，再同步到release分支，重新開始測試。
資源背景
一組測試人員（序列測試）
2-3套部署環境（資源緊張的話測試和開發共一套環境，線上一套環境）
4套Jenkins配置（開發，測試，線上和hotfixes）
一組功能開發人員
一組運營活動開發人員
