部署脚本是否应该是构建的产物？

这是一个用Java编写的Web项目。

因此，我正在编写构建和部署脚本。为了创建构建，我使用了ant。詹金斯（Jenkins）完成了连续构建。

构建生成3个不同的工件：

1. 战争档案
2. 带布局的拉链
3. 带图片的拉链

到目前为止，一切都很好，但是现在我需要编写部署脚本，该脚本应该：

• 将战争（工件1）部署到在服务器1上运行的tomcat
• 将工件2放置在服务器1的特定目录中
• 将工件3放置在服务器2的特定目录中

因此，我正在与我的同事交谈，他说我们还应该生成一个工件（也许是deploy.xml），当将其放置在正确的服务器上时，就可以部署这些工件。

因此，将有另一个脚本，它将是：

• 下载詹金斯文物
• scp到每个服务器，并将deploy.xml放在此处
• 远程调用deploy.xml

使我有些不舒服的是将deploy.xml作为构建工件的行为。其背后的动机是能够进行部署而无需访问VCS存储库，因此构建将是自包含的，即，任何构建只能使用Jenkins生成的内容才能投入生产。

部署脚本应该放在哪里？它们应该只在VCS还是应该是构建工件？

我的经验是一切可以被自动化应该是。如果您可以将其描述为第1步，第2步...，那么它应该是一个脚本。如果可以自动生成脚本以包括特定于构建的信息（例如，修订标签），那么您应该这样做。这不是为了懒惰，而是为了可预测和可复制。

注意：您还应该有一个自动生成的还原脚本，团队中的任何人都可以使用该脚本，以防自动生成的部署脚本发疯并拖累生产服务器。

彼得·罗威尔（Peter Rowell）所写的一切都是正确的，此外，我还会：

对于部署脚本文件

• 如果它是由某人编写的，则需要处于版本控制中。
• 如果已生成并且可以再次生成，则通常不会进入版本控制。

对于部署过程：

• 如果您希望工件是独立的并且可以轻松完成，则该文件可以是构建工件，这意味着将其与构建结果打包在一起，以使其可用于部署。
• 另一方面，部署变得越来越复杂，所以迟早您需要一个专用的程序（阅读一些代码）来进行部署，而Jenkins构建的工件不再是自包含的。

而是取决于您的流程以及您喜欢如何处理部署。