持续集成总结 第1篇

在软件工程中,持续集成是指软件开发流程中一系列的最佳实践,近几年已被广发应用到实际项目开发中。极限编程中一项建议实践便是持续集成，它提供了及时发现问题、追踪问题、修复问题的机制，替代了传统的在所有代码编写完毕后才提交QA部门进行测试的方法。持续集成对单元测试较为依赖，测试覆盖率越高，单元测试越准确，越能体现持续集成的效果。持续集成主要在以下方面提供好处:

1、持续自动化测试（持续集成可通过时间间隔触发，或其他方式触发）

2、跟踪工程健康状况

3、强制性单元测试用例，验收测试用例等

4、静态代码检测，生成测试报告

持续集成总结 第2篇

这是一个持续集成的流程，但是运行起来更加的复杂。

首先，项目开发的流程使用的是Agile，用常见的Scrum为例子。

每天早上第一件事情，就是开站会standup meeting，为什么要站着呢？因为时间不能太长，微服务的一个模块，大概需要5-9人的团队规模，如果团队规模太大了，说明服务应该进行拆分了，这个团队规模，是能够保证比较短的时间之内过完昨天的状态的。

一定要大家一起开，而不要线下去更新Jira，虽然看起来一样，但是执行起来完全不一样。只有大家一起开，一起看燃尽图，一起说我昨天做了什么，今天打算做什么，有什么阻碍，才能够让大家都了解情况，不要期望大家会去看别人的Jira，经验告诉你，不会的。

而且这个站会对于开发是比较大的压力，例如你的一个功能block了依赖方的开发，在会议上会暴露出来，大家都知道这件事情了，一天block，两天block，第三天你都不好意思去说了，这会强迫你将大任务，比如原来写1周干一件什么事情，写成小时级别，这样每天你都有的说，昨天完成了一个task，而不是周只在那里说干同样一件事情，而且一旦有了block，team lead会知道这件事情，会帮你赶紧解决这个事情，推进整个项目的进展。让一个技术人员在团队面前承认这件事情我尝试了几天，的确搞不定了，也是一种压力。

站会中的内容其实在前一天晚上就要开始准备了。

持续集成要求每天都提交代码，这样才能降低代码集成的风险，不能埋头写一周一起提交，这样往往集成不成功。怎么样才能鼓励每天都提交代码呢？一个就是第二天的站会，你这个功能代码提交了，单元测试通过了，第二天才能说做完了，否则不算，这就逼得你，将大任务拆成小任务，每天都多次提交。

而且Git的提交方式，是后提交者有责任去merge，保证代码的编译通过和测试通过，你会发现，如果你不及时提交，等你改了一大片代码，别人都提交完了，这一大片的冲突都是你来merge，测试用例不通过的你来fix，所以逼的你有一个小的功能的改动，就尽早提交，pull一下发现没有人提交，赶紧提交。

提交不是马上进入主库，而是需要代码审核，这是把控代码质量的重要的环节。

所以建议将复杂的规范通过项目组内部的讨论，简化为简单的10几条军规，深入人心，大家都容易记住，并且容器执行。

代码审核往往需要注意下面的几方面：

当然还有一些不容易一眼看出来的，可以通过一段时间通过统一的代码review，来修改这些问题：

代码审核完毕之后提交上去之后，一个是要通过静态代码审查，可以发现一些可能带来代码风险的问题，例如异常过于宽泛等。

在就是要通过单元测试。我们应该要求每个类都要有单元测试，并且单元测试覆盖率要达到一定的指标。单元测试要有带Mock的模块内的集成测试。

在编译过程中会触发单元测试，单元测试不通过，已经代码覆盖率，都会统计后发邮件，抄送所有的人，这对于研发来讲又是一个压力。

当有一天你的提交break掉了测试，或者代码覆盖率很低，则就像通报批评一样，你需要赶紧去修改。

单元测试完毕之后，就会上传成果物，或者是war或者是jar，一般会用nexus，因为有版本号，有md5，可以保证安装在环境中的就是某个版本的某个包，我们还遇到过有使用FTP的，这样一个是很难保证版本号的维护，升级和回滚比较难弄，另一个是没有md5，很可能包不完整都有可能的，而且一旦发生，很难发现。

如果使用了容器，则还需要编译Dockerfile，使用Docker镜像作为交付，能够实现更好的环境一致性，保证原子的升级和回滚。

每天下班前，当天的代码需要提交到库中去，晚上会做一次统一的环境部署和集成测试。

每天晚上凌晨，会有自动化的脚本将Docker镜像通过编排部署一个完整的环境，然后跑集成测试用例，集成测试用例应该是基于API的，很多的公司是基于UI的，这样由于UI变化太快，还有UI不能覆盖所有的场景，所以还是建议UI和API分离，通过API进行集成测试，有了每天的测试，才能保证每天晚上的版本都是可以交付的版本，也保证我们微服务拆分的时候，尽管改了很多，不会因为新的修改，破坏掉原来能够通过的测试用例，保证不会有了新的，坏了旧的。

这个集成测试或者叫回归测试每天晚上都做，都是在一个全新的环境中，这就是持续部署和持续交付。

如果某一天测试不通过，则会发出邮件来，是因为当天谁的哪个提交，导致测试不通过，抄送所有人，这是另一个压力。

所以第二天的站会上，昨天你完成了哪些功能，是否提交了，是否完成了单元测试，是否通过了集成测试，就都知道了，你需要给大家一个解释，然后进入到新一天的开发。

到了两周，一个周期完毕，可以上线到生产环境了，可以通知有权限的运维进行操作，但是也是通过自动化的脚本进行部署的。

这就是整个过程，层层保证质量，从中可以看到，敏捷开发，持续集成，持续交付，持续部署，DevOps是互相联系的，少了任何一个，整个流程都玩不转。

持续集成总结 第3篇

代码结构往往包括：

如果使用Dubbo RPC，则API接口往往在一个单独的jar里面，被服务端和客户端共同依赖，但是使用了springcloud的restful方式就不用了，只要在各自的代码里面定义就可以了，会变成json的方式传递，这样的好处是当jar有多个版本依赖，需要升级的时候，关系非常复杂，难以维护，而json的方式比较好的解决了这个问题。

这个模块提供了哪些接口，只要到API接口这个package下面找就可以了。因为无论是Dubbo还是springcloud，接口的调用都会重试，因而接口需要实现幂等。

访问外部服务的包，这将所有对外的访问独立出来，好处一是可以抽象出来，在服务拆分的时候，可能会用到，例如原来支付的逻辑在下单的模块中，要讲支付独立出来，则会有一个抽象层，涉及到老的支付方式，还是调用本模块中的逻辑，涉及到新接入的支付方式使用远程调用，有了这一层方便的多。好处二是可以实现熔断，当被调用的服务不正常的时候，在这里可以返回托底数据。好处三是可以实现Mock，这样对于单元测试来讲非常好，不用依赖于其他服务，就可以自己进行测试。

DTO和访问数据库的包，看到了这些数据结构，会帮助程序员快速掌握代码逻辑，不知道大家有没有这个体验，你去看一个开源软件的代码，首先要看的是他的数据结构，数据结构和关系看懂了，代码逻辑就比较容易懂了，如果数据结构没看懂，则光看逻辑，就容易云里雾里的。

还有就是核心的代码逻辑和对接口的实现。在这里面是软件代码设计的内功所在，但是却不是流程能够控制的。

持续集成总结 第4篇

代码可以很好的版本化，应用也可以用镜像进行原子化的升级和回滚。

唯一比较难做到的就是数据库如何版本化管理。

有一个开源工具 flyway 可以比较好的做这件事情。

在代码中，flyway需要有以下的结构：

在数据库中，flyway会自动增加SCHEME_VERSION表。

当服务启动的时候，java类的migration方法会被调用，它会按照指定路径中sql语句的版本号进行排序并且按照这个排序去执行，当每一个sql文件被执行后，元数据的表就会按照格式进行更新。

当服务重启的时候，Flyway 再次扫描sql的时候，它就会检查元数据表中迁移版本，如果要执行的迁移脚本的版本小于或者等于当前版本，Flyway将会忽略，不再重复执行。

但是flyway从来不解决数据库升级和回滚的代码兼容性问题。

太多的人问这个问题了，代码可以灰度发布，数据库咋灰度？代码升级了，发现不对可以回滚，数据库咋回滚。

如果可以停服的话，自然是使用数据库快照备份的方式进行回滚了。

如果不可以停服，没办法，只有在代码层面做兼容性。每次涉及数据库升级的都是大事情，代码当然应该有个开关，保证随时可以切回原来的逻辑。

延伸阅读：