自動化部署方案
由於來來也的時間不久，可能對現有的部署情況不是很了解，以下是個人對POC自動化部署的設計方案。
自動化部署優點
降低成本，提高生產力，高可用，更可靠，性能優化
與gitlab持續集成的比較流行的有jenkins和gitlab-ci
Jenkins:
優點：編譯服務和代碼倉庫分離，而且編譯配置文件不需要在工程中配置，如果團隊有開發、測試、配置管理員、運維、實施等完整的人員配置，那就采用jenkins，這樣職責分明。jenkins依靠它豐富的插件，可以配置很多gitlab-ci不存在的功能，比如說看編譯狀況統計等。
缺點：配置相對復雜，維護成本較高等
gitlab-ci:
優點：完美和gitlab進行集成，gitlab-ci已經集成進gitlab服務器中，在使用的時候只需要安裝配置gitlab-runner即可。 gitlab-runner基本上提供了一個可以進行編譯的環境，負責從gitlab中拉取代碼，根據工程中配置的gitlab-ci.yml，執行相應的命令進行編譯。
缺點：功能相對少一些，沒有web頁面查看等
總結：
個人覺得gitlab-ci更簡單易用，如果有gitlab-ci達不到的要求，可以考慮使用jenkins。如果只部署poc相似的項目使用gitlab-ci可以滿足需求。
方案一：gitlab-ce + gitlab-runner + docker
從左往右看，首先研發人員完成需求提交代碼到 GitLab。GitLab 觸發一次 Build，構建好服務，然后開始跑單元測試、集成測試。等待測試結果通過后，再由負責該項目的同事進行 CodeReview（可省略），灰度發布，正式部署到線上，支持shell部署和docker部署。
gitlab-ce 代碼倉庫管理與pipeline主控台
gitlab-runner 則是當pipeline啟動時，會根據gitlab特有的gitlab-ci.yml執行CI/CD
gitlab-ce 每個project會有一組自己的token，用以注冊gitlab-runner
gitlab-runner注冊時，可以選擇執行方式(executor)，我們選擇docker
gitlab-runner會另外開幾個container來pull code與執行CI/CD，最后push到服務器上
主要步驟：
編寫統一格式dockerfile，如果多應用關聯編寫docker-compose文件
編寫統一pipeline，注冊ci-runner等
上圖是一個典型的 Pipeline，一共有 5 個階段，Build，Test，Release， Staging， Production，每個階段里都至少有一個 Job，Test 中有兩個 Job。GitLab 會從左往右依次把任務給到 Runner 處理，如果中途有一個任務沒有處理成功的話，整個 Pipeline 就會退出。這就是持續集成（CI）、持續發布（CD） 的一個流程。
方案二：gitlab + jenkins + docker
- 開發者向自己的gitlab網站提交了代碼
- 通過webhook讓jenkins執行自動化構建過程
- jenkins從git上拉取代碼進行構建，如構建失敗可配置郵件通知開發人員
- jenkins在自動化構建腳本中調用docker命令將構建好的鏡像push 私有鏡像服務器
- 同時，jenkins也可以直接執行remote shell啟動構建好的容器
- 服務端可以手動通過docker命令，從鏡像倉庫中心拉取鏡像，進行手動
總結：個人意見如果只部署poc類似不是很復雜的應用可以選擇方案一滿足
原因：配置簡單使用方便，可以花較少的時間完成自動化部署，節約成本，主要比較符合現狀。但是如果以后需要區分環境部署，做一些類似sonar代碼的健康檢查等，可能不能很好的完成。
個人不成熟建議：隨時時間變長，poc的項目也會越來越多，每個人的項目也會越來越多，可能需要一些資產的管理，例如CMDB，權限系統控制每個人操作的權限等，可以引入devops的概念，從急需的需求，慢慢做起。