【普及】中小企業項目上線的通常流程

在公司從事運維工做期間，發現了一些更新上線項目發佈的問題：

1，程序中寫有大量的接口調用使用的是ip地址。

2，程序中的垃圾代碼不少，用個人話說程序不乾淨，很明顯是由於交接形成的。

3，生產環境更新的備份文件壓縮文件處處亂放

      tomcat等的日誌有分割可是沒有按期清理，高達上G。配置文件  寫的一沓混亂。

4，運維人員離職竟然沒有交接文檔，更沒有生產環境的維護文檔。

      更甚的是我這個倒黴蛋竟然來了都沒人給個口頭交接，只是口頭僅此而已，沒有。

5，更新上線沒有提早通知規定，沒正式流程

      都要過年了竟然還贊成上線，穩定性意識不夠，估計仍是由於沒人看吧

6，上線進行時，開發人員圍着運維同志亂轉亂叫，徹底沒秩序

      更倒黴的是上線人員提早也不知道都上什麼不上什麼

個人建議：

1，杜絕ip地址在程序中出現，沒有域名的用寫hosts代替，須要特別標明。

2，清理程序中的垃圾代碼，保證程序的整潔。

3，清理生產環境，統一規範安裝路徑備份路徑，定時壓縮清理無用的日誌。

4，完善文檔制度，補充生產環境配置部署文檔。

5，完善更新流程，統一更新上線時間安排，及上線作好提早通知，標明上線修復的bug，及更新內容

      採用郵件形式。大更新提早1周，小更新提早1-2天。合理安排測試結束時間，建議上線最遲半日完成測試

6，靈活安排上線項目的具體次序，程序開發不得影響運維人員，有什麼特殊需求提早說明。

下面說說公司常見的項目上線工具Git的詳細使用過程

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!