Pipeline是软件交付的命脉，为了保证每一个功能需求可以长期稳定、源源不断地通过，在优化过程中我们引入了关于Pipeline性能的监控机制，我们基于ThoughtWorks的开源产品GoCD 提供的API开发了一个监控工具，每一次构建之后可以自动统计该次构建的时间和成功率，如果超过这两个指标超过了阈值，则让该次构建失败，提醒代码提交者检查是否引入了影响Pipeline性能的变更，避免性能的进一步恶化。考虑到网络和机器性能的问题，在设置实际的阈值的时候可以稍大于期望值。

我们还构建了基于邮件通知的预警机制，每个工作日的下午发送出包数量通知，提醒团队解决影响出包的问题，同时我们把Pipeline的性能可视化并纳入每周的周报中。

　　写在最后

优化Pipeline除了Pipeline结构、测试策略和监控可视化手段之外，还需要关注软件架构和团队组织结构，下面是我们项目架构的局部依赖图：

核心的微服务OrderAPI依赖复杂，和RatingSrv之间甚至出现了双向依赖，领域上下文（Bounded Context）的不合理切分使得业务逻辑散落在不同的服务之间，不管我们增加集成测试还是契约测试，这种依赖关系也同样会体现在Pipeline之间的依赖关系上，增加Pipeline的复杂度。

在ThoughtWorks技术雷达上A single CI instance for all teams目前处于Hold状态，在一个组织中多个团队共享一个臃肿的CI会导致很多的问题，比如上文中提到的构建队列过长，构建时间长等，一旦这个共享的Pipeline出现问题会造成多个团队工作 的中断。技术雷达建议在具有多团队的组织中由各个团队分布式地管理自己独立的CI。这种分布式的CI同样也依赖于整洁的软件架构和与之相契合的团队组织形式。

在项目的DevOps小组解散之后，我们成立的项目内部的DevOps Community，以保证产品交付为目标，同时肩负着项目提高内部DevOps技能的职责。项目内部的成员有跨多个开发团队的不同角色组成，直播，DevOps community产生的相关Task，最后都会分配到不同的开发团队中。DevOps是一种文化而不应该是一个单独的小组，DevOps主旨在于构建整个团队中的责任共享的文化，改进现有的流水线是每一个开发团队都需要具有的技能之一。