持续部署才是王道

原话是“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,也就是我们乙方所谓的甲方,是不是也在问自己这个问题?如果是,那么很好,那么我们在追求卓越软件的道路上了,至少已经开始上路了。之前,只不过是在泥沼中爬行而已。

你可能感兴趣的:(软件测试,SOA)