实践持续交付一年后的反思
source link: https://mp.weixin.qq.com/s?__biz=MzU1Njk2NjkxNA%3D%3D&%3Bmid=2247483951&%3Bidx=1&%3Bsn=c97071c0d7dcb54eae2b8311958b9182
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
感谢领导们，让我有机会在团队里实践持续交付。因为在3年前我就已经希望有这样的机会。了解我的人都知道这是肺腑之言，我个人是不会拍马屁的人。
我先申明，我不是那种为了持续交付而持续交付的人，我深刻地知道我实践持续交付的目的。持续交付只是手段。
之前分享过一些持续交付的实践经验。没读过的读者可以在翻下之前的博客。这篇博客主要是反思。
为什么要反思？是因为从上周六到这周四，生产环境出现了三次事故。触目惊心的数字。这还是在我们自动化程度、版本化很高的情况下发生的。
朋友问我：咋最近这么多事故？
这是一个好问题。
我问自己，为什么是最近才发生？想想最近发生的事故，似乎都是必然的。最近不发生，将来也会以某种形式发生。
接着是为什么这么多？这个问题的答案并不重要。我们应该问为什么会发生，为什么离我们高可用的目标那么远？
原因很多。我总结有以下几点：
1. 主干开发后，没有code review，或者code review做得不够好。 2. 采用feature toggle后，只测试了feature toggle开的时候，没有测试feature toggle关的时候。 3. 当实现自动化构建和自动化部署后，要想交付得更快，测试资源将会成为瓶颈。但是我们不能简单的通过加人来解决这个问题。 4. 当采用主干开发的方式，又没有code review时，开发人员变更代码会变得很“随意”。实现feature时，一堆堆的代码的push到主干，等待自动化打包完成，然后部署到开发环境进行联调。到月底，所有的feature再统一的提测。 5. 工程化程度高的同时，人员的能力也要跟上。
以上是这些问题，并不是一个个独立的问题。它们是相互关联相互影响的。不可能采用先解决问题一，再解决问题二，逐步接近法来解决。因为它们也只是表象。需要找到根本问题。
如果硬是要我说根本问题是什么，我觉得是反馈周期太慢了。目前的反馈周期是按月来算的。程序员在月初写的代码，只能在月底才能得到反馈。
反馈包括：
1. 代码质量层面的反馈 2. 测试层面的反馈 3. 业务价值层面的反馈
接下来的问题是，如何验证我的结论是否正确呢？这时，我想起了大野耐一的《现场管理》。只有深入现场，才有可能找到问题的本质。软件工程的现场是什么呢？是一个好问题。将来再写。
小结
虽然，基于一切版本化，一切自动化的原则，技术上实现了自动化构建和自动化部署，但是离真正的业务上的持续交付还很远。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK