一位同学的疑问

有一位同学问我：

你们一个流水线从编译到部署成功需要多少分钟啊。我们快的2分钟，Java 普遍10分钟，开发同学总是觉得慢，我不知道业界是什么水平。

我的回答是： 没有行业标准的，有些项目10万行代码，有些100万行代码，没法比。

后来，我又问他：你们的流水线都包括了哪些阶段？

“编译，带数据库的测序，sonar，docker build，ansible deploy，mvn release”，他回答。

后来的沟通中，我得知，他们流水线时间长发生在两个阶段：带数据库的测试和下载依赖。

下载依赖慢是因为他们每次构建都重新下载依赖，这样做又是因为总是遇到缓存问题，所以，干脆就每次重新下载了。

带数据库的测试通常会慢，因为要启动应用，然后操作数据库，这个数据不确定他是类似 MySQL 这样的真实数据库，还是使用 H2 这样的内存数据库。

出乎我意料的是，他们的 SonarQube 扫描倒是很快。

所以，他们的优化点就是那两个慢的阶段。具体解决办法还要看具体情况，比如带数据库的测试是不是可以通过并行解决、构建时依赖缓存遇到的问题是不是可以通修改构建工具配置来解决。

写到这里，我想表达的是，优化流水线的速度的思路，差不多就是这样：先找到最慢的阶段，然后根据具体情况来优化。

从 DevOps 平台设计角度解决

那么，作为 DevOps 平台，我们能通过什么办法帮助用户提高流水线的速度呢？

笔者认为，只要将流水线中的每个阶段中的每个步骤的耗时都记录下来，然后显示给用户，用户自然会注意到每次流水线的执行速度差异。当然，管理层也可以对这部分内容进行考核。

同时，要将耗时进行分类，一类是用户步骤的耗时，比如执行mvn package，执行单元测试等，一类是 DevOps 平台本身的耗时，比如初始化构建环境耗时，上传制品耗时等。

为什么要进行这样的分类？是因为 DevOps 平台使用过程中，用户遇到问题，往往是区分不了，是平台的问题，还是自己的问题。这时，我们将平台的信息显示给用户，用户就可以自行判断，自行处理了。这会大大节约平台维护者的时间。而且，平台维护者也可以根据平台运行耗时统计来对平台进行有依有据的优化。这是一箭双雕。

我把这个功能叫做：流水线耗时统计。

那么这个功能，到底应该如何实现？不同的平台有不同的实现，比如基于 Jenkins 的话，在每个步骤后加上一个回调请求就可以了；基于 GitLab 的话，就不了解了。 图来自：https://wiki.jenkins.io/display/JENKINS/Pipeline+Stage+View+Plugin

后记

流水线的速度是一个很重要的指标，它直接显示了一个软件开发团队在工程方面的效率（正确性问题是另一个问题）。而流水线耗时统计功能可以有效地帮助用户提高自己的流水线速度。

Last modified on 2019-11-21