pipeline 结构设计

一.pipeline步骤

当团队开始设计第一个pipeline时，该如何下手呢?以下是笔者的设计步骤，仅供参考。

第1步:了解网站的整体架构。这个过程就是了解系统是如何服务用户的。其间，还可以识别出哪些是关键系统。

第2步:找到服务之间、服务与组件之间、组件之间的依赖关系。第3步:找到对外依赖最少的组件，将其构建、打包、制品管理自动化。

第4步:重复第3步，直到所有（不是绝对)的组件都使用制品库管理起来。

第5步:了解当前架构中所有的服务是如何从源码到最终部署上线的。

第6步:找出第一个相对不那么重要的服务，将在第5步中了解到的手动操作自动化。但是，通常不会直接照搬手动操作进行自动化，而是会进行一些改动，让pipeline更符合《持续交付》第5章中所介绍的“部署流水线相关实践”内容。 另外，之所以先从一个不那么重要的服务下手，是因为即使自动化脚本出现错误，也不至于让大家对自动化失去信心。这个过程也是让团队适应自动化的过程。

第7步:重复第6步，直到所有服务的所有阶段都自动化。这一步不是绝对的，也可以先自动化一部分服务，然后开始第8步。

第8步:加入自动化集成测试的阶段。

在现实项目中，远没有这么简单。而且，整个过程并不一定是顺序进行的，而是需要几个来回。 如果当前服务没有日志收集和监控，那么在第3步时就要开始准备了，免得后期返工。在第8步以后就要看团队的具体需求了。

二.案例

假设存在一个X网站，我们需要使用上一节介绍的步骤来设计其pipeline。 通过与X网站的团队进行沟通(通常不止一次沟通)，总结出它的(不是严格意义的）架构

file

A和B都是后端服务，它们共同依赖于common组件。F是一个Node.js服务。LB1和LB2分别负责前端的负载和后端的负载。

现在我们已经完成第1、2步。

第3步，很容易就能找出依赖最少的组件:common。它的pipeline非常简单，只需要编译打包并上传到制品库即可。读者参考第2、3章就可以独立完成。

第4步，省略。

第5步，A服务承载的业务相对不那么重要，我们就从它开始。那么，之前A服务是怎么从源代码到最终部署上线的，笔者了解到×网站的成员都是自己打包自己所负责的服务的，然后把制品以邮件的方式发给运维人员，运维人员再把制品复制到目标服务器，然后逐台机器更新服务。

第6步，开始设计A服务的pipeline。这个过程不是一次就能做到相对完善的，而是需要多次迭代调整才能实现。我们跳过这个演进过程，为A服务设置了以下几个阶段

file