說一說，正常上線的流程

不少時候，經驗是被痛苦逼出來的，流程是被錯誤逼出來的。在上線的過程中，這段時間遇到了一些問題，形成了研發耽誤了很多時間。緣由是上線的不規範性以及沒有任何的權限限制。

另外互聯網項目版本開發都很是頻繁。一天上線十幾個小版本，也是有可能的。像我如今的公司，常常一天修改好屢次文案，就須要不斷的上線。若是處理不及時上線的話，會形成用戶的一些誤解，致使一些投訴以及很差的用戶體驗。這麼頻繁的修改上線，也是須要必定的流程和規範保證。

Git 代碼管理

不少互聯網公司都開始使用Git，替換了svn。Git很是適合互聯網迭代以及多人多版本開發。若是讓我說爲何喜歡使用Git，我喜歡切換分支，以及分支之間merge的方便快捷。

新建分支以及合併分支的便利性，會形成一些問題，分支不天然的就會過多。因此須要定時的須要刪除一些過期的分支。

項目分支

通常來講，互聯網項目有上線分支，預上線分支，測試分支，開發分支等．

保證不一樣的分支作不一樣的事情，防止分支污染。

1. 上線分支，是發佈到線上的分支，以這個分支爲準，其餘分支都是以這個分支爲基礎拉取。
2. 預上線分支，在預上線環境當中，防止出錯的最後一道保證。
3. 測試分支，可能測試環境你們共用一套，因此把代碼都merge到這裏，而後發佈。這樣你們各自測試本身的，互不打擾。若是有多個測試環境的話，直接使用開發分支測試也是能夠的。
4. 開發分支，從上線分支拉取，根據需求修改的新分支。

開發流程

上面的這張圖看起來有一點複雜。整體上來，能夠分爲這麼幾步。

1. 第一步，需求來了以後，從上線分支拉取一個開發分支。
2. 第二步，在開發分支進行開發，自測。
3. 第三步，合併到測試分支，通知QA測試。
4. 第四步，若是經過測試，合併到預上線分支，而後繼續測試。若是不經過測試，進入第二步。
5. 第五步，若是預上線測試經過，將預上線分支合併到上線分支。若是不經過測試，進入第二步。
6. 第六步，上線，而後線上測試。若是經過測試，那麼這個需求開發就結束了。若是沒有經過測試，就撤回上線，而後進入第二步。

分支規範

1. 測試分支以及預上線分支要定時清理，和上線分支同步。
2. 上線分支以及預上線分支，merge權限保證在少數人手裏。merge的時候，須要檢查提交以及對線上的影響。
3. 只能在開發分支修改代碼，其餘分支都是等着被merge.
4. 提交以前，須要保證和上線分支沒有衝突。
5. 防止分支被污染，特別是受到測試分支污染。

流程規範以外

人是最難管理的，以及人是懶惰的。這些話是很是準確的，因此會遇到一下問題，還得須要解決。

1. 需求改動很是小，是否是還得走總體流程。
2. 我只是修改文案，是否是還得走總體流程。

具體怎麼作，每個公司和組都有本身的作法，是否是都必須都得走一遍流程。可是，分支規範是必須的，不能隨意修改。直接在上線分支修改，堅定說NO!

若是轉載的話，請註明轉載地址，萬馬奔騰博客，http://www.woniubi.cn/service_online_process/