（不）实用的持续交付

本周我参加了一个为期两天的培训课程，内容是关于持续集成、交付和部署方面的实用解决方案。我参加培训是因为我们公司的一项战略目标就是提高产品开发速度。

正如前文所述，在工作流程中实施完善的开发、集成和测试流程，将极大地帮助您交付始终如一的产品，确保产品顺利通过所有质量关卡，并持续带给客户惊喜。如果您想了解更多关于持续交付优势的信息，我强烈建议您阅读@stenpittet撰写的这篇文章。

文章已失效

起初，我心想，建立一套统一的工作流程能有多难？我的工作流程已经优化到极致，只要工具齐全，一天就能解决好几个问题。多亏了我们优秀的导师，我很快就意识到现实并非如此……

因此，在这篇文章中，我将列出一些我在工作中习以为常，但最终却被证明是持续集成和交付中可怕的反模式的方法。当然，需要声明的是，已经有很多文章解释了更多的反模式，所以请记住，这份清单本质上是我个人的经验，并非完整清单。以下所有反模式都反映了我的个人经历。

在持续集成模型中，开发人员应该每天至少一次将他们的代码直接推送到主线（例如，Git 存储库的 master 分支）。

我的做法是，我会让我的功能分支停留数天甚至数周，经常从父分支进行变基，但从不推送回主分支。这是因为在工作中，我们遵循严格的看板工作流程，为了安全和授权，在功能合并到主分支之前，我们需要同行评审和手动测试。

特性分支的一个缺点是它将开发人员与团队其他成员完全隔离开来。尽管我积极地进行变基，但我仍然时不时会遇到棘手的合并冲突。这是为什么呢？

答案很简单：隔离会阻碍沟通。

我倾向于把代码牢牢掌握在自己手中，除非遇到真正的阻碍性问题，否则不会轻易讨论。这实际上会导致两种结果：a)我最终实现了超出必要范围的功能（YAGNI），反而拖慢了进度；或者b)我实现了错误的功能，由于需要重写代码，进一步拖慢了进度。

为了解决这个问题，并让持续集成真正按部就班地进行，我们应该彻底放弃特性分支，但我并不确定我和我的团队近期内是否做好了准备。另一方面，将新功能设计成尽可能小的增量，并将它们从特性分支快速合并到主线或许可行。

相反，我更想通过多做结对编程来提升沟通技巧。最近，我一直在以真正的 DevOps 方式练习，和我们的一位运维同事结对——他负责服务器维护，我负责代码编写。在我看来，我们在这方面做得非常出色。

此外，当我需要代码审查时，我应该大胆地请同事帮忙，而不是让问题一直搁置。我知道，我知道，这很简单，对吧？但对于像我这样的内向者来说，却并非如此。作为开发者，我们应该更加重视开发中的软技能，例如沟通、合作和同理心等等。

对于大多数质量保证专家来说，这大概就像一根生锈的钉子扎进了脚后跟一样难受。想象一下，几个包含 20-30 个新增量的大型用户故事正在并行开发。在所有（痛苦的）合并操作完成后，代码在代码冻结仪式（这本身就是一种反模式）中被合并到主线，然后才开始在发布到生产环境之前进行回归测试。

即使对于专业的测试部门来说，回归测试至少也需要几天时间，而开发人员要么闲着等待测试中可能出现的错误报告，要么转而开发下一个功能，这实际上会导致不同任务之间不必要的上下文切换。就我个人而言，如果几天或几周后有人问起我写的代码，我都很难回忆起来。

显而易见的解决方案是邀请同事在你开发代码的同时进行测试。结对编程是解决此问题的有效方法。事实上，测试专家应该从最早的迭代会议开始就参与到开发迭代中，一直到最后的迭代评审。让他们在迭代的最后阶段才加入，只会损害他们自身和开发人员的利益。

持续集成检查清单要求所有代码在推送到主线之前都必须在本地进行测试。通常情况下，我在本地开发代码时会运行静态代码分析和单元测试，等待它们通过后再创建新的提交。那么，为什么即使所有测试都已通过且测试覆盖率很高，我的某些更改仍然会引入错误和破坏性变更呢？

如果你认真阅读了这篇文章，应该已经注意到我在“反模式#1”部分解释过了。主线（trunk ）中的 bug 和破坏性变更（垃圾代码）会削弱持续集成和交付流程，降低其可靠性，并需要更多的手动测试。此外，你的版本控制历史记录也会因为这些修复提交而变得混乱不堪。

对于经常在单个分支上工作的个人项目，例如，可以轻松配置Travis CI来构建管道的提交阶段，并在打包软件或将其发布到生产环境之前报告可能出现的错误。

对于涉及数十人的开源和封闭式商业项目而言，向持续集成和持续交付最佳实践的转型将更加困难，因为这首先是一个文化问题。我认为任何社区或公司只要真心想要转型，都能实现。无论我未来的职业生涯走向何方，我都致力于尽可能地解决上述反模式问题。

封面图片由 Nhan Ngo 提供，并根据知识共享署名-相同方式共享许可协议授权。