持续部署才是王道

原话是“Continuous Deployment is the holy grail”。在听到的这句话的时候，我的灯泡突然被点亮了。说得实在是太对了。有一句老话是“纲举目张”。意思是提起渔网上总绳，一个个网眼就会被张开。我们的很多实践，就像这渔网上的网眼，琳琅满目。我们缺乏的就是这样一个总绳来把所有的实践联系起来。No，No，No，你错了。你可能要说，我们有这样的一个总绳，它的名字叫Agile。那是昨天的名字了，今天的名字叫Lean，天晓得明天的名字会是啥。这个总绳，还叫Pragmatic，还叫Value Driven。这些确实是可以起到概括一切的作用，但是你怎么知道你做的是不是
Agile呢？是不是Lean呢？是不是Pragmatic呢？是不是Value Driven呢？这些都缺乏一个实际的可测性。Continuous Deployment，强大之处就在于，他很直白，甚至是缺乏内涵的。所以很容易知道，你到底做到了没有。这就是我们所需要的总绳，能够时刻时刻地把我们所有的实践团结在一起，纲举目张。

那么持续部署为什么就是王道了？这里有两个可以产生歧义的地方，持续部署与王道。什么是持续部署？而王道又是什么？Holy grail，王道其实就是说this thing is good。我们经常在口头上对某件事物表示赞叹，常用的词汇就是“好”。王道就是特别好。好是主观的，我认为软件开发这个领域中，好就意味能够从投入产生出持续的真金实银的回报。好也不在于界面如何友好，不在于code有多优美，所有这些指标都是间接的。唯一的指标就是到底产生了多少金钱上的回报。如果我们假设，软件开发产生回报的唯一手段就是把软件部署到产品环境，去提供服务（另外一个方面，如果不用部署就能产生回报，也许就不是一个软件开发项目，也许是某些政府部门的政治项目）。可以得出一个结论就是，要持续的产生回报就必须持续地进行部署。这看似是一个很浅显的道理，但是浅显的问题的可怕之处就在于，不是所有的人都意识到了这一点。

持续部署又是什么？持续意味着一直在部署，相对的就是偶尔部署。持续与偶尔部署的区别就在于，你把部署看做一种常态，还是一种偶然发生的事情。如果部署在所有的开发行为中，所在占到了10%而不是1%，那么就不再是偶尔才做的事情了。要想朝着持续部署的方向前进，意味着以前开发向前10步做一次部署，就得朝着5步一次部署，2步一次部署前进。持续并不是很难理解的问题，难度在于How？前面说了持续部署只是一个总绳，而渔网上的那么多的网眼就是How的答案。我们有SOA的架构，有高耦合低内聚的设计，有Domain Driven Design。有在线的Migration。给持续部署找出具体于你的Context的解决方案，就是整个Team需要努力的事情，它只是一个方向，而不是一个具体的solution。

最容易在实践中被混淆的就是“部署”。这似乎是另外一个很浅显的问题，但同样你会惊讶于到底有多少次我们做到了真正的部署。部署不仅仅是把软件包安装到某台机器上 ，让人可以来用。部署意味着，确实给业务提供服务。最容易检测的方法就是，把你部署好的软件反部署之后，会有多少业务无法运行，有多少比例的用户受到影响。根据这样的定义，部署到Staging环境不是部署，部署成为一个只有1%用户使用的Pilot版本也不是部署，部署到服务器上，但是所有用户仍然再用旧的系统，只是出于好奇才来用一两下的情况也不是部署。只有部署到产品环境上，给绝大部分用户使用，提供别的系统无法提供的服务时，才算是真正的部署。不要拿什么用户体验改进来搪塞了，不要再喊什么这只是一个Pilot了。只要不是真正地提供无可替代的服务，就根本不可能产生一个子的价值。“部署”成一个测试环境，只不过是给将来真正的部署，去赚那真真的一个子的钱，做准备而已。在此之前，都是投入，而不是产出。在产出真正实现之前，都是浪费。

你有没有问过你自己，你过去一年写的代码，有现在是部署了的。你过去三个月写的代码，现在是部署了的。你过去一个月写的代码，现在是部署了的。你过去两个星期的代码，现在是部署了的？不在于代码的多少，以及功能是否强大，只要是部署了，起码就有提供价值的可能。我们需要的就是，每天都问自己一遍这个问题。不但要个人的reflection，整个团队都要问这个问题。最重要的是，product owner，也就是我们乙方所谓的甲方，是不是也在问自己这个问题？如果是，那么很好，那么我们在追求卓越软件的道路上了，至少已经开始上路了。之前，只不过是在泥沼中爬行而已。

评论

2 楼 taowen 2010-03-10  

举一个例子，如果是一个已经存在的系统。你可以只添加一个新的Feature，但是这个Feature是和已有系统的其他部分集成起来的。这样不能商用吗？如果这个Feature需要修改现有系统，或者扩展现有系统的外部接口，就先把要改动的模块显式地分出来，然后再添加这个Feature。这个就是Eric Evan所说的Strategic Design。
第二个例子。如果不存在已有的系统。那么现在的业务是靠什么运行的。应该就是靠文档和各种单据吧。这不就是一个“现有系统”么？只是不自动化而已。同样可以引入一个Feature，去改善这个“现有系统”，把其余的任务仍然用手工完成。这样不能商用么？

1 楼 funcreal 2010-03-10  

仔细看了看，怎么感觉跟不上你的思路呢？
这里所说的部署感觉是要商用的意思，可是一个不完整的系统如何商用呢？