Abraham Marin Perez是一位独立的Java开发者以及演讲家。他在旧金山举行的2016年JavaOne大会上发表了讲话，内容涉及如何保持持续集成和持续交付（CI/CD），以及尽可能实现流水化。

根据你的经验，公司对自己的CI/CD流水线失去控制是不是很常见？有没有办法从一开始就设立好这条流水线来避免问题发生？

Abraham Marin Perez：在某种程度上来说，是的。他们不会称之为“失去控制”，不过我认为，尽管有一些真正富有创新精神的公司拥有一些非常复杂的CI/CD流水线，大多数公司仍然还处在努力实现完全功能性自动化生成的阶段。我见过一些地方制作可部署软件包甚至还没有可再生成的手段，一切都是靠手册，需要把一个个独立的建构块拼凑起来……你可以想象所需的试错数量。对于这些公司来说，仅仅是在不需要关心生成需要花多长时间的情况下实现自动化就已经是巨大胜利。

实现快速生成的问题在于这属于一种相对比较新的做法，而且我们还没有找到一种标准化或者规范化的流程来处理。仔细看看不同地方、不同CI/CD流水线时，你会意识到一切都是相当定制化的。不过，还有就是如果这种办法可行的话，我并不认为现在大家普遍担心这个问题，首要事情是确保你能自动化生成，然后才会考虑让这个过程加快的事情。

你的流水线并没有期望的那么快。你能不能大概介绍一下诊断流程？

Perez：诊断过程实际上跟任何其他表现相关任务都相当类似，要做的第一件事情是建立可靠手段来衡量你的CI/CD流水线，这样你就可以讨论具体数字而不仅仅是印象。大家抱怨往往是因为他们感觉生成很慢，但实际上却没有衡量具体的数据。衡量本身本来就是一项任务，因为一次生成往往需要不同的时间，取决于实际进行了哪些变更，所以必须关注平均时间、最大时间这些数据。

一旦团队对生成需要多久有了可靠评估之后，下一步就是建立阈值：生成应该花多久时间？这里仍然有许多变量会影响到决定；也许你希望设定一个最大的生成时间，以便能足够快地对关键bug做出响应，或者也许你只是担心平均生成时间，避免开发者等得心烦。做出决定可能会比较棘手，但一旦确定下来之后，你只需要定期将实际生成的时间跟阈值进行比较：如果实际时间低于阈值，很好；如果超过，你的生成就太慢了，需要采取行动。

另一方面，采取行动也跟其他表现相关的任务类似。如果你已经下结论说自己的生成太慢，那么显然你就得在某方面做出改变才能让它更快。但从哪儿开始呢？这里你就需要对流水线进行更细致的分析，看看每一个独立步骤的时间都花在了什么地方。通过这样你也许可以找出一些瓶颈，或者至少找到什么部分耗时更多。对这些地方进行修改的话就能得到最好的结果。

一旦你已经决定在什么地方采取行动，那就进入到以下改进循环中：进行修改，重新衡量表现，直到对结果感到满意。

这一切的挑战性表现在什么地方？是什么导致大多数公司跌跌撞撞呢？

Perez：我觉得主要问题是，尽管大家都很理解衡量——改变——评估的一般原则，但却还没有把这个原则应用到CI/CD流水线这一领域，这意味着他们实际上还不知道如何进行衡量。

为了让CI/CD流水线运作顺畅，测试扮演的是什么角色？

Perez：这实际上是一个非常有趣的问题。我近年来注意到了一件事情，就是团队内部的角色越来越专业化：有测试员，显然他的角色就只关注测试；然后，还有开发者，他只关心代码；还有业务分析师，UX（用户体验）设计师等等。有时候开发者还会进一步拆分为子角色，比如后端开发者和前端开发者，每个都有自己的知识领域。这类多学科团队是非常有利的，尽管他们还有一个重要的缺点：由于每个人都太过专注于特定的职责范围，一旦新的挑战出现时，就不清楚该由谁来处理了……

在这类团队内部，测试员的角色改变了很多。在一些团队里面，测试员关心的是整个用户体验，而在一些团队，他们编写了主要的端到端的自动化测试，他们需要跟开发者保持同步，确保其与开发者的单元和组件测试端到端的平衡，因为重复发生得很频繁，实际上测试是可以进行合并去重的。类似地，我认为测试员的角色可以扩张到跟DevOps工程师协调一起监督生成流水线，去理解测试时如何影响整体生成性能的，然后试着在需要时找出提高效率的地方。

老实说我认为测试员的角色有些被高估了，测试员应该逐步集成到团队的其他职责里面。测试员的工作相对于团队其他人来说太过孤立了，他们只是在认为自己发现了bug时才跟别人沟通。实际上，我认为其他团队成员应该在测试过程中一起协作来确保该活动更好地集成到一起。