Q​Club（北京）回顾——DevOps与持续集成（含资料下载）

2011年7月15日，InfoQ线下活动QClub北京站活动，于周五晚在北京贝塔咖啡举办，本次活动有幸邀请到ThoughtWorks公司CTO Rebecca Parsons演讲，演讲主题包含DevOps和Continues Delivery两部分。 

Rebecca首先从软件交付的现状谈起，传统的软件交付周期分为开发、用户接受测试和部署等阶段。但是随着市场竞争的日益激烈，越来越多的公司需要加快部署和上线，从而提升其在市场中的地位和价值。于是，持续交付就应运而生了。

持续交付的目标是：“在任何时间只要点击按钮即可完成发布”。这样做的前提是需要将大部分的工作自动化，比如环境搭建、配置文件、编译、测试和部署等。 

Rebecca提到：

即使具备发布所有功能的能力，也不要一次都将它们发布。

开发环境的建设要尽可能的脚本化，其中包括：操作系统、系统软件、操作系统配置信息以及补丁的版本。配置管理要经常使用，此外要养成将代码及时提交到版本库的习惯，同时还要了解和熟悉不同应用间的版本关系。

在编译阶段，要尽可能采用持续集成，要讲究依赖包的管理，而且还要具备随时都可将代码从版本控制上获得并在本地运转的功能。 从数据库层面来讲，不可能把生产数据放到版本管理中，但是在测试环境中这点就不难做到，所以在测试环境安装时会变得很容易。

在测试阶段，各个级别的测试都应该尽可能的自动化，Rebecca特别提到了性能测试，她认为性能测试应该在项目初始阶段就应该有，虽然这样做在项目初期并不是很明显，但是随着项目的展开，性能测试的持续执行，很快就能看出是在哪一次代码提交后产生的性能瓶颈。Rebecca建议冒烟测试主要走功能的主线，这样在自动化后，就如同在系统内部形成一长安全网，这样才有可能做到持续的发布。 此外，虽然能够实现测试的自动化，但这并不意味着就可以忽略手工的探测性测试，自动化测试是最基础的保证，为的是修改关键依赖后，还具备持续发布的能力。因此，QA或测试人员，手动测试以及探索性测试仍然在整个发布过程中占据相当重要的地位。

在部署阶段，从传统的开发角度上来讲，部署成功是件令人鼓舞的事情，但是持续交付的目标恰恰相反，持续交付的思想认为，部署成功应该变成一件很自然的事情，只有不停的做，才能够保证足够的正确性。再次Rebecca提醒大家注意两点：

• 尽可能的把一切操作都脚本化、自动化，其中包括软件安装，这样才能够在开发、测试、预览环境上不停地去执行脚本。不同的是，配置参数的细微差别，只有做到了这样，最后部署到生产系统上时，脚本才会变得非常成熟和可靠。
• 开发环境到生产环境的迁移要尽可能的自动化

持续交付的所带来的好处主要有两个层面： 

部署层面: 

• 无压力部署
• 速度快 
• 在工业发布时尽可能避免人为的错误
• 使部署成为了一件常规的事情，而不是冒险的事情

维护层面： 

如果有了这样的一个可将生产环境问题复现的过程，在发布时发现了问题，就会很容易在开发或测试环境中复现，即使这样做并不一定100%会有帮助，但这种方法的确是一个快速定位BUG的方法。

接下来Rebecca分享了DevOps上的一些实践经验。 

Rebecca 提到，DevOps不是技术层面的问题而是人和组织的问题，人员间的相互合作，会减少软件缺陷的出现，而且一旦在维护期间发现问题，运维团队还可以很快就能分辨出什么样的日志能够有效的记录问题，从而加快软件上线的时间，减低错误率，缩短问题修复时间，最终达到提高软件质量的目的。

在提到持续交付和DevOps的区别时，Rebecca是这样回复的：

持续交付关注于开发流程和技术要提高的方面，DevOps则是关于组织中人员架构和人员协作的问题。传统的团队，开发和运维是两个毫无关联的部门，这就导致运维人员非常痛苦。DevOps就是要打掉组织中的这堵墙，在开发阶段就让运维团队融入进来，使开发和运维人员相互了解和合作，而且，运维人员还可提出意见供开发人员参考。

一些组织已经采取了精益运营（Lean Operation）的实践，运维团队也有了自己的故事墙和迭代计划，从而达到提高运维效率的目的。

此外，运维团队具有保护生产环境的职责，DevOps的目的是增强沟通，互相理解。

最后，Rebecca总结了如何使持续交付和DevOps变得可能：

• 工作不是一两周就能做完的，而是一个长期艰苦的过程，每次迭代和尝试都是为了让开发变得简单，这就要求至少第一要有版本管理，第二要有持续集成。
• 所有的工作尽可能自动化起来，让脚本用起来。
• 在选择第三方软件包及应用时，应该首先看第三方包是否支持脚本的启动和关闭，因为有些软件和应用不支持脚本，只提供在界面中操作。因此，这类软件的被可自动化程度是非常低的。
• 应尽可能保证所有环境是相似的。
• 运维阶段在处理紧急事件时，最快的当属直接在生产环境修改代码，但是这样的方法应当尽量避免。如果万不得已真的做了，也要尽快使代码处于版本控制之下。总之，所有的配置项和代码都应当从版本管理系统中获取。

在开放讨论环节，Rebecca回答了到场人员的提问：

问：冒烟测试、性能测试、回归测试之间应当是怎样的一个顺序？

答：当有了第一次发布的时候，一旦遇到新的功能或Bug要及时上线，第一应当是需求，第二是性能测试，最后是冒烟测试（也可以和回归测试和冒烟测试结合起来）

相关资料下载

1. 本次活动演讲稿下载：Rebecca谈DevOps和持续交付实践
2. 本次活动精彩照片请参见：本次活动照片
3. DevOps: Friction-Free Collaboration for Development & Operations（需注册方可观看）