上线：准备和部署软件包时开发和运维的角色解析.doc

上线：准备和部署软件包时开发和运维的角色 来源: infoq??发布时间: 2011-05-31 17:27??阅读: 883 次??推荐: 0?? 原文链接?? [收藏]?? 摘要：按照发布流程正确的部署软件——二进制代码和与之相关的配置文件——到你的开发、测试、 验收或产品环境（DTAP）是一项复杂的任务，涉及到众多部门和团队。不幸的是，在许多组织中这项关键的流程还是费时并容易出错的。 　　这篇文章里，我们会探讨开发团队、运维团队和其它相关方如何通过协作来准备一个“好”的部署软件包。“好”的软件包能减少部署中出错的可能，并在需要自定义环境时提高部署的透明性。 　　此外，我们还会检视为何一个结构良好的部署包更易于转为自动化部署，提升生产率和可靠性，同时减少软件开发和维护生命周期中的错误和等待时间。 　　区分部署过程中的担忧：为什么 vs. 如何做 　　显而易见，部署包需要包含应用程序的所有组件。而不仅仅是你自己的二进制包——EARs，WARs之类——通常这些包由集成构建产生，还应包含静态内容、配置文件、共享库、防火墙配置等等。特别还应包括应用服务器的参数和设置，比如消息队列、连接工厂、数据源或类环境变量。实际上，软件包应包含软件生命周期中的所有内容，也就是那些需要一起被部署、升级和取消部署的内容。 　　确保软件包是“完备的可部署单元”对于一次可靠的部署来说是至关重要的，特别是在大规模环境中。指望目标中间件栈（middleware stack）已经用“正确值”设置好是导致部署失败的一个常见原因，这通常导致耗费很多时间来找出不同环境中的细微差异，这往往是令人沮丧的过程。 　　部署包中只包含配置信息，比如共享“服务”，例如为多个应用所共享的消息队列或数据源，这种情形不鲜见。这些配置显然应该按照有版本管理的、可部署的对象来处理，意味着这些配置文件按照和“普通”应用程序一样严格的流程来发布。实际上，平稳、可靠的部署共享服务通常更为关键。 　　除了确保软件包最完整的描述了包含什么使特定版本的应用程序或配置正确工作，软件包还需要指出它们能够运行所需的其它东西。换句话说，部署软件包需要明确界定他们的先决条件和依赖，以便在匹配的环境上部署。 　　准确的说，哪个部门负责部署和组织结构有很大关系。多数情况下是开发团队，他们通常能使用持续构建工具使某些发布流程变为自动化，但发布过程还可能涉及其它团队。举例来说，让DBA在发布前确认SQL脚本，或要中间件竞争中心（Center of Competence）检查中间件配置的情况并不少见。 请不要增量式发布（Delta Release） 通常，开发的一个目标就是尽量减小对目标环境的影响。显然，如果你的应用需要“不间断运行”或多个应用程序共享一个集群，不必要的重启服务器是要尽量避免的。 为了达到这个目标，一个通常的做法是要求开发团队提交一个“增量”发布包，其中值包含新的或修改过的系统模块，并且只部署这些模块。经验显示，其实这是一个冒险的策略，应尽量避免，原因如下： 准备一个增量发布通常都是手工任务，完全依赖开发人员判断哪些是修改过的模块而哪些不是。这是一个耗时的又容易犯错的过程，因而这个过程几乎不可重复 。 某个应用程序部署包的版本不适合实际部署——在最坏的情况下；可能所有的组件都需要上一版本。部署到一个“干净”的环境（设想需要快速设置几个干净的镜像来重现一个压力问题）则更加复杂，失败的风险也因所有早期版本的包必须还要保留、并按照顺序保留而增大。这是因为，当然，简单来说就是数据库增量备份的问题。 除非应用程序的每个版本都部署到了每个环境，否则在升级到相同版本时会产生问题，因为需要从不同的版本升级。这很快会在选择了错误的增量发布包时导致混乱和产生错误。 不包括完整的包，而只是一些碎片的发布仓库不是一个好的最终软件库的候选。 上述各点都无法让减小部署影响的目标失效，这是显而易见的。但部署包不能解决问题 。实际上，部署流程才能应该通过在部署时推知哪些组件应增加、哪些被修改和哪些应移除，并据此实施来满足这个需求。 在时限压力下手工实现上述部署流程是非常困难的（开发人员总是首先要做增量发布包），而一个好的自动部署系统能够很容易地实现上述目标。实际上，这是引入自动化部署的一个主要好处。 　　在上述情况下，通常会设立专门的发布管理小组负责协调各种交付物，部署包按照便于恰当的人更新、修改和批准部署包的内容来组织是非常重要的。 　　构建部署包是一个需要多个步骤的工作流，需要很多部门参与并耗时很长，也会产生准备“不完整”部署包的情况。这种情况下，发布管理系统不产生这种“不完整（draft）”发布包非常重要。 　　我们建议由恰当的人员对已批准和已发布的包进行数字化签名，这样所有的包在部署前都通过验证，为部署安全提供更进一步保