实践持续交付一年后的反思

感谢领导们，让我有机会在团队里实践持续交付。因为在3年前我就已经希望有这样的机会。了解我的人都知道这是肺腑之言，我个人是不会拍马屁的人。

我先申明，我不是那种为了持续交付而持续交付的人，我深刻地知道我实践持续交付的目的。持续交付只是手段。

之前分享过一些持续交付的实践经验。没读过的读者可以在翻下之前的博客。这篇博客主要是反思。

为什么要反思？是因为从上周六到这周四，生产环境出现了三次事故。触目惊心的数字。这还是在我们自动化程度、版本化很高的情况下发生的。

朋友问我：咋最近这么多事故？

这是一个好问题。

我问自己，为什么是最近才发生？想想最近发生的事故，似乎都是必然的。最近不发生，将来也会以某种形式发生。

接着是为什么这么多？这个问题的答案并不重要。我们应该问为什么会发生，为什么离我们高可用的目标那么远？

原因很多。我总结有以下几点：

1. 主干开发后，没有code review，或者code review做得不够好。 2. 采用feature toggle后，只测试了feature toggle开的时候，没有测试feature toggle关的时候。 3. 当实现自动化构建和自动化部署后，要想交付得更快，测试资源将会成为瓶颈。但是我们不能简单的通过加人来解决这个问题。 4. 当采用主干开发的方式，又没有code review时，开发人员变更代码会变得很“随意”。实现feature时，一堆堆的代码的push到主干，等待自动化打包完成，然后部署到开发环境进行联调。到月底，所有的feature再统一的提测。 5. 工程化程度高的同时，人员的能力也要跟上。

以上是这些问题，并不是一个个独立的问题。它们是相互关联相互影响的。不可能采用先解决问题一，再解决问题二，逐步接近法来解决。因为它们也只是表象。需要找到根本问题。

如果硬是要我说根本问题是什么，我觉得是反馈周期太慢了。目前的反馈周期是按月来算的。程序员在月初写的代码，只能在月底才能得到反馈。

反馈包括：

1. 代码质量层面的反馈 2. 测试层面的反馈 3. 业务价值层面的反馈

接下来的问题是，如何验证我的结论是否正确呢？这时，我想起了大野耐一的《现场管理》。只有深入现场，才有可能找到问题的本质。软件工程的现场是什么呢？是一个好问题。将来再写。

小结

虽然，基于一切版本化，一切自动化的原则，技术上实现了自动化构建和自动化部署，但是离真正的业务上的持续交付还很远。