什么是爹式开发？

这几天跟Simore在车上聊研发云和 持续交付 ，聊来聊去就聊出了一个新概念：开发即交付——Development As Delivery，缩写DAD，也就是“爹式开发”。

免责声明：爹式开发绝大部分理念和实践是基于持续交付的。我们发明这个概念主要是为了搞笑。

在持续集成的场景下，每当程序员提交代码，就会触发一次完整的构建（包括编译、静态检查、部署、自动测试等），确保软件系统可用并且符合质量要求。但持续集成之后的软件往往仍然没有针对真实环境进行验证，没有考虑投入真实环境使用的各种问题，因此“符合质量要求”与“达到可发布水平”之间还有明显的距离，我们称之为 软件交付的最后一英里 。

为了解决这最后一英里的问题，我们有了持续交付。持续交付的核心是 构建流水线 ：流水线越靠后的阶段，验证越接近真实环境。当一个发布候选版本最终通过正规的发布过程被部署在非常类似生产环境的UAT或者staging环境上然后执行了大量的自动化功能测试，我们就可以说：这个发布候选版本已经为交付做好了准备。

然而，问题是，我们为什么需要等到提交代码之后才做这一切？为什么不在提交代码之前就确认我刚编写的代码已经达到了交付要求，然后每个人都提交绝对高质量的代码？

其中一个重要的原因是历史相关的：我们已经太习惯于测试环境（尤其是与生产环境相仿的测试环境）的匮乏了。因为这样的环境是昂贵而不易获得的，所以我们要让它成为整个团队共享的资源；因为要让它被整个团队共享，所以我们要降低它的使用频率，所以要把它放在构建流水线的最后一环。

但研发云将改变现状。测试环境将不再昂贵：它可能仍然需要5台服务器，但由于每个环境的使用率只有10%，所以整体来说它没有那么贵。并且它也不再难以获得：云计算平台方便的开通（provision）加上自动配置工具例如Chef方便的配置（configuration），让我们只要一条命令加三十秒等待就能得到一套接近生产环境的测试环境。

于是我们的观念将发生一个根本性的转变。从前当我们讲“开发环境”，我们讲的所有东西都是基于“每个人一台电脑”这个假设。但这个假设不是必要的。我们每个人都可以有一整套生产环境来做开发。你仍然做单元测试，你仍然降低耦合，但此刻你不再与生产环境隔离——你随时身处在生产环境中，你随时可以看到刚写的代码在生产环境中如何工作，并且你写的所有代码将通过生产级别的验证之后才提交。

这时候我们已经不必再强调“持续交付”，因为我们的开发就是交付（Development As Delivery，DAD）。这就是“爹式开发”。

当然它不会那么容易就实现。一切使你无法做到爹式开发的障碍，我们都称之为“坑爹”。所以，在一个践行爹式开发的团队中，我们的口号就是“不坑爹”。

附录：由于爹式开发要求每个程序员充分了解生产环境，因此会极大地促进 DevOps 在团队中的推广。最终，爹式开发会造就一种新的、具备开发和运维全面技能的人才，他们会把开发和运维工作全部搞定。这些人开展运维工作的方式，称为“多技能运维模型”（Multi-skill Operation Model），缩写MOM，简称“妈式运维”。