互联网开发模式：持续集成

互联网开发模式：持续集成

文章转自韩大的博客https://sanwen8.cn/author/handa1740168.html

持续集成的意义和实践

不管是敏捷开发的快速迭代，还是重构系统，我们都将频繁的编译代码、部署、测试，也就是所谓的集成。如果我们的系统集成效率太低，那么快速的迭代可能变成慢速的迭代，重构系统的频率也会**降低。有一些项目，每一次集成，都要最少经历两三个小时，如果不顺利的话，搞一个通宵都未必能完成。

“发版本”是很多程序员和运维管理人员的常见加班原因。对于这个问题，很多小型公司开始的时候，并没有给与足够的重视，认为这些事情不过是程序员或者运维的本分工作之一，也是最日常的工作。真正得到出问题了，才发现重要性。

在任何一个互联网应用业务中，我们都会需要“发版”：出新功能、修改BUG、启动运营活动、甚至是机房搬迁。所有的这些，如果没有一套合适的工具来保障，每次发版都会是一场噩梦。所以持续集成（CI），很自然的成为互联网企业中最流行的、研究最广泛的技术之一。

所有资产纳入版本管理

持续集成的所有东西，都应该来源于版本管理系统（SVN/Git）。除此之外，软件资产不应该存放在任何其他地方。版本管理系统应该是开发团队的保险箱和金库，除了代码以外，所有的数据文件，配置，脚本，文档，都应该放入这个保险库。由于版本管理系统可以追溯到任何一个是时间点，这可以让故障恢复，问题回溯有良好的支持。

关于源代码使用版本管理系统，已经有很长历史了。但是互联网服务中，除了代码，还有很多其他的资源，比如图片、数据、脚本等等。除了产品项目外，我们的很多额外系统，比如运维工具、产品文档等等，都是需要妥善保管的，这些也都应该存放到版本管理系统中。

一般现在的版本管理系统，都有“分支”的功能，简单来说就是类似于“拷贝”了一份新的资源出来，在这之上的修改，可以由我们选择合并到其他分支或者放弃。所以SVN的常用方案，是启动三个类型的分支：trunk/branch/tag，专门针对“测试”、“开发”、“运营”。如果我们按预定的分支模型来设计版本管理系统的使用，那么我们的持续集成就可以很细致的选择集成哪一个版本的内容。

而在Git里面，每个使用者，都可以拥有自己的资源库，这对于开发测试可以更加的灵活，但是对于使用者的要求更高一些：在不同的资源库合并的过程中，需要更好的版本管理策略。持续集成系统可以自己拥有一个或者多个Git资源库，这样他们可以完全脱离版本管理服务器来独立运行。

自动化部署

我们曾经无数次的登录服务器，无数次的拷贝文件，无数次的修改配置，无数次的导入数据到数据库，无数次的……如果我们对这些重复，而且容易出错的工作熟视无睹，我们将永远的被这些本该机器去做的事情困住。

自动化部署，是整个持续集成工作中最重要的步骤。当我们每次发版都要很仔细的修改很多文件的时候，我们是无法避免在某次倒霉的事故后被挨批的。只有我们能把部署工作，也用我们的开发能力去解决，编写自动部署工具之后，我们才真正的能提升部署这个事情到一个新的台阶——我们终于可不再担心发版。

和自动化测试一样，自动部署脚本，也是把一系列的技术需求，从纸面文档+人手处理，改成用代码实体化，并且可积累改善的方法。自动化部署工具在开源界也非常热门，比如jekins，还有chef等等，都是为了解决部署问题而发明的软件工具。也许对于你来说，自己用bash开发一套脚本才是合乎你的品味，但是不管怎样，一定要有这样的工具。

就算要花费较长的开发时间，调动项目开发的程序员，一起来认真的开发一段时间自动部署功能，都是非常值得的。因为从今以后，你就可以拥有一个自己的部署系统，这个系统不但可以积累你的运营部署经验，还能加入很多错误、故障的自动检查，让你不再需要导出找“永远不出错的”运维人员。

自动化部署系统中，最核心的部分就是配置管理。拥有一个对现有环境资源集中管理的数据仓库是非常重要的。如果每个你的脚本可以识别自己所在的环境，以主动的方式去“申请”自己的配置文件和安装任务，是非常好的一个模式。因为从一个节点主动去分发程序，比不上多个节点向中心集群请求部署任务，来的更容易稳定。因为在节点上的部署代理程序，能更准确的知道自己环境的情况，也可以做本地的测试。

自动化集成测试

前面曾经说过，敏捷开发非常依赖于自动化的单元测试。实际上持续集成，也非常依赖于自动化的集成测试。集成测试可以把自动化部署的结果进行检验，避免手工进行反复验证。

如果只有自动化部署，而没有自动化测试，那么集成工作，其实还是非常浪费人力的。更重要的是，我们在每次“发版本”之后，总会担心新的修改，导致一些旧的功能失效。这种问题实际上是很常见的，如果无法自动化的做这种回归性的测试，那么我们每次发版还是要忍受漫长的测试工作进度。

自动化集成测试也有很多开源的工具可供选择，特别是基于B/S模式开发的WEB程序，但如果是手机APP的项目，或者客户端C/S程序（比如网络游戏），对于这类服务器系统的集成测试，往往需要我们自己根据业务来编写测试程序。

对于服务器系统来说，一般我们针对其通信协议编写测试程序即可，而对于客户端系统，如果是GUI系统的，我们还可以根据GUI的内部调度命令（安卓就有这样的套件）来测试，但如果是类似游戏这类业务，就只能用图形识别技术了。

在持续集成的流程中，集成测试往往是最后一步的检验关口。如果集成测试失败，应该给所有关注集成的人员发送警报（实际上，如果成功也应该报告）。现在企业往往会用邮件、IM、微信、短信或者别的一些东西接收这种消息。