持续集成交付的流水作业

最近和一位朋友讨论持续集成、持续交付在企业的具体价值，和具体执行时的岗位要求，比较值得让我们思考。

我看的持续交付（Continuous Delivery），主要实现一套自动化的软件生产线，在生产线的开端，是程序员提交代码，而生产线的产出物就是要交付的东西：

• 如果企业是需要运营一个平台的，交付的就是一个更新后的平台；
• 如果企业是交付APP的，最终交付的应该是发布到市场上的APP；
• 如果企业是做软件产品的，刻录到DVD上的，最终交付的可能是一个ISO文件。

能在整个交付的流水线的自动化，我们普遍相信能提高软件的质量，因为在中间的生产过程，都已经标准化了，不存在中间过程会因为某种人为的误操作而导致错误，而往往这些错误都是非常严重而不容易发觉的。通常在开源项目里，开发者人员流动是不能控制的，一套自动化的交付体系相当重要，它能大大降低入门的门槛。放在企业上，也应当如此。期望的结果是：一个开发者能以低成本的进入项目，能尽快为企业创造价值。

把交付过程中一切能自动化的步骤都做到自动化，是整个持续交付的核心重点。

对于什么岗位能完成这个自动化的生产线？因为要完成一条自动化的软件生产线，大概需要以下要求：

• 在企业里有一定权力调动资源
• 对软件开发流程熟悉，知道每个环节的输入、输出、难点
• 熟悉产品的交付时使用的工具（maven, nexus/artifactory, scp, shell-scripting, make, msbuild之类）
• 熟悉虚拟化技术（因为有可能需要启动一个虚拟环境做验收测试后才可以上线）
• 熟悉配置管理工具，如puppet、chef、cfengine等
• 对系统安全、保安方面有一定理解和执行能力（不能因为某员工的恶意干预导致生产线出问题）

要单独完成生产线自动化，需要有全面技术知识的全栈工程师，否则就需要一个DevOps团队协作来完成。但是团队协作相信没有一个全栈工程师来做来的有效率。若要用一个团队来做，也需要有个拥有多方面知识的协调牵头的人领导才会成功。

这样涉及到另外的问题：如何找到这样的人？在我的经验里，企业中人员的跨领域性是不够的，我们通常看到的问题是 “这个不应该是我负责” 之类的回应，内部提拔艰难重重。社会招聘，又因为全栈工程师往往被标签为 “什么都会、什么都不会”，招聘对于面试考官的考验更大。

面对老板，自动化生产线没有立即的回报，还有完成建立了自动化生产线后，这个人的价值是否就减退，甚至没有价值了，成为疑问。但是，工厂的生产流水线也会因着不同情况来改造，同样我相信软件交付会因着不同新的技术情况而有所调整，达到持续改进的境地。

以上说的是对持续交付流程建设上的人员要求。

我们也需要讨论的是，是否所有系统架构都能做持续交付？怎样的系统架构能更好的支持持续交付的模式呢？

举个极端例子：如果系统架构是依赖关系模糊不清，一个简单改动有可能导致系统崩溃的情况，这样就算做了完美的持续交付流程，相信开发团队也不会超过5人，因为这样造成了另外一种入门门槛，真正的创新和创造价值的部分，达不到规模效益。但是，运帷团队就可能有几十人，因为要比较多的人手去救火。企业如果出现这种现象，相信距离死亡不远了。