在Jenkins上为多种环境构建工件并将其上传到S3

Question

环境：

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

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

1. Jenkins构建并测试我们的代码
2. 一旦感到满意，我们将使用Artifactory插件发布（仅用于生产部署；开发和登台工件基于纯Jenkins构建）
3. 对于每个项目（开发，暂存，生产），我们使用带有3个不同升级工作的Promoted Builds插件来构建所需环境的工件，然后将其上传到S3

这通常可以，但是我们遇到了很多麻烦：

1. Artifactory插件由于无法提交到存储库而无法标记和更新源代码（这可能特定于我们的Jenkins提供程序CloudBees ）。 没关系-我们可以手动执行此操作。
2. Jenkins S3插件不适用于多个上传目标（我们在每个环境中都使用一个）-当您保存配置： JENKINS-18563时，它将尝试上传到所有目标并重复设置。 没关系-我们使用的是Shell脚本进行上传，效果很好。
3. 升级作业有时会失败，因为它们可以在与原始版本不同的实例上运行-导致失败（由于文件丢失而导致的版本）或过时的版本（由于使用了旧版本）。 同样，由于CloudBees提供了特定的设置，因此可能会发生这种情况。 可以通过再次运行该构建，并希望此次升级作业在与其构建相同的实例上运行来解决此问题（根据我的理解，这很幸运）。

CloudBees建议我们在运行升级作业之前进行代码签出，因为工作空间是短暂的，并且不能保证该工作空间是存在的或最新的。 但是，升级作业中的Shell脚本似乎不遵循另一个StackOverflow线程中所述的环境变量，即使它们被链接在textarea字段下方。 因此svn checkout ${SVN_URL} -r ${SVN_REVISION}不起作用。

我很确定可以通过某种解决方法来解决此问题，但是我肯定做错了什么。 我假设许多其他人正在以相似的方式部署他们的应用程序，并且必须有一种更好的方法-没有各种变通办法和麻烦。

感谢您的指点，并阅读完所有内容！

Answer 1

• 您面临的最大问题是，您实际上想在升级过程中进行构建。 升级的构建插件旨在执行一些小操作，主要是对构建的归档工件进行一些小操作，或者执行标记或其他此类操作。

  • 该设计确保它在从属设备上获得一个工作空间。 但是（首先，这是Jenkins的一般事情，而不是CloudBees特有的问题），首先，您获得的工作空间不必是您要升级的构建所使用的工作空间。 它可能是：

    1. 空的工作区
    2. 项目的最新版本的工作空间（可能是比您要推广的版本新的版本）
    3. 项目的较早版本的工作空间（当您无法进入具有项目最新版本的从站时）

    现在，您将完全依赖于Jenkins集群所承受的负载。 在CloudBees上运行时，通常最有可能遇到上述前两种情况之一。

  • 因此，您在促销中采取的行动应“自给自足”。 因此，例如，他们会将存档的工件复制到特定目录中，然后使用这些复制的工件进行“处理”。 否则，它们将触发下游构建，并传递来自升级构建的参数。 否则，他们将在不使用任何本地状态的情况下在远程服务器上执行某些操作（即，将开关切换为蓝绿色部署）

• 就您而言，您正在多个方面进行斗争。 您要抗争的第二战线是您正在抗击Maven。

  • 当活动的构建概要文件生成不同的，非等效的工件时，Maven不喜欢它。
  • Maven可能会与release配置文件一起使用，从而生成了一个版本的工件，其中包含了经过精简的JavaScript，并且可能去除了调试信息（尽管可以避免这样做会更好）……但这是因为两个工件是等效的。 精简了JavaScript的网络应用程序应该和未精简的网络应用程序一样运作（除非精简会引入错误）
  • 您使用概要文件来构建完全不同的工件。 这很糟糕，因为Maven不会将活动配置文件存储为部署到Maven存储库的信息的一部分。 因此，当您声明对其中一个工件的依赖性时，您不知道在构建该工件时哪个配置文件处于活动状态。 这样做的常见副作用是最终会产生裂脑工件，其中复合工件的一部分正在与开发数据库对话，而另一部分则在与生产数据库对话。 当开发人员由于过去曾经被裂脑构件烧掉而想要切换到生产版本时，通常会告诉他们这种不好的代码味道，因为他们通常运行mvn clean install -Pprod && mvn clean install -Pprod 。 这是不良设计的征兆，不是Maven的问题（除了能够创建特定于体系结构的Maven工件的构造会更好，但是它们可以引起自己的问题）
  • 处理针对不同部署环境的不同工件的“ Maven方法”是使用单独的模块重新打包“通用”工件。 正如Maven处理不良体系结构的微妙方法的典型做法一样，您将需要为要定位的每个环境添加重新打包模块...这会阻止拥有许多不同的目标环境...（即，如果要使用10个Web应用程序/服务部署和三个目标部署环境，您将拥有10个通用模块和3x10个目标特定模块...（提供40个模块构建），并希望鼓励您找到一种方法，使工件在部署时能够自动发现其正确配置。

• 我怀疑破解解决方案的最安全方法是依靠复制存档的工件。

  1. 在主构建期间，创建一个文件，该文件将签出与正在构建的版本相同的版本，例如

      echo '#!/usr/bin/env sh' > checkout.sh echo "svn revert . -R" >> checkout.sh echo "svn update --force -r ${SVN_REVISION}" >> checkout.sh 

     尽管您可能想编写一些更健壮的内容，例如，确保您在SVN工作副本中，确保工作副本使用了正确的远程URI，删除了不需要的任何文件，等等。

  2. 确保您创建的脚本已存档。

  3. 在升级过程的开始添加，将存档的checkout.sh复制到工作区，然后运行该脚本。 您应该能够像以前一样执行所有后续升级步骤。

• 更好的解决方案是为每个升级过程创建构建作业，并将SVN修订版作为构建参数传递（但是将需要更多工作来为您设置（因为您已经设置了升级过程））

• 最好的解决方案是修复您的体系结构，以便生成可以从其目标环境中发现其正确配置的工件，因此您可以将相同的工件部署到每个所需的环境中，而无需完全重建工件。