持續集成開篇之（一）代碼發布流程

最近在網上看了不少有關CI/CD的文章，其實基本是雷同的，且內容也不是非常完善。確實，當前持續集成用到的開源工具無非還是Git、Jenkins、Ansible(Fabric)這些，不同的應該是各公司的技術框架差異，發布審核流程不同，從而使配置細節也有較大不同。接下來我要分享的一系列文章均是圍繞生產版本發布、集群中間件搭建以及監控來寫，并且都是這些年（2014-至今）我們一直還在用的技術（包括具體環境搭建以及前后端發布等細節），歡迎拍磚，共同探討。

我們一直沿用的一套流程如下：

0、在公司內部搭建gitlab服務器，員工自行在公司gitlab服務器通過公司郵箱完成賬號注冊。

1、配置管理員在gitlab上創建project(項目或倉庫)，建議按業務線或功能先分group(組)，然后再在group下創建具體的project，避免所有project混在一個group。

2、源碼放在源碼project；編譯后可用于發布包放在可發布的project。

3、配置管理員對已注冊開發人員分配權限（master、develop、Reporter等），權限可在group上分配，也可細到某個project。

4、開發人員通常只分配develop權限且在develop分支進行開發，開發人員不允許直接提交代碼到master(主分支)，如需提交到master，則需要發出合并請求，由項目管理者review后決定是否合并。

5、源代碼合并后，由合并者打tag觸發jenkins構建出用于發布的版本包，并推送到對應發布代碼的project中，同步tag，同時根據最新tag發布到測試環境。

6、在經過代碼審查、集成測試、功能測試以及安全性測試等都通過后，且經產品人員確認同意發布，再使用jenkins將測試通過的tag發布到RC環境。

7、RC運行正常，產品人員確認同意發布到生產，再使用jenkins將RC通過的tag（測試和RC的tag均是同一個）發布到生產環境。

8、如果發布后出現異常，則使用jenkins按上一次正常tag進行回滾。

上述是一個較理想的流程，但實際開發過程中，一名開發人員可能身兼多職，包括編碼、測試等，所以可能更通用的流程如下圖1描述所示。

圖1
同樣，一般中小規模公司，一般只有一到兩名運維人員，那么在維護上述發布框架同時，該名運維人員常備的技能如下：

0、與開發、測試、產品同學之間的和諧溝通及協調能力。

1、Gitalb搭建以及配置管理功能，包括備份恢復、郵件通知、權限分配、通過API創建project、Webhooks、tag（標簽）規范化并實現自動生成tag等常用維護操作。

2、Jenkins環境搭建以及配置管理功能。包括插件安裝、權限分配、郵件通知、腳本創建job、參數化構建等。

3、腳本編寫能力，包括Shell、Fabric或借助Ansible完成代碼編譯、推送、發布（回滾也是發布）等。

4、日志集中收集，如配置syslog-ng和ELK，個人更傾向于用syslog-ng完成集中收集，然后用ELK來展示，因為在發布過程中開發人員更習慣使用tailf來查看發布過程中是否報錯以便及時回滾。

5、監控，推薦使用Zabbix+Grafana，也可使用Nagios。實現對網絡設備監控（CPU、內存、溫度、接口流量等）、服務器硬件監控（通過IPMI接口獲取硬件故障信息）、系統監控（內存、CPU、磁盤空間和IO、負載、網卡流量、文件句柄等）、集群中間件監控（集群狀態、CPU、內存使用、日志等）服務監控（進程、端口、響應狀態碼、日志等）、數據庫監控（常用命中率指標、表空間、慢查詢、日志等）、業務監控等，確保業務7*24不時不中斷穩定運行。

6、集群中間件搭建以及維護能力，諸如Zookeeper、Redis、Mongodb、RabbitMQ、RocketMQ等。

7、數據庫集群搭建以及維護能力，包括Oracle、MySQL。不過，現在中小規模公司基本在云上，主要用的是RDS，個人覺得阿里云RDS的性能監控可視化做得非常棒，遠超AWS。

總結：干運維真得非常不容易，分分鐘就會當背鍋俠，請對運維好一點！
下一篇：Gitlab搭建與配置技巧