最近在看到ThoughtWorks的一篇技术文章提到“几项与持续集成相关的反模式”, 结合自己的实践体会特别有深切体会，所以记录下来
持续集成的反模式
最需要被点名批评的现象莫过于“持续集成剧场”了：
很多开发者只是简单的搭建了持续集成服务器就以为在做“持续集成”，但他们实际上会遗失持续集成的关键优点而导致失败。常见的失败模式包括：虽然在一个共享的主分支上运行持续集成，但是代码提交不频繁，所以集成并没有真正的“持续”。以及在一个测试覆盖率不足，甚至是长期状态为红的情况下进行构建；或者在功能分支上运行持续集成，这会导致持续隔离。
简而言之，这些团队并没有真正体会到持续集成的好处，而是为了完成上级的任务而演一场“我们在持续集成”的戏——这也正是这个反模式的名字由来。过去十年中，我们在众多刚开始实施持续集成的企业见过这一幕。领导认识到持续集成的好处，但是推行成了个大问题：推轻了，下面团队不愿动，技术问题解决不了；推重了，下面团队来个上有政策下有对策，领导想看什么就给你演什么——持续集成剧场就此落成。比如说你见过一个表面看起来一直是绿色但是背后连编译都不敢跑的持续集成吗？ 我见过。真是一场好戏。
为了解决持续集成演戏的问题，一些规模较大的企业开始建设持续集成中心。想法很符合直觉：既然团队自己做持续集成有技术困难、还有可能变成演戏，那么我就组建一支团队专门帮他们一个个把持续集成跑通、帮他们管理持续集成服务器，持续集成的运行和统计数据都在这个中央团队手里，下面的团队总没办法演戏了吧？于是，他们又遭遇了第二个持续集成反模式：“所有团队共用一个持续集成实例”。
那些必须使用中心化持续集成服务器的交付团队，常常依赖中心的团队去完成小的配置任务，或者在共享的基础设置和工具中排查问题，这给他们在进度上带来长时间的滞后。
这次是康威定律带来的困难：如果每个团队使用的技术栈配置不同、技术栈配置和管理的职责仍然在每个团队中，那么技术栈演进与持续集成的演进就难免出现节拍不一致。于是管理着持续集成中心的中央团队开始疲于奔命，帮一个个项目团队修持续集成，而项目团队还感到没有得到足够的支持。
第三个反模式是“企业级集成测试环境”，这也是很多组织建设持续集成中心的初衷之一：由于能执行完整端到端测试的环境稀缺，各个团队的集成测试无论如何也必须在一个瓶颈处统一调度，所以中心化管理持续集成也就顺理成章。然而，
这些企业集成测试环境通常称为 SIT 或预生产环境）是当下持续交付常见的瓶颈。环境本身很脆弱而且维护成本很高，而这些环境通常存在一些需要由单独的环境管理团队手动配置的组件。在预生产环境的测试给出的反馈慢且不可靠，而且会重复测试那些在隔离的组件上已经测过的功能。
我的体会
对于上面第一个情景，很多时候我们以为有了工具就是持续集成，但是往往那些持续集成并不是那么完美，至少在我看到都是“hardcode”, 可移植性差，不能复用，维护成本高，下一个接手的人需要花时间了解上一个人做的“CI/CD”；因为在一些团队里，并不是很重视这个，认为CI/CD仅仅是个辅助的东西，当然这样跟国内项目的开发周期有关，有时候项目很小，客户催的很急，哪有时间去优化那么好，能用起来再说。当下一个项目来的时候，同样的技术栈的项目还要重新来过一次。
毕竟对于开发团队来说，CI/CD是另外一个领域的东西，虽然入门简单（按照网上的教程一个很简单demo就搞定了），但是里面的思想和业务场景需要一个个业务场景的积累，如何优化，如何标准化复用，这并不是简单的事情，其实这也是DevOps要解决的一个个痛点。
那么我们建个专业的团队做这个事情吧，就是第二个场景提到的事情，其实这也是我目前正在进行中的场景，但是随着业务开展，严格意义上还没有人用，我们就发现你搞出来了，不见得有人会用，不同的业务，不同的技术栈，你需要和Dev团队密切沟通，需要DevOps团队有广阔的技术视野，如果服务众多个不同业务团队，你可能会发现自己被动的成为了“那个业务项目的一员”；另外沟通的成本其实也不低，想法是好的有个专业的团队，但是落地不是那么容易，这不是一个人，一个团队能解决的问题。
那么如何解决这个困境？ 我认为需要企业自上而下，推广这种文化，可以从一个项目开始做推广，小步快跑，将“标准化规则”慢慢建立起来，比如分支的管理，依赖管理，CI/CD与不同技术栈的集成标准化，环境问题（内部环境,线上环境），最后衍生出来一个标准化的CI/CD平台。最后的场景是，Dev团队只关注于业务，他们只需要基于一个CI/CD模板，填写必要的环境参数等，剩下的事情不需要他们管，对于他们是透明的，他们只需要产出是什么，比如仓库，邮件通知等等。
所有的”快速复用，持续交付”都是基于大家形成的一个标准流程，没有标准，就没有”复用”，就没有快速的迭代，最后还是”半人工”的低效工作。
