标签：
按照发布流程正确的部署软件——二进制代码和与之相关的配置文件——到你的开发、测试、 验收或产品环境（DTAP）是一项复杂的任务，涉及到众多部门和团队。不幸的是，在许多组织中这项关键的流程还是费时并容易出错的。这篇文章里，我们会探讨开发团队、运维团队和其它相关方如何通过协作来准备一个“好”的部署软件包。“好”的软件包能减少部署中出错的可能，并在需要自定义环境时提高部署的透明性。此外，我们还会检视为何一个结构良好的部署包更易于转为自动化部署，提升生产率和可靠性，同时减少软件开发和维护生命周期中的错误和等待时间。区分部署过程中的担忧：为什么 vs. 如何做显而易见，部署包需要包含应用程序的所有组件。而不仅仅是你自己的二进制包——EARs，WARs之类——通常这些包由集成构建产生，还应包含静态内容、配置文件、共享库、防火墙配置等等。特别还应包括应用服务器的参数和设置，比如消息队列、连接工厂、数据源或类环境变量。实际上，软件包应包含软件生命周期中的所有内容，也就是那些需要一起被部署、升级和取消部署的内容。确保软件包是“完备的可部署单元”对于一次可靠的部署来说是至关重要的，特别是在大规模环境中。指望目标中间件栈（middleware stack）已经用“正确值”设置好是导致部署失败的一个常见原因，这通常导致耗费很多时间来找出不同环境中的细微差异，这往往是令人沮丧的过程。部署包中只包含配置信息，比如共享“服务”，例如为多个应用所共享的消息队列或数据源，这种情形不鲜见。这些配置显然应该按照有版本管理的、可部署的对象来处理，意味着这些配置文件按照和“普通”应用程序一样严格的流程来发布。实际上，平稳、可靠的部署共享服务通常更为关键。除了确保软件包最完整的描述了包含什么使特定版本的应用程序或配置正确工作，软件包还需要指出它们能够运行所需的其它东西。换句话说，部署软件包需要明确界定他们的先决条件和依赖，以便在匹配的环境上部署。准确的说，哪个部门负责部署和组织结构有很大关系。多数情况下是开发团队，他们通常能使用持续构建工具使某些发布流程变为自动化，但发布过程还可能涉及其它团队。举例来说，让DBA在发布前确认SQL脚本，或要中间件竞争中心（Center of Competence）检查中间件配置的情况并不少见。请不要增量式发布（Delta Release）通常，开发的一个目标就是尽量减小对目标环境的影响。显然，如果你的应用需要“不间断运行”或多个应用程序共享一个集群，不必要的重启服务器是要尽量避免的。为了达到这个目标，一个通常的做法是要求开发团队提交一个“增量”发布包，其中值包含新的或修改过的系统模块，并且只部署这些模块。经验显示，其实这是一个冒险的策略，应尽量避免，原因如下：标签：
原文地址：http://my.oschina.net/orgsky/blog/374636
