对于上面的5个疑问词，Docker 只解决了其中的一个，而且是并没有采用最有效的方式。以一个欧洲著名银行为例，他们现在每个月发布的产品已经过千，这也只有在所有发布的产品都不是高风险的才能实现，在这个例子里，这意味着这些工件都是低风险类型。因此，这些类型工件的发布会很迅速，这有助于确保这个银行的客户的资产满足他们的需要。
然而，如果他们在使用Docker,无论这些类型的工件是否获得生产许可，整个应用都需要重建。对于大部分公司来说，直接将未获许可的二进制文件发布到产品中而带来的风险是不可接受的。这只是对于上面5项之一-Docker对于解决其他4项无能为力。
应用发布管理不只是应用
只从应用的角度考虑应用发布管理是很有趣的，而从业务的角度来看，忘记应用是更大场景的一部分。在上面How部分里，提到了ITSM，这不只是发布过程必须要集成的唯一技术。事实上，还有SDLC工具链与一系列适合特定需要的解决方案可供选择：适用于连续集成的Hudson 和Jenkins；用于源代码管理的Git和Subversion;用于工件管理的Nexus和Artifactory;用于配置管理的 Chef 和 Puppet 等等。
此外，在应用的生命周期中，发布应用的过程通常包括针对这过程的治理，但是这却不是该过程的一部分。然而，这些构建应用所要经历的阶段都是必要的，这可以将高节奏进行发布的风险降到最低，这包括许可、验证和其他类型的活动。
自动化是一切的关键
我们提到的每一件事对于应用发布来说都是关键的，但是，最后结果是什么。终端用户需要新的功能，应用开发团队能够以什么样的速度开发出新的功能并把它最终交付到终端用户手上，决定了新的功能能以多快的速度变成附加的收入。
此外，过程的可重复性能够保证应用发布更高的成功率，相反的，失败的部署会消耗你的公司资金，在诊断和修复过程中开发的应用数量也会受影响而下降。过去3年，分析公司的两项研究表明，财富1000强公司因变更、配置或其他与之相关的问题而导致应用中断的成本在$200k-400k/小时。
上述部分中的每一个工具只与应用开发和发布过程的一小部分有关系。类似地，Docker解决了与应用程序发布相关的工件管理，这样就可以简化这些工件的部署，确实如此。这些与其他解决方案的协调能力，必须要通过一个统一的方案来进行管理，这就是应用发布自动化的目标。
总结
总的来说，Docker是一项令人兴奋的技术，它应该被单纯看作是在整个应用程序发布周期中存在的另一种机制。但是它不应该被看作是一个定义良好方法的替代品，它不仅包括“what”，还包括“who”、“where”、“when”以及“how”。
投资于企业级自动化解决方案，实现关键任务应用的自动发布，不但可以提高部署应用的速度，而且能提高公司数字化转型的程度，随着更多的应用发布通过自动化完成，也会为公司带来更多的盈利。