浅谈持续集成

在我们一般的软件开发流程中会出现以下问题：在集成的时候才发现产品无法运行；在不同的分支之间不断合并代码；加班改bug但bug依旧顽固存在；不断手工进行部署、测试、发布……

那么问题来了。持续集成，能解决上面的问题吗？

这是目前咱部门在使用的持续集成Jenkins

持续集成，简称CI，是一种敏捷开发模式。通过持续自动化构建，实时对代码进行编译、测试，来保证产品可以随时发布的状态。这里面有三个有效的因素：可以高效构建的系统，产品有效的实时和定时测试，合理的流程规范。

高效构建系统，首先依托在主干开发基础之上。所谓主干，对位就是分支。主干开发的优点：避免了合并分支的麻烦，分支多了对于管理层面要求就高了；而对于QA来说，我们只需要focus主干这条线就好了。所以一般来说，分支用来发布，主干用来开发。高效构建系统，需要借助工具，如版本管理SVN、代码管理，虚拟机，docker等基础设施，构建系统如Jenkins，服务，邮件通知等。高效构建系统，还需要开展合理的开发任务。这里分四点阐述：1.合理的版本控制。如SVN、GIT等。2.去冗余。3.单一化。（功能测试和系统测试不要放一起）4.任务的定时和实时。如果项目要求的性能要求优先，那就优先进行性能测试；如果是用户体验优先，则优先进行功能测试；具体应该根据开发团队的需求来定。

实现全面有效的测试。有效的测试，首先要符合产品的现状。我们不光是要测试产品的功能，还需要多个维度地考虑其他方面。例如开发的维度，用户的维度，是否满足了用户的需求。其次，要有高效并且稳定的系统。我们所说的自动化测试，不一定就是高效稳定的代名词。case维护版本稳定，可维护，才可以称得上是高效稳定。如果因为版本更改而不停地要去维护case，不停去调试测试环境，反而会让项目delay而达不到高效稳定的效果。第三，缺陷越早发现越好。如果可以在UT阶段发现最好，这样的话成本就越低，收益越高。

合理的流程规范。首先，代码提交的时候要做到流程规范。其次，构建系统执行任务出错时，修复的流程要规范。编译开发规范，先要checkout，确认别人提交的代码对自己没有影响；关注构建任务，有问题及时修复。

最后再强调一下，要做到持续集成，首先一定要有自动化测试；其次是一定要具备高效稳定的特性，快速及时反馈，才能做到敏捷开发。

---

读更多的好书，拍更美的照片，写更酷的代码，遇见更有趣的人，愿望是实现从IT菜鸟到全栈工程师的蜕变。