笼统来说，持续集成就是用来消除所有在编译，打包，质检（不仅仅是测试），部署中的手工工作。对于持续集成，你又了解多少，今日极限追问：
① 你的持续集成做了哪些事？
② 持续集成做这些事如何提高软件质量？
③ 你还想在持续集成中增加做哪些事？
持续集成应该是行业里普遍得到认同的实践了。不过每个团队的持续集成做法还是有很大差异。
很多人认为持续集成就是持续编译打包，不就是调一句 “ gradlew clean build ” ，“ Absolutely no effort ” 吗？
其实对于做哪些动作，我也持怀疑态度，希望多听取各位大佬的意见。
我自己做了这些动作：编译，打包，单元测试，前端测试，开发，测试，生产环境的远程部署。
不过不同公司动作不同，也可能有下面两种方式：
① 持续构建、静态代码检查、持续打包、持续部署测试环境、持续运行自动化集成测试脚本；
② 使用aws的code build, code pipeline, code commit 构建自己的持续集成流水线，成熟后将产品打包，开放给公司内其他开发团队。
持续集成能让我们快速发现错误，同时防止分支大幅度偏离主干。
持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。
它的核心措施是，代码集成到主干之前，必须通过自动化测试。
只要有一个测试用例失败，就不能集成。
在持续集成做这些事的过程中，又如何提高软件质量呢？
第一，需要消除手工工作，提升效率，避免人工操作的失误；
第二，设立自动化机制，强制在代码签入时持行集成，测试与发布；
第三，通过对失败编译过程的分析，找到事故多发点；
主要需要通过自动化的手段来快速反馈，有问题尽早解决。
高频的自动化的集成，部署代码，几乎是零宕机时间，可以缩短发布周期，有了重构基础，代码也进入了良性循环。
除了正在进行的事情中， 还想在持续集成中增加做哪些事？
我是这样想的，从思想和行为上进行持续集成，更频繁的提交代码，更频繁的集成和沟通；同时并发任务执行，复杂流水线可视化；包括代码静态扫描，发布数据归类生成发布和版本的中央报表数据等。
如果你有不同想法，欢迎在评论区留言。
从系统架构本身的可以测试思考和入手，事半功N倍。系统架构本地对测试的友好性不够，才是导致测试(方式)出现的根源。
拿 Bug 当 Feature，”本地” => “本身”，拿 Bug 当 Feature，也是jira里面推崇的使用方式。
【问——答】
Q：系统架构对测试友好性体现在哪里呢？为什么用EventSourcing就友好了？
A：事件溯源，可追溯到时间点，还原整个事件。
【问——答】
Q：今天看到有人在群里提到：集成了 “ sonar ” 单元测试和集成测试，可能包括：线上tcp dump流量，线下回放，在保证基本功能没有被破坏的情况下，前置应该如何去做？
A：选择 “ log replay ” ，这个类似于全链路mock，需要准备好前置的状态，比如存储，缓存。我能想到的可能是，dump n 日 流量， n-1 日零点的全量存储，然后重放。
【问——答】
Q：集成测试目标是什么？测试单个服务吗？
A：集成在我们团队是指负责的所有feature主线剧情无障碍，主要的流程都能通，不以服务为单位。
【问——答】
Q：在做cicd的时候，是一条branch还是多条？
A：一条branch就对应一条流水线。
以上内容整合自【极限编程中国 | 实践者】 微信群12月4日讨论，内容贡献者有： 
若有收获，就点个赞吧
0 人点赞
