软件交付很难；这个星球上有很多人都在为在他们自己的受控环境中交付软件而苦苦挣扎。他们发明了伟大的模式，可以构建一个工件，然后施展魔法，应用程序就可以启动并运行了。
在谈论持续交付时，人们总是会讨论他们的交付管道以及该管道中需要的不同组件。通常，对从该管道部署或升级应用程序的关注是如此强烈，以至于团队忘记了如何从头开始部署他们的环境。
在对代码运行大量测试并在需要的地方进行编译后，人们希望快速前进并将他们的发布工件部署到实际平台上。这种部署通常是通过文件上传或从应用程序所在的专用计算机的源代码控制工具检出来实现的。有时，会集成专用工具来模拟开发人员在计算机上手动执行的操作以使应用程序运行。向左复制三个文件，向右复制一个文件，并确保重新启动该服务。虽然这显然已经比人们从 42 页的运行手册中手动粘贴命令有了很大的改进，但它并没有解决所有问题。
就像那些在生产服务器上快速做出更改的人一样，永远不要提交更改（告别 git pull 升级过程）如果你打包你的软件，你可以从你的打包系统中免费获得一些东西。诸如此类的问题：这个文件在我部署后是否被修改过，这个文件从哪里来，它是什么时候部署的，我在我的所有服务器上运行的是什么版本的软件 X；我们已经为系统上的每个其他包使用的相同工具很容易回答。您不仅可以使用现有工具，而且还可以使用您的操作团队熟知的工具，并且它们已经用于您系统上的所有其他软件。
如果您的构建过程创建了一个包并将其上传到一个包存储库，该存储库可用于您要部署到的环境中的主机，则不再需要从 3rd 方位置复制工件的脚本，甚至更少对于那个永远不会更新的 42 页文本文档，它仍然告诉您从只能找到 3.2 和 3.1.8 的位置下载 yaja.3.1.9.war，并且开发人员知道您是否可以使用 3.2 或为什么使用 3.1。 9 只剩下长周末了。
另一个可能更重要的事情是，目前令人遗憾的是，有另一种工具正在将 42 页的文本文档转换为一堆从拖放界面创建的 shell 脚本，通常是“部署工具”甚至从管道内触发。除了它通常会激发不可重用代码模式、分发更多 ssh 密钥或在所有系统上添加另一个代理这一事实之外。它没有考虑到您希望将服务器视为牛并能够快速部署应用程序的新实例。
你真的想在 AWS 上部署你的五个新节点并为生产准备好完整的 Apache 堆栈，然后重新配置你的负载均衡器只是为了弄清楚有人需要点击你的持续集成工具或部署来将应用程序部署到新的主机？有人忘记了那个手动操作？
Imvho 部署工具是产品团队成熟过程中的一个阶段。是的，这是手动部署软件的一个进步，但它会产生更多和其他问题。一旦您的团队成熟，重构该工具就变得微不足道了。
解决这个问题的明显而简单的方法，它带来了更多的好处。称为包装。当您将工件打包为操作系统（例如 .deb 或 .rpm）包时，您可以将该包包含在要在安装时部署的包列表中（通过 Kickstart 或 debootstrap）。同样，当您的配置管理工具（例如 Puppet 或 Chef）配置计算机时，您可以指定您希望默认部署的应用程序版本。
因此，当您设计部署应用程序的方式时，请考虑部署新实例或部署到现有设置（或者更确切地说，升级您的应用程序）。当您想要部署一批新的服务器时，这样做会让生活变得更加轻松。