持续集成之“自动化部署”

　　在前文《依赖管理》中，我们讨论了如何在代码变得庞大，组件增多的情况下，做好外部库和内部组件依赖管理，从而提高构建效率。可以应用的实践包括：一次生成，多次复用;建立统一制品库，外部依赖库可以使用像Maven或Ivy这样的工具进行统一管理;对架构进行调整，使一个大的代码库分成多个组件;每个组件有自己的持续集成体系;对多个组件做持续集成。然而，解决一个问题后，总会有另一个问题等在那里，需要你来解决。这次Joe的团队遇到了部署问题。

　　星期一早上，Alice一进办公室，就看到一脸倦意的Joe坐在椅子上，喝着咖啡。

　　“今天怎么来得这么早?看样子，你没睡好啊?”Alice问道。

　　“当然啦，昨天晚上我就来了。”Joe无精打采地回答道。

　　“怎么啦?”

　　“还不是因为新版本上线出了点儿问题”，Joe说道。“看来我们要把部署这件事好好讨论一下，再这样下去，不只我要来，你们也要和我一样啦!呵呵!”

　　当天下午，Joe邀请了运维团队的主要负责人Tom和Steven，召开了一个关于部署问题的讨论会。

　　Joe说道：“先请运维部门的Tom介绍一下上周末的新版本上线过程和发现的问题吧。”

　　Tom描述了上线部署全过程。

　　不可重复且不可靠、易出错的手工部署过程

　　当新版本开发测试完成后，由开发团队的成员在浏览器上登录运维平台，填写上线申请单。申请单的内容包括新版本的上线部署步骤。

　　测试人员为了保证能够升级部署成功，首先要复制生产环境中的程序和数据到本地的测试环境中，然后根据上线申请单中所描述的上线部署步骤进行操作，对上线步骤进行验证。

　　运维人员登录到运维平台，收到上线申请单后，确认“已收到”。

　　运维人员发现上线部署步骤有问题，生产环境的路径与上线部署步骤中描述的不一致。于是与开发人员进行沟通，让开发人员修改上线部署步骤。

　　开发人员修改后，再次通知测试人员和运维人员查看并确认。

　　确认无误后，运维人员根据部署计划，登录到生产环境中，依照上线部署步骤，手工操作完成。

　　“上周末上线部署时出现的情况是：在本次部署之前，我们的集群中，有两台机器因HotFix，其程序配置被修改过，与其它机器不一致。因此，该机器上的部署失败，导致部分服务不可用。运维人员查了很长时间没有发现问题，星期日打电话把Joe叫来帮助我们查问题时，Joe才回忆起有那么一次HotFix，但当时负责的运维人员已经离职，没人其它运维人员知道这件事情。”Tom说道，“我们对问题进行了分析，认为应该加强我们的上线流程管理，对于那种HotFix也应该发起一个审批流程，并且在该流程中不但要主要负责人审批，而且要对相关人发出周知通报。另外，我们的运维人员应该对上线单进行严格审核，并对部署中所涉及的机器进行更详细的验证，对生产环境中的任何修改都要进行登记。即使非常紧急，也要在事后补充记录一下。”

　　“这些方法固然很好，但其实我们可以采用更好的办法来解决。”Joe接着说到，“假如我们在部署运维工作也能够借鉴持续集成的做法，利用一些最佳实践，那么这次部署事故根本就不会发生。比如(1)将部署操作脚本化;(2)进行持续部署验证测试;(3)部署脚本通用化，环境变量等使用配置方式传入;(4)让测试环境尽可能与生产环境一致，至少在成本条件允许的情况下尽量保持相似;(5)对环境配置进行版本控制;(6)任何人不得直接对生产环境进行直接的手工操作，等等。”

　　将部署操作脚本化，并进行部署验证测试

　　Bob说道：“嗯，其实那些上线步骤中所描述的内容都可以进行脚本化，之前也讨论过这一问题。目前上线步骤中的内容基本都可以写成自动化脚本，即使现在不行，也可以通过少量改造，使其可以自动化。但问题是... ...”Bob犹豫了一下，接着说道，“如何来验证这些脚本是正确的呢?”

　　Joe 说道：“保证运维人员是如何验证上线申请单上的上线步骤是正确的呢?同样，我们也可以做一些部署验证就行了。这些部署的验证也可以通过脚本方式来进行，比如在安装之前验证程序所用端口没有被占用，安装之后验证该端口已被该程序所使用;比如安装之前验证程序日志中记录了该程序已停止运行，在安装之后验证程序日志中刻录该程序已重新启动;等等”。

　　Alice问道：“那我们还要调试这些部署脚本呀?没有线上生产环境，我们怎么调试呢?”

　　各类环境尽可能相似，并使部署脚本通用化

　　Joe 回答道：“首先我们应该加强基础设施这方面的投入。在力所能及的情况下，让测试环境与生产环境相似。比如，生产环境可能有100台机器的集群，那我们至少要找两台机器的集群做测试环境。生产环境中使用Tomcat，我们的测试环境和开发环境中也应该使用相同的Tomcat，而不用Jetty。”

　　Joe 停下来，喝了一口咖啡，接着说道：“这样一来，我们的部署脚本就可以在开发环境、测试环境进行测试了。当开发人员进行本地测试时，可以使用这个脚本进行单机的部署。当测试人员进行集成测试时，可以使用同样的脚本进行多机部署。与机器数量无关的配置可以统一放在某配置文件中。而与机器数量等相关的配置可以放在另外的配置文件中。由于在真正上线部署之前，开发人员和测试人员已经使用同一个脚本进行多次部署，就是对该脚本进行的测试。当我们上线部署时，只有与机器相关的配置文件会有变化，其它配置基本相同，所以上线部署时脚本出错的几率已经比较小了。而且，这种自动化没有人工干预，也不会发生手工误操作。”

　　Tom问道：“那这些脚本由谁来写?由谁维护呢?”

　　Joe回答道：“谁最了解情况，就由谁来写。其实，我们也应该像对待产品代码一样，来对待这些脚本和配置文件，把它们放在我们的代码库里，进行版本控制。无论是运维人员还是开发人员，或者测试人员，对这些脚本的修改都应该提交到版本控制库中，除非他所做的修改只是为了测试他自己在本地的程序，那就不用提交了。这样一来，‘谁在什么时候对什么进行了修改，为什么做修改?’这个审计问题就可以直接由版本控制系统来回答，也就做到了所有内容可追踪了。”

原文转自：http://www.ltesting.net