[[164328]]

作者介紹

裴雙才，Geekwolf，現MAKA運維負責人，博客: http://www.simlinux.com。《FastDFS分布式存儲實戰》作者，《Ansible中文手冊》譯者。RHCA/RHCVA，混跡各種開源社區，專注高效運維、DevOps、性能優化、Docker、MySQL等方向，熱衷技術分享，歡迎一起討論技術，互相學習，共同進步。

前言

持續集成和部署是每一個互聯網開發團隊都必須要面對的問題，特別是在初創公司，由于業務和技術團隊快速增長，技術積累較弱，所以一個高效的，可持續的運維規范尤為重要。

最近一段時間，一直在梳理項目開發流程以及自動化測試和部署規范，作為一個總結和大家分享，希望有所幫助。

高效可持續的運維環境需要合理的規范作為支撐：

• 應用管理規范
• 權限管理規范
• 配置變更規范
• 發布策略規范
• 日志運維規范

持續集成部署實戰(該內容將在后續文章中進行討論，本次不展開)

一、應用管理規范

1. 應用版本化

可以使用SVN、Git對代碼進行版本控制。

建議使用Git(如：GitLab)，并使用Git Group命名規范：大原則為根據產品域名區分，或者根據前后端業務模塊進行分組(小寫字母命名，橫杠[-]作為連接字符)。

舉例：

MAKA官網 http://www.maka.im 對應的Git倉庫Group為official，按照功能模塊分組，商城前端對應的Git倉庫Group為store。

  項目名命名規范：

•     全部用小寫字母
•     橫杠[-]作為連接字符
•     命名規則：[產品名稱]-[項目類型]-[自定義名稱]

舉例：

official-store-customer。

實踐建議：在創建項目倉庫時就要權衡前后端或者大的功能模塊的拆分，保持低耦合度。

2.合理的分支策略

常用的Git工作流總結如下：

第一種：集中式工作流，很多公司使用SVN，對Git的使用并不熟悉。如果遷移至Git之后，可以考慮集中式工作流進行開發，即代碼庫只有 master 一個分支，所有開發者只有本地 master 和遠端 master 分支。這種方式使用簡單，但無法充分發揮 git 的優勢。

第二種：功能分支工作流， 與上一種不同的地方在于，除了 master 分支以外還有功能分支。日常開發在功能分支，提測集成時提交Merge Requests(在Bitbucket中是Pull Request)。

開發者可以在這個時候進行討論、審核代碼，同意后可以合并至 master 分支，未同意則可以讓開發者修改后重新提交或者選擇關閉該MR。

舉例： third-party-login-feature 

第三種：Gitflow工作流，兩個主干分支 master(正式發布分支)和 develop(功能集成分支)。

開發者應基于 develop 分支創建 feature 功能分支，用于開發，開發完成后提交merge requests請求合并進 develop 分支。

此時若到了發布窗口，基于此時的 develop 分支創建發布分支 release 用于測試 → 預發布 → 發布，以避免影響 develop 分支的正常集成、合并功能分支；release 分支不再有新的功能合并進來，一旦創建只用于 bug 修復并將修復 cherry-pick 到develop分支；發布完成后，release 分支合并進 master 并分配版本號、打tag，用于存放發布歷史。

Gitflow工作流方式適用于大型項目

第四種：Forking工作流，開發者 fork 官方的 repo 到自己的賬號空間，對于官方分支只有只讀權限，開發者通過pull request 提交給官方審核是否合并進代碼庫；開發者通過同步上游官方的 repo 來使用其他人的代碼，分支策略可參考上述三種工作流，適合開源項目。

針對創業公司參與同一個項目的開發者并不多，過于復雜的分支策略并不能帶來便利，可以參考 leancloud 的分支模式，根據團隊的使用情況進行調整。

介紹下我們當前使用的分支策略：

• master：主干分支，用作日常開發的基線；
• userA：開發者A日常開發所在分支；
• release-201603091106： master分支集成測試完成后，構建到預發布環境時自動創建 release-201603091106 用于發布。
• hotfix-201603091106： 基于當前發布之后的 release-201603091106 分支用于修復bug，通過提交merge requests 方式合并進 release-201603091106，并將修復 cherry-pick 到master分支。

日常開發在 userA 分支操作，然后提交merge requests 請求合并至 master 分支，本地通過 git fetch origin master，然后在 userA 分支 git rebase origin/master 將 master 最新 commit 合并到本地 userA 分支從而形成閉環開發。

3.關于代碼審核

三劍客 GitLab + Jenkins + Gerrit。

Gerrit作為創業公司代碼審核工具略顯復雜，不足夠敏捷，建議使用GitLab的 Merge Requests 或者 Github 和 Bitbucket 中的 Pull Requests 作為代碼審核和討論的工具。

也可以選擇 Facebook 的 Phabricator (可同時作為代碼托管和評審，非常敏捷，由于 Phabricator 提供的工具集在 Windows 下使用起來不太友好，后來沒有選用，后期會分享 Phabricator 的使用思路和工作流)

4.目錄結構

規范的目錄結構不僅有利于開發者理解代碼結構，更有利于代碼的快速部署，以PHP為例，目錄結構建議將代碼配置文件(如：數據庫，Redis，OSS Key，語言開關，日志級別開關等)、日志文件，其他文件緩存等獨立于代碼庫之外存放。

前端項目 src 為源碼目錄，dist為前端經過壓縮合并等最終生成的代碼目錄(發布時可忽略src)。

每個項目詳細寫 README.md 文件，詳細說明，各個環境對應的訪問路徑、目錄說明、構建壓縮方式，Nginx配置等，代碼倉庫中包含額外的 test 目錄存放測試用例(本著誰開發誰寫測試用例的原則)。

二、權限管理規范

權限有兩類：一個是系統權限(包括服務器登陸，數據庫/Redis等)，另外一個是服務運行時的權限。

1. 系統權限

統一入口，受限訪問IP，禁止空密碼弱口令，生產環境服務器需要先撥入vpn之后通過跳板機才能連接成功(當然我們使用的是開源當中最好的跳板機Jumpserver)，任何人的操作都需要審計;

生產數據庫及Redis禁止了外網訪問，分別使用phpMyAdmin和RedisLive統一訪問入口，增加了多主機訪問及屏蔽了危險操作如DDL 數據的導入導出等。也需要先撥入vpn才能訪問。

開發測試環境權限控制相對寬松，DEV Leader 和 QA Leader同時具有開發和測試環境的服務器及數據庫權限，便于測試和Debug;

生產環境為了便于開發調試生產代碼，且不影響線上，增加了 Staging 節點，未在線，但環境代碼及后端均和生產一致;

2. 針對服務權限層面

以 Web 服務為例，Nginx 和 php-fpm 運行用戶和用戶組為：www-data;代碼目錄用戶為www。

這樣代碼目錄默認情況下web服務只讀，避免出現文件和目錄777權限的情況;

日志和緩存目錄用戶設置www-data，但要禁止訪問php等動態文件。

禁止危險函數phpinfo exec eval system 等，具體可參考：

http://www.sinacloud.com/doc/sae/php/runtime.html

禁止跨目錄訪問open_basedir，開啟前后的性能對比請參考：

http://www.simlinux.com/archives/1531.html

三、配置變更規范

1.系統部署

傳統IDC機房可以通過定制鏡像或者使用 Cobbler 定制安裝，運行的服務也可以定制在鏡像中，但建議安裝系統時注冊puppet/salt agent，再自動化部署相關服務。

公有云中可以在服務器上部署相應環境后創建系統快照，制作系統鏡像，彈性擴容時可選擇該鏡像自動化安裝。

2.日常變更

日常變更包括服務配置的變更和代碼配置的變更，這些操作我們是通過 Ansible，相比 puppet/salt 的好處就是簡單方便不用裝agent，后面會詳細介紹如何基于Ansible做發布回滾。變更的內容使用git進行版本控制。 

四、發布策略規范

1. 發布時間

注意：以上請根據自己業務做相應調整，避免在業務高峰期發布(除應急bug外)。

我們業務高峰期基本在18:00-23:30，低峰期基本在01:00-06:00。這也是微信分享閱讀的高峰和低峰時段。

無論應急Bug還是日常迭代都必須由QA測試通過和產品經理審核通過后才能上線。

血的教訓：曾經出現過開發為了修復線上很急的bug，開發修復后自主上線導致生產出現更嚴重的問題。

2. 發布工具的選擇

無論是自主開發發布系統，亦或是使用開源的系統都要本著解決問題的原則，否則只能是重復造輪子，然并卵呀!

開源的持續集成和發布里面個人覺得比較好的如:Jenkins，Walle，Spinnaker，go，Gitlab-ci，Bamboo(收費)等，其他參考。

https://github.com/geekwolf/sa-scripts/blob/master/devops.md

下面介紹我們基于GitLab + Jenkins + Ansible(Flamingo自動化代碼發布工具)實現的自動化代碼部署平臺，流程如下：

Flamingo：(“火烈鳥”，https://github.com/geekwolf/flamingo)是基于Ansible的自動化代碼發布工具，目的是實現統一的代碼發布方式，思路基于Capistrano，并對Ansisrano進行了改造可以通過傳入語言環境，主機組(應用組/灰度機組等)，項目代碼庫，分支名稱，項目名稱等參數來進行自動化打包發布，也可以將Flamingo工具二次打包使用。

Flamingo本著回滾即發布的原則，以簡化發布流程，回滾時傳入要回滾的分支即可，其他參數可參看defaults/main.yml進行了解;(注：依賴Git/rsync/ansible)

例子： 

ansible-playbook deploy.yml 
 
--extra-vars='flamingo_git_repo=git@github.com:geekwolf/flamingo.git flamingo_product_name=flamingo' 

 執行后生成的目錄結構如下圖(目錄定義請參考defaults/main.yml)： 

五、日志運維規范

毫無疑問，規范的日志對于運維和開發排查問題有非常大的幫助，例如PHP項目日志格式可以規范為時間，日志級別，日志內容(比如對于連接多個DB時出現連接不上或超時應該把實例地址一同寫入日志)，可以參考psr-3的標準：

http://www.php-config.org/psr/psr-3

通過ELK將業務日志，PHP自身錯誤日志/慢日志，Nginx慢日志等進行搜集統計并結合Zabbix實現報警，便于及早發現問題。

六、持續集成部署實戰

后續篇章會分享針對PHP/JAVA/前端以及Android/ios持續集成和部署實戰，敬請關注。

總結

以上只是粗略對持續集成和部署過程中遇到的問題進行了總結，并不完美，但對于初創公司應該有些幫助，歡迎一起學習討論!