git 和 docker 黃金搭檔

首先介紹我們公司和團隊的情況，kingdee 云之家，主要是做企業社交，其中包括 im，微博等，我們的服務主要包括免費的公有云服務，和各個企業的私有云部署，其中萬科，海爾都是我們的客戶。

再看看我們現在的系統和技術棧的情況：

1. 現在的系統中存在 449 項目
2. 開發使用的技術棧有 java(標準容器項目使用 jetty，play 項目)，nodejs，php，百花齊放。
3. 兩條產品線，將近 100 來號開發人員
4. 我們還有很多企業的私有云部署需求

在如此多項目和人員情況下，產品迭代又非常快，這就要求我們能夠支持開發部門。下面我們說說在如此情況下我們遇到的一些實際問題：

開發工程師說：

• 誰又收走了我 MQ 中的數據
• 誰改動了 API 的代碼，導致我的程序代碼報錯
• 本地程序修改部署，其中出現個以上問題，一上午就過去了
• 。。。

測試工程師說：

• dev 環境老是在部署，導致沒有辦法測試
• 測試一個 bug 時，別人提交了代碼，導致另外的 bug

產品經理說：

• realease 分支的代碼合并導致了將其他沒有完成的功能發版正式環境
• 由于相互依賴導致自己開發好的功能必須等其他人
• 以上問題導致功能進度不能如期

上面的各個角色都有自己的痛點，我們來分析下上面的情況造成的原因，其實大部分的情況是由于各個環境的隔離不夠造成的，知道原因后我們來看看我們的應對策略：

• 劃分好各個角色的邊界
• 采用 Pull-Request 的做法

那我們先來看看我們的基礎設施和角色：

1. 開發工程師
2. 測試工程師
3. 產品
4. 其他

然后我們再來劃分下各個角色的邊界：

1. 開發工程師應該只用關注 git 上的代碼和 jira 上的 bug 和 newfeature
2. 測試工程師只關注 jira 的 bug 和 newfeature 的測試
3. 產品和其他人只關注 jira 提交的 bug 和 nrefeature 的解決

角色的劃分，和我們的基礎設施看完了，來看看現在 git 上的分支視圖，假設我們現在有兩個主分支

1. master： 代表的開發部分穩定分支
2. release: 代表線上穩定分支

我們的角色邊界和基本涉及到的設施夠看完了，現在看看開發工程師如何工作的：

• 第一步：根據 jira 上 bug 或者 new feature 從 master 上 fork 一個對應的分支 iss001
• 第二步：開發工程師，在 fork 的分支上提交代碼，git hook 會通知 jenkins build 相應的 image
• 第三步：jenkins 會把相應的 image 部署到服務器集群中，開發者就可以通過
  iss001.kingdee這個域名訪問剛剛對應分支的服務了，iss001 對應的 fork 分支的名稱，我們要求唯一

我們來看看測試工程師是如何工作的：

• 第一步：測試工程師經過驗證后，這個 bug 或者 new feature 的功能完成，會把代碼 merge 進入
  master分支，在這分支上做性能測試和冒煙測試
• 第二步：經過性能測試和冒煙測試后，就可以通過 cherry pick 挑選要發布的功能
• 第三步：經過發版后的，測試工程師關閉 jira，我們通過 web hook 通知后端 k8s 集群刪除對應分支分配的資源

這就完成了整個系統的流程，這其中每一個分支都可以分配資源部署環境測試和開發。

• Q1:開發每提交一個bugfix，都會觸發jinkens去構建鏡像，那么多的開發者，豈不是要構建很多鏡像？
• A：沒有錯，我們是每次都觸發構建 image，由于 image
  是分層的，底層已經存在的父對象，是不用存儲，只存儲變化的部分所以再用的磁盤空間很低，在系統開始初，我做過統計， 1000 個 image 也不到 9G，這其中還有很多基礎鏡像。
• Q2：想問一個集群相關的，像docker部署這部是直接調用docker部署容器，還是通過ansible或其他工具
• A：有了 k8s 管理集群后，發布的工作就比較簡單了，用不上 ansible。但是 ansible 還是有它的用處的，比如清理集群中過時的
  image，和已經退出的 container等。
• Q3 你好，以前也做過類似的服務“第三步：jenkins 會把相應的 image 部署到服務器集群中，開發者就可以通過 iss001.kingdee這個域名訪問剛剛對應分支的服務了”，單獨一個分支解決了對應的bug，但實際生產中非常容易修改一個bug引起其他的 bug，你們是怎么去把控整體的穩定性？如何提高這種單個bug分支單個測試環境的意義？
• A: 這個 pull-request 的工作方式是應對功能開發的，如像長期開發某個 new feature，你剛剛說的一個 bug 產生另外一個 bug，我們的做法是有回歸測試，我們有一個 smoke 分支，持續不斷的對其做功能回歸測試，只有通過的才能 cherry pick 到 release 上
• Q4：測試環境依賴的redis/MQ之類的外部服務如何做的隔離?每次測試單獨拉起來一套外部依賴的服務嗎？
• A：我們通過多個手段來實現
  共享數據：master，smoke，release 分支測試都有自己獨立的中間件
  要是不用訪問共享的數據，可以部署如 MQ image
  代碼層面的，如 MQ key 的名稱加上機器的 IP
  Q5:有沒有用到mesos?是否容易遇到問題？這方面的文檔好像并不多
  A：mesos 是個二級調度，適用于像存在多套集群的情況，來均衡資源，如：部署了 hadoop 和 storm ，一般會使用 storm 來處理實時的請求，hadoop 做離線工作。晚上和白天就存在一種可能就是 hadoop 閑置，但是 storm 可能很忙，這時 mesos 這樣的二級調度就可以平衡資源，節約成本，我們暫時沒有這樣的需求。至于文檔方面我也沒有深入研究，建議看官方文檔。