基於GitLab，Jenkins和RunDeck的持續交付系統（一）

公司計劃推行持續交付，系統更新部署再也不經過人工操做，咱們打算使用GitLab來管理源代碼，Jenkins打包項目，RunDeck將打包好的項目部署到生產環境。

在網上查了不少資料，流程大概是開發人員在GitLab中提交一個Merge Request將開發分支合併到master中，負責代碼審覈的人贊成提交後，會觸發Jenkins自動打包項目並部署到測試環境，在經過一系列自動化測試後，就會部署到生產環境。

不過這個流程不太符合咱們的要求，緣由以下

• 測試由專門的測試部門負責，只有經過測試部門的測試，項目才能部署到生產環境
• 咱們並不但願在贊成Merge Request後，項目就立刻開始打包部署到生產環境，而是但願在將來的某一個時間點纔開始，好比，開發人員今天提早提交了Merge Request，代碼也在今天經過了審覈，可是項目的上線時間倒是明天早上七點，咱們也總不能讓負責代碼審覈的人每次都那麼早回來審覈Merge Request
• 在Merge Request經過後，負責部署審覈的人須要收到部署通知郵件，並能夠在部署執行前，根據實際狀況直接在這封郵件中拒絕執行此次部署

因而咱們修改了這個流程，修改後的流程中有三個階段：開發測試階段，預發佈階段，發佈階段

開發測試階段

每次開發人員push開發分支到GitLab，都會觸發Jenkins自動打包項目並部署到測試環境，測試部門能夠在測試環境對項目進行測試

預發佈階段

與開發測試階段相似，只是開發人員push的不是開發分支，而是預發佈分支，部署的環境也不是測試環境，而是預發佈環境

發佈階段

1. 在經過測試部門的測試後，開發人員提交Merge Request，同時也提交項目部署信息，如發佈時間等
2. 代碼審覈人員贊成此次提交後，部署審覈人員會收到部署通知郵件
3. 若是在發佈時間以前，部署審覈人員都沒有拒絕此次部署，則部署會如期執行

因爲只靠GitLab，Jenkins和RunDeck沒法實現上述的發佈階段，因此須要開發一箇中間系統專門處理這些部署信息，咱們把它命名爲IT AutoDeploy Platform，加入了這個中間系統後，整個發佈階段的流程圖以下

在 基於GitLab，Jenkins和RunDeck的持續交付系統（二） 中將會大概描述一下這個系統的實現