多分枝測試需求
隨着業務和需求的增長，需要研發進行並行開發，如何保證功能之間不受影響，防止研發打架。如何保證大家代碼不被覆蓋，如何保證上線的功能就是上線的代碼。這需要從代碼管理方面來進行考慮，當然推行git是基本。
1.功能開發時使用功能分支，拋棄都提交到develop分支的方式，單獨拉取一個分支進行開發，保證開發的時候只涉及當前功能；
2.權限管控：下掉開發master權限，只保留開發權限；
3.上線的時候通過代碼合並的方式將功能代碼提交到master，合並通過cmdb平台自動完成。
會帶來的問題
當開發功能從develop到功能分支，不可避免的會遇到合並代碼時候的沖突問題，這個需要在合並的時候研發進行相應的處理，解決沖突。
多分枝測試的實現
為什么要做多分枝講了，那么如何實現呢？
多分枝不可避免就是服務器上需要跑多套環境，多套不可避免會造成資源沖突，比如端口/pid文件等，還有可能造成管理混亂（多個版本都在跑，回收或手動操作的時候不知道刪哪個）。如何規避這些問題，我們選擇了kubernetes來解決這些問題。
實現思路為：
1.默認的測試環境，代碼全部從develop拉取，也可以查看當前develop分支的代碼是否都正常運行；
2.分支環境，從功能分支進行拉取，非功能分支的都從默認環境獲取；
3.分支環境的代碼和develop的代碼通過對ingress的編排實現，我們選用的時helm的charts進行實現的。
以上基本就能實現資源的發布。
那么資源的刪除呢，也是需要通過helm來實現。在ingress中把功能分支的service更換成默認的service即可。
會帶來的問題
多分枝測試避免了研發之間代碼的相互覆蓋（合並有沖突會提醒，只有解決了沖突之后才能完成合並，在此之前研發能夠相互進行溝通，避免覆蓋的發生），但是任何事情都有利有弊。
下面簡單說說弊端：
1.需要程序進行適配：由於多分枝是通過不同域名進行實現的，需要給程序制定一個規則，讓其訪問對應域名下的程序；
2.需要對dns進行泛解析，如果放到公網會帶來一些安全問題。
edit by cherrydot