无论你是推出一个全新的应用程序还是只是简单地对现有程序进行更新，在你按向启动按钮时，你可能经历了短暂的恐惧时刻。你甚至可能会感到一种强烈的，即将到来厄运的感觉，当你最后的部署工作在你面前毁了的时候。你清楚的记得那种感觉，就像看到的IT帮助台埋葬在一堆的门票之下，在在线更新几分钟或几小时后就开始流动。

　　你的组织不是犯错导致部署恶梦的第一人。了解应用部署问题的根本原因是防止未来部署损毁的第一步。这里介绍了一些最常见的错误：

　　使IT和终端用户分离

　　明确的通信优于部署是必要的。如果IT不分布关于部署的目的和参数的信息，那么用户可能会编造他们自己的关于变化的一些事情。然后，你就会看到IT泛滥着这样的问题，“我认为这个版本将会修复我上个月抱怨的XYZ。发生了什么事？”

　　即使是完美无缺的部署也有可能失败，如果它不能满足用户的需求。IT的目标可能与最终用户的目标完全不同。例如，IT可能承受着很多压力在满足部署的特定最后期限时。确保发布日期可能优先于确保UI是易于使用的。这导致抱怨的一个因素，也是确保在未来采用新技术有更多的阻力。

　　IT将永远也体验不到时顺畅的部署，如果50%的用户不知道怎样使用新的功能的话。部署前的沟通一定要包含培训，如果新技术的任何一个方面都不是不言自明，直观的话（在普通用户的体验中）。在部署时，通过确保已经开发的和提供给用户的文档的正确性，IT可以省去帮助台的大量请求。

　　缺失文件或脚本

　　对于软件，它所需要的是一个小的JavaScript文件，而且这个文件是没有随着其它的部分被收集和部署来启动一个滚雪球似的的错误报告和损坏的功能。如果这个是因为在手动收集和打包文件过程人为错误导致的循环问题的话，那么是时候去寻找一个自动化解决方案了。除了确保所有脚本都存在，并对应用程序本身有说明，你还应该确保安装程序是双重检查和充分测试的。

　　不适当的测试环境

　　直到你把所有东西放到一起并真正运行，你都不会知道在程序中哪里会有盲点。有时，就如可以很容易访问在终端用户的内部交付网络上的设置这样的因素都可以妨碍你的部署。这一应用程序可能在美国会工作的很好，但是在其它国家的卫星局就会完全不起作用（或者是你无法接受的长时间的加载时间）。可以在常常使用的浏览器上良好运行的应用程序，在你组织内的第二常用的浏览器上可能就会出现严重的性能问题。如果在测试环境中，你不能找到并修复这些问题，那么你将要处理泛滥成灾的HTTP 401请求。

　　有时，在你的组织内不适当的测试环境是不公平的。这种情况可能会发生在当你不知道从何处下载的，已经用在你的应用程序中的模型来创建程序时。对那些使用已经小的负载已经测试过程序的最初设计者来说，他们可能已经有了良好的跟踪记录。确保您的测试环境就是尽可能密切匹配于“真实的世界”，而且适当的负载大小是避开这些陷阱必要的措施。

　　一次做的过多

　　遗留设备、数据和软件都可以引起应用部署问题。你可能不能通过推出并发更新来更新你的应用程序触动的所有系统。事实上，这实际上可能会创建一个复杂项目，以致于它不会完成。在这种情况下，就要考虑一个受限的部署，与现有的应用程序并行运行。

　　有时，部署方法本身就与过时的系统不匹配。例如，你可能依赖于远程访问在跨分布式网络上分发或安装软件。如果本地计算机上没有安装安全外壳（SSH），那么你可能就会遇到问题。因此，在基于地理位置、部门或其它的一些参数来一部分一部分地部署就会有机会寻找故障，而不是一次性地每一个用户都让你窒息。

　　控制部署可能看起来更像预先需要更多的工作（尤其，你必须创建更多的代码，并允许使用新旧两个版本）。然而，与其双脚一起用力蹦，不是轻松地进入部署，这样更能阻止别人厌恶的崩溃。