言之无物

我说的一切都是错的

拆书凤凰项目- 部署管道

《拆书凤凰项目- 部署管道》

经历了几个通宵,凤凰项目终于上线了,但部署的问题依然很严重,上周的一个变更部署,又花了一个通宵。总结会上,埃里克指出了问题的所在:虽然已经改善了工作流,但批量规模太大,部署涉及到太多方面,引发计划外的修复。需要建立起从IT运维部返回至开发部的不间断的反馈回路,在初始阶段就筹划产品的质量。

“如果每九个月才能打一发炮弹,就永远射不中你们瞄准的目标。别再去想那些内战时期的大炮了,想想高射机枪吧”。埃里克继续说道,“在任何一个工作系统里,理论上的理想状态是单一工作流,这样能让生产能力最大化,同时让变化幅度最小化。通过持续不断地降低批量规模,就能达到这种状态。”

开发总监克里斯说,连一个次要的漏洞修复部署都问题重重,我们无法承受每月一次的发布。我建议改成二个月发布一次。

这遭到了CEO斯蒂夫的反对,离购物季还不到30天时间了,由于延迟了很多的功能,预期的销售收益没有实现。我们没有时间了。

比尔理解克里斯的想法,要让笨重的凤凰项目起飞,的确不太可能。为了实现预期销售目标,比尔提议,组建一支特别行动队(Special Weapons and Tactics team,简称SWAT),叫他们去弄清楚,哪些功能可以帮助我们尽快达到收入目标。时间不多了,所以我们得谨慎选择功能。我们要告诉他们,为了完成这项工作,他们可以打破各种规则。这个建议得到了大家的认同。

究竟如何降低批量规模,实现快速的部署?比尔心里还是没谱,只好再次求教埃里克。埃里克又把比尔带到了MRP-8工厂,指着地面上的一长列设备说,那里的两道工序(喷涂、烘干)曾经是工作流的瓶颈,由于每项工作的准备时间很长,只好依靠巨大的批量规模来满足需求,把尽可能多的部件塞入烘房。但却无法满足客户的需求,即使客户愿意加钱,我们也无能为力。我们明白要提高生产力,必须降低批量规模,但每个人都说那是不可能的。

丰田公司的“快速换模”,为我们提供了思路。我们改良了流程,把四个工作中心合而为一,排除了三十多个容易出错的人工步骤,使整个工作周期完全实现了自动化,形成了单一工作流,并且去掉了所有的准备时间。生产能力一飞冲天。

“现在,轮到你了。”,埃里克指着比尔说,“你得想出办法来降低转换时间,让部署周期时间加快。”

“要怎么做?”,比尔还是一头雾水。

“把布伦特派到特别行动队中,和克里斯一起想想办法,如何才能保证在敏捷开发流程的每一个阶段,不仅有可推出的代码,还能具备能够部署这些代码的工作环境!”。埃里克严厉的说,“只要开发部和运维部协同工作,连同QA和业务部门一起,这个‘超级部落’就能够成就各种不可思议之事。”

“你们需要创建‘部署管道’,那是从代码签入到投产的整个价值流。那不是一种技术,而是生产。你们应该对所有东西都进行版本控制。所有东西,不只是代码,而是创建环境所需的每一样东西。然后,你们应该把整个环境创建流程自动化。在部署管道中创建测试和生产环境,然后彻底按照要求往里面部署代码。那样你们才能缩短准备时间并排除故障,才能随时跟上开发部的各种工作节奏。”

回到团队,比尔表达了埃里克1天10个部署的要求,每个人都觉得那是天方夜谭。问题出在哪里呢?为了弄明白部署流程,大家把部署所涉及的所有步骤都列在了白板上。从代码提交开始,也就是说整个流程包括了开发,测试以及运维的工作。流程优化必须从整个价值链出发,局部的优化没有意义。

比尔望着白板上几十个方框,让他联想到了工厂的工作中心,这不就是工厂的流水线吗?IT工作本质上和工厂是一样的,就是要打造一条价值流。这大概就是埃里克所说的部署管道吧。

现在,这条管道还体现不出价值,基本上每个环节都存在问题。但团队已经找到了思路,利用精益的方法,结合布兰特之前写的一些自动化脚本,自动化部署也不是那么遥不可及了。

点赞

发表评论

电子邮件地址不会被公开。 必填项已用*标注