Java 在Jenkins上为多个环境构建构件并将其上载到S3

环境：

• 大约有十几种服务：war和jar（使用Tanuki包装器运行）
• 每个服务都被部署到开发、登台和生产中：环境使用不同的web.xml文件、Spring概要文件（在Tanuki包装器上设置）和
• 我们希望将工件存储在AWS S3上，以便EC2实例可以轻松获取它们：一些服务在多台机器上运行，自动缩放实例在启动后自动获取最新版本，开发工件在更新后应自动部署

我们当前的部署过程如下所示：

詹金斯构建并测试我们的代码

一旦我们感到满意，我们将发布（仅用于生产部署；开发和分段工件基于普通Jenkins构建）

我们为每个项目（开发、登台、生产）使用3个不同的升级作业来为所需的环境构建工件，然后将其上载到S3

这基本正常，但我们遇到了多个麻烦：

由于无法提交到存储库，Artifactory插件无法标记和更新源代码（这可能是特定于我们的Jenkins提供商）。没关系，我们可以手动完成

Jenkins无法正确处理多个上载目标（我们为每个环境使用一个）-它将尝试上载到所有目标，并在保存配置时复制设置：。没关系，我们正在使用一个shell脚本进行上传，效果很好

升级作业有时会失败，因为它们可以在与原始生成不同的实例上运行-要么导致失败（因为缺少文件而生成），要么导致过时的生成（因为正在使用旧版本）。同样，这可能是由于CloudBees提供的特定设置造成的。这可以通过再次运行构建来解决，并且希望这次在与its构建相同的实例上运行升级作业（这在我看来是纯粹的运气）

CloudBees建议我们在运行升级作业之前进行代码检查，因为工作区是短暂的，不能保证它存在或是最新的。然而，升级作业中的shell脚本似乎不支持另一个作业中所述的环境变量，即使它们链接在textarea字段下面。所以

svn checkout${svn_URL}-r${svn_REVISION}

不起作用

我很确定这可以通过一些变通办法来解决，但我肯定是做错了什么。我假设其他许多人也在以类似的方式部署他们的应用程序，并且一定有更好的方法——没有各种变通方法和麻烦

谢谢你的指点和阅读，直到最后

• 你面临的最大问题是，你实际上想做一个构建作为促销的一部分。升级的构建插件设计用于执行一些小操作，主要是对构建的存档工件，或者执行标记或其他类似操作
  • 该设计确保它在从机上获得一个工作空间。但是（这是一个一般的Jenkins问题，而不是CloudBees特有的问题）首先，您得到的工作区不必是您试图推广的构建所使用的工作区。它可以是：

  • 空的工作空间
  • 项目最新版本的工作区（可能是比您尝试升级的版本更新的版本）
  • 项目较旧版本的工作区（当您无法进入具有项目最新版本的从属版本时）
  现在，您得到哪一个完全取决于Jenkins集群所承受的负载。在CloudBees上运行时，您通常最有可能遇到上述两种情况之一
  • 因此，你在晋升中采取的行动应该是“自给自足”的。例如，他们将归档的工件复制到一个特定的目录中，然后使用这些复制的工件来完成他们的“任务”。或者，它们将触发一个下游构建，该构建将通过升级的构建的参数进行传递。或者，他们将在不使用任何本地状态的情况下在远程服务器上执行某些操作（例如，在蓝绿色部署中翻转开关）

• 在你的情况下，你在多条战线上作战。你在打的第二条战线是你在打Maven
  • Maven不喜欢在构建概要文件处于活动状态时生成不同的、非等效的工件
  • Maven可能会使用

    发行版
    概要文件来生成一个版本的工件，其中JavaScript被缩小了，调试信息也被删除了（不过如果可以避免的话会更好）。。。但这是因为这两个工件是等效的。JavaScript缩小的webapp应该和未缩小的webapp一样工作（除非缩小会引入bug）

  • 您可以使用概要文件来构建完全不同的工件。这是不好的，因为Maven没有将活动概要文件存储为部署到Maven存储库的信息的一部分。因此，当您声明对其中一个工件的依赖时，您不知道构建该工件时哪个概要文件处于活动状态。这样做的一个常见副作用是，最终会出现分裂的大脑工件，其中复合工件的一部分与开发数据库对话，另一部分与生产数据库对话。当开发人员因为过去被分裂的大脑工件烧坏而想要切换到构建生产构建时，当他们经常运行

    mvn clean install-Pprod&&mvn clean install-Pprod时，您可以看出存在这种糟糕的代码味道。这是糟糕设计的症状，而不是Maven的问题（除非能够
    echo '#!/usr/bin/env sh' > checkout.sh
    echo "svn revert . -R" >> checkout.sh
    echo "svn update --force -r ${SVN_REVISION}" >> checkout.sh