image.png

分支模型

主干开发模式就是从Master分支拉代码直接改，改完之后提交到Master分支，发布的时候发布Master分支。但是，这是有场景的，如果一个团队同时进行一个项目是可以的，这种情况下提交任何代码都有功能测试和非功能测试的环节保证，发布的时候代码是有保证的。但是，这是比较理想的，一个开发团队实际都是同时进行很多项目，一个项目里涉及很多应用。这个情况下，有可能两个项目同时在改一套代码，Master同时在改、同时在提交。我在做项目A的发布时候，会把没有经过质量保证的项目B的代码也发布了。
主干开发模式是一个项目团队同时只在进行一个项目是可以的，它解决不了并行的问题。
所以就有了Gitflow开发模式，它在Master分支上有一个Development分支，任何变更都要从Development分支上迁代码。这种模式可以比较好地解决项目并行的问题，但带来更大的问题，它分支太多了，是非常复杂的，分支管理成本会非常高。
分支开发模式是我们现在采用的模式，我们从Master分支每次做变更的时候，一个需求拆分多个Feature，从Master分支迁出Feature分支，在Feature分支上做变更，在发布的时候以Master分支为基线，迁出一个release分支，Release发布后，合并回Master分支，这样可以保证始终与线上的版本是同步的。这样的成本会小一点，还能解决项目并行的问题。

代码提交到分支上了，要做一些单元测试和接口测试。我们会用Junit和TestNG分别进行单元测试和接口测试。之后，我们用Maven插件，用来执行Junit或TestNG用例。用JaCoCo分析单元测试和接口测试后的代码覆盖率，之后用Jenkins，自动化测试任务执行，报表生产和输出，与Maven、Junit、Gitlab这些工具结合非常好。
image.png

image.png

非功能性验证是穿插在整个过程中的，比如提交阶段会进行非功能性验证，就是安全扫描，要看看有没有漏洞在里面，检查的漏洞非常多，比如远程代码执行。这个工具叫Cobra，是我们安全团队开发的，现在很多公司也在用这个工具在做这个事情。我们做的时候，中间有一步是安全扫描，这个必须通过的，不通过是无法进行下一步。
image.png

环境配置

image.png

image.png

一开始的时候，我们就一个线下环境、线上环境，中间会做网络隔离。实际情况是什么呢？对开发团队来说不是只有一个项目在并行，是多个项目的，这些项目都有质量保证的需求，这些需求都放在一个机房测试的话会有冲突的。我们会碰到测试的时候应用不行了，这会产生环境的冲突，这怎么解决呢？我们就建设项目环境，每个项目分不同的环境，这只允许核心的项目，一般的项目不会这么做，因为这是有代价的。
我们分了这么多环境，这些环境里只包括本次项目涉及到的变更应用，如果不涉及到变更应用就不会设置这个。我们做了一个改造，在分布式的服务化架构上，我们会优先支持本地调用。比如在项目1里有应用A、应用B、应用C，这些应用是本次项目需要变更的，这时候之间的相互调用都是在本环境内进行闭环的。但是如果是应用E、应用F、应用G，在本次项目中不包含的，这时候就依赖集成测试环境。这既保证了环境的隔离，又保证了环境的建设最小化原则。
多环境下的配置管理，有三种：多配置文件、PlaceHolder和AutoConfig方案。多配置文件就是一个环境建一个配置文件出来。最初的时候，我们是线下环境、预发环境和生产环境，有三个环境的时候，我们用这个方式，但是后来会有项目环境、开发环境，这种方式是搞不定的。AutoConfig方案有点复杂，但是有一些教程可以在网上找到。这个方案可以比较好地管理不同环境之间的配置，阿里在用这个方案，我们现在在调研这个方案。
后面会涉及到多环境发布的问题，这几个环境是我们必须经历的环境，即开发环境、集成环境、预发环境、Beta环境、生产环境。
这是单提机器上线部署的场景分解（见下图），这个单机的。如果靠人工去做，做一两台是可以的，但是几百台是搞不定的，所以我们要把过程串联起来。我们会把单机的动作做成自动化的过程，之后我们把这个过程再应用到线上去。

image.png

发布

这是发布和部署模式（见下图）。主流发布模式有三种：蓝绿部署、金丝雀发布和滚动发布。蓝绿部署在线上有两个环境，发布的时候先发布到绿的环境上，验证没有问题的时候，再切换蓝环境，解释起来挺复杂的，从管理上来说也是挺复杂的，用的时候，我感觉没有这样的场景需要我们这样去做。
image.png
我们做的是金丝雀发布和滚动发布。金丝雀发布就是从线上的环境里挑从两三台机器，先把版本升级发布，这几台机器在线上承载线上真实流量，它有没有问题会暴露出来。Beta发布完了，版本没有问题，就大面积往线上发布，这时候需要考虑一个问题，不可能线下的机器都停掉，会分批去发布。
线上部署案例，我分了8批，每批有8台。我们采取的方式是金丝雀的灰度发布再加滚动发布的分批形式。发布完后，我们会做另外的非功能性验证，验证性能和容量的下降，要看QPS有没有降，或者有没有出现新的错码。