按照发布流程正确的部署软件——二进制代码和与之相关的配置文件——到你的开发、测试、 验收或产品环境（DTAP）是一项复杂的任务，涉及到众多部门和团队。不幸的是，在许多组织中这项关键的流程还是费时并容易出错的。这篇文章里，我们会探讨开发团队、运维团队和其它相关方如何通过协作来准备一个“好”的部署软件包。“好”的软件包能减少部署中出错的可能，并在需要自定义环境时提高部署的透明性。此外，我们还会检视为何一个结构良好的部署包更易于转为自动化部署，提升生产率和可靠性，同时减少软件开发和维护生命周期中的错误和等待时间。区分部署过程中的担忧：为什么 vs. 如何做显而易见，部署包需要包含应用程序的所有组件。而不仅仅是你自己的二进制包——EARs，WARs之类——通常这些包由集成构建产生，还应包含静态内容、配置文件、共享库、防火墙配置等等。特别还应包括应用服务器的参数和设置，比如消息队列、连接工厂、数据源或类环境变量。实际上，软件包应包含软件生命周期中的所有内容，也就是那些需要一起被部署、升级和取消部署的内容。确保软件包是“完备的可部署单元”对于一次可靠的部署来说是至关重要的，特别是在大规模环境中。指望目标中间件栈（middleware stack）已经用“正确值”设置好是导致部署失败的一个常见原因，这通常导致耗费很多时间来找出不同环境中的细微差异，这往往是令人沮丧的过程。部署包中只包含配置信息，比如共享“服务”，例如为多个应用所共享的消息队列或数据源，这种情形不鲜见。这些配置显然应该按照有版本管理的、可部署的对象来处理，意味着这些配置文件按照和“普通”应用程序一样严格的流程来发布。实际上，平稳、可靠的部署共享服务通常更为关键。除了确保软件包最完整的描述了包含什么使特定版本的应用程序或配置正确工作，软件包还需要指出它们能够运行所需的其它东西。换句话说，部署软件包需要明确界定他们的先决条件和依赖，以便在匹配的环境上部署。准确的说，哪个部门负责部署和组织结构有很大关系。多数情况下是开发团队，他们通常能使用持续构建工具使某些发布流程变为自动化，但发布过程还可能涉及其它团队。举例来说，让DBA在发布前确认SQL脚本，或要中间件竞争中心（Center of Competence）检查中间件配置的情况并不少见。请不要增量式发布（Delta Release）通常，开发的一个目标就是尽量减小对目标环境的影响。显然，如果你的应用需要“不间断运行”或多个应用程序共享一个集群，不必要的重启服务器是要尽量避免的。为了达到这个目标，一个通常的做法是要求开发团队提交一个“增量”发布包，其中值包含新的或修改过的系统模块，并且只部署这些模块。经验显示，其实这是一个冒险的策略，应尽量避免，原因如下：
准备一个增量发布通常都是手工任务，完全依赖开发人员判断哪些是修改过的模块而哪些不是。这是一个耗时的又容易犯错的过程，因而这个过程几乎不可重复 。
某个应用程序部署包的版本不适合实际部署——在最坏的情况下；可能所有的组件都需要上一版本。部署到一个“干净”的环境（设想需要快速设置几个干净的镜像来重现一个压力问题）则更加复杂，失败的风险也因所有早期版本的包必须还要保留、并按照顺序保留而增大。这是因为，当然，简单来说就是数据库增量备份的问题。
除非应用程序的每个版本都部署到了每个环境，否则在升级到相同版本时会产生问题，因为需要从不同的版本升级。这很快会在选择了错误的增量发布包时导致混乱和产生错误。
不包括完整的包，而只是一些碎片的发布仓库不是一个好的最终软件库的候选。
上述各点都无法让减小部署影响的目标失效，这是显而易见的。但部署包不能解决问题 。实际上，部署流程才能应该通过在部署时推知哪些组件应增加、哪些被修改和哪些应移除，并据此实施来满足这个需求。在时限压力下手工实现上述部署流程是非常困难的（开发人员总是首先要做增量发布包），而一个好的自动部署系统能够很容易地实现上述目标。实际上，这是引入自动化部署的一个主要好处。在上述情况下，通常会设立专门的发布管理小组负责协调各种交付物，部署包按照便于恰当的人更新、修改和批准部署包的内容来组织是非常重要的。构建部署包是一个需要多个步骤的工作流，需要很多部门参与并耗时很长，也会产生准备“不完整”部署包的情况。这种情况下，发布管理系统不产生这种“不完整（draft）”发布包非常重要。我们建议由恰当的人员对已批准和已发布的包进行数字化签名，这样所有的包在部署前都通过验证，为部署安全提供更进一步保障。深入到比特和字节选择部署包格式主要是从方便起见。当然，部署包应该：
便于移动——最好是个单一文件
便于检查
可压缩，因为文本文件，如SQL或配置文件压缩率很高
支持某种错误修正
可移植（比如开发人员在Windows环境开发，生产环境是UNIX）
可进行数字化签名，目的是可以验证待部署的包是通过审批的包。
所以通常来说，选择一种压缩文件格式，比如ZIP、TGZ或RPM，作为发布包的格式，但具体选择哪种完全取决于你自己。
目前关于build文件格式没有多少可说，因为除了WAR就是WAR。然而对于配置文件，情况则大不相同。目前，如果消息队列和数据源的定义，甚至包本身（在发给运维团队的成员的电子邮件中碰见这种情况很常见）通常都只是由人们可读的文档来描述的，比如发布注记（release notes）或按模板写的Word文档，这些文档非常容易引起歧义并难于检查修改。基于上述原因，配置文件也应该由机器可识别的格式来定义，比如XML。不幸的是，在这个方面目前还没有什么标准可推荐。事实上，这方面也是我们非常希望和用户及供应商合作的。最好避免使用某种特定中间件定义的格式，比如WebSphere的XML配置。有时直接从已有的配置文件中抽取配置项看上去很方便，但这样会限定于某个中间件供应商，在部署到不同的服务器环境时可能会遇到困难。通常，这是完全可以避免的，因为应用程序通常不会用到特定中间件的某个特定特性，因此可以在自己的配置文件中很容易的定义更“一般”的JMS队列，数据源等等。最后， 声明文件或清单应该能描述包的内容。应该在这里列出包的依赖关系，给操作者的描述和任何其它不容易找到的信息，比如开发人员的联系信息，项目名称，等等。声明文件还需指出包内项目内容的类型，这些内容往往不容易通过名字判断出来：EAR文件显然是EAR但是一个ZIP文件可能包含HTTP服务器的的静态内容、应用程序配置文件等等。再次指出，文件格式应该是机器可读并可验证的，同时也应该是容易自动生成的（比如从构建系统生成）。我们现在有了方便的、可移植的并能自动部署的软件包，这个软件包也是待部署应用程序要包含什么内容的完整描述。到现在，我们还没说任何如何部署的内容。发布注记在哪儿？部署和回滚计划呢？理想情况下，应该没有这些东西。更准确的说，标准的Java EE应用程序的部署流程应该，以部署包内容为基础，是足以完成正确部署的。应用程序特定的部署步骤意味着满足该应用程序的些特殊要求，这些特殊要求在之前只有开发人员了解。当凌晨2点钟时需要进行一次紧急部署，而无法联系上开发人员，运维人员犯错几乎是不可避免的。简单来说，开发人员应该知道什么应该被部署，他们不应该为如何部署而操心。当然，组织内有标准的Java EE部署流程是实现上述目标的先决条件，当你的组织有几类不同的应用时可能有几个流程。这个流程要足够复杂，以便能覆盖在部署时所需的各个组件和配置，但限制可选项的数量以保证流程的可维护性、测试性和可靠性也同样重要。这必然会给开发技术加上一些限制条件。然而，相比在当前的情况下维护成本是运行应用程序中最大的日常开支这一事实，减小犯错可能性、更可靠的部署流程带来的好处胜过最大化开发灵活性。当然，在每个组织都需要依据自身的要求来平衡这两者。标准的部署流程不只是更容易维护。它也使运维人员在压力下更可靠的执行操作，相比于依照大量针对不同应用程序的不同版本的发布注记手工操作容易得多。标准部署流程也会让自动化变得更简单，让运维人员从重复任务中解脱出来，同合适的访问控制相结合，可以让开发人员自己执行部署。如果有适合的集成点，将构建和发布系统连接起来实行持续部署以达到真正的端到端自动化也是有可能的。此外，实现更多的自动化部署流程来支持更复杂的场景，让开发团队在避免临时流程时更加灵活性更容易。不过随着自动化流程变得越来越复杂而难于实现和测试，是否采取复杂的自动化流程需要仔细考虑。但是相对手工流程明显的优势是，一旦自动化流程通过测试和校验，你可以确保流程的所有步骤是执行结果是可预测的。对人们来说，不断成功的执行复杂的、步骤众多的流程的目标是非常难以达到的。