技術團隊代碼管理和部署

時間 2019-11-15

標籤技術團隊代碼管理部署简体版

原文原文鏈接

主流公司使用svn和git做爲代碼版本管理，固然也不排除直接copy或者ftp。公司經歷了的svn到git的變遷，也深入體會到不一樣的版本管理服務，使得技術團隊的協做方式變得更爲流暢。php

簡單介紹下背景，有一個項目V5，從版本V1一直演變到如今V5，可見歷史之久，想從svn切換到git，其中的代碼管理和上線部署遷移，都會是經歷很長一段時間的不穩定，尤爲是一些開發同窗對新的版本管理和部署理解不透徹，很容易引起事故。git

在svn的主幹開發流程

開發同窗更新主幹代碼，提交代碼github
部署測試環境web
檢查每個要上線的文件版本，是否夾帶其它同窗的提交，若是有，先回滾再提交，或者是帶版本號上線，如：sql

common/request/Base.php
common/config/db.php -r 182993909

如今龐大的V5代碼庫仍然是全公司同窗往master裏更新代碼，開發團隊愈來愈大，這種原始的原始的開發方式，讓全部同窗都在一個master分支上協做的成本愈來愈大。svn

成本大在哪些地方？

團隊協做首先是要讓成員更方便得到彼此的更新，這樣才能更一塊兒完成各個模塊，最後聯調測試。成員就會把代碼加入版本管理，而項目是有時間跨度的，若是時間短的項目和大項目的代碼混合了，小項目要上線須要剝離大項目，剝離是否出錯先不說，這個時候已經影響到另一個項目了。若是遇到線上bug，須要緊急修復，須要從線上版本檢出，最後和其它成員合併，這工做量都是附加的。測試

另外，在部署的時候繁重的版本檢查，會嚴重耽誤上線時間，改代碼和驗收花了5分鐘，上線檢查和處理夾帶其它提交也花了5分鐘。這時間成本在線上事故面前，那就直接影響着你的KPI了。spa

切換到git分支開發

這，不是咱們想要的開發流程。遷移到git的分支開發是早晚的事情，它首先帶來的好處就是團隊不一樣項目的開發是相互隔離的，測試迴歸能夠靈活地選擇feature分支驗收，經過再合併到主幹。code

branch和tag

Branch: master 和 development。其中 master 對應目前的發佈分支，在這個分支只能增長從 master cherrypick 過來的 commit。development 是當前開發的分支，全部的 pull request 都應該發到這個分支。有些團隊會以master做爲開發主幹，另外推送一個online分支做爲發佈分支，名字不一樣而已。blog

Tag: 對應每一個發佈版本的 tag。 tag 遵守 tag_[milestone號]_日期的命名，如 tag_m6_2015-08-12，若是有 bugfix，則在後面增長小寫字母，如 tag_m6_2015-08-12後是 tag_m6_2015-08-12a，而後是 tag_m6_2015-08-12b。

正常開發流程

從master切feature分支開發
自測經過以後，提交 pull request 到 development（若是是大項目milestone的話，能夠先pull request到milestone分支），並通知QA部署feature分支迴歸
CodeReview標Ok，QA驗收經過後進行merge到development，若是CodeReview或者QA發現有問題，在feature分支修正再部署到測試環境，直到沒有問題
merge 驗收經過的 feature-fix 到 development
部署development分支到測試環境
測試驗收經過，merge development分支到master，打tag
發起仿真環境上線，仿真環境驗收
驗收經過，發起生產環境上線
leader審覈上線任務，發起同窗進行部署，生產環境驗收

hotfix流程

從master切hotfix分支開發
merge 確保全部要發佈的 pull request 到 master
後面與正常開發流程一致了
merge master分支到development

大項目與hotfix開發和上線流程圖

若是不是開發週期有兩三個星期的項目，迭代速度快的，一天要上線好幾個小功能的，能夠在開發完feature分支，跳過milestone分支直接merge到development分支，讓QA驗收打tag。另外，並非每一個 bug 都有專門發佈 bugfix 版的必要，對於不緊急的 bug，能夠在 master 裏 fix 後隨下一個版本發佈。