java - 在 Jenkins 上为多个环境构建工件并将它们上传到 S3

Question

环境:

大约十几种服务:WAR 和 JAR(使用 Tanuki 包装器运行)

每个服务都被部署到开发、暂存和生产:环境使用不同的 web.xml 文件、Spring 配置文件(在 Tanuki 包装器上设置)、...

我们希望将工件存储在 AWS S3 上，以便我们的 EC2 实例可以轻松获取它们:一些服务在多台机器上运行，AutoScaling 实例在启动后自动获取最新版本，开发工件在更新后应自动部署。 ..

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

Jenkins 构建并测试我们的代码

一旦我们感到满意，我们就会发布 Artifactory plugin (仅用于生产部署；开发和暂存工件基于普通的 Jenkins 构建)

我们使用 Promoted Builds plugin为每个项目(开发、暂存、生产)提供 3 个不同的推广工作，为所需环境构建工件，然后将其上传到 S3

这大部分工作正常，但是我们遇到了多个烦恼:

由于无法提交到存储库，Artifactory 插件无法标记和更新源代码(这可能特定于 CloudBees，我们的 Jenkins 提供商)。没关系 - 我们可以手动做到这一点。

Jenkins S3 plugin不能正确处理多个上传目标(我们为每个环境使用一个) - 它会尝试上传到所有目标并在您保存配置时复制设置:JENKINS-18563 .没关系 - 我们正在使用 shell 脚本进行上传，它工作正常。

升级作业有时会失败，因为它们可以在与原始构建不同的实例上运行 - 导致失败(构建因为文件丢失)或过时构建(因为正在使用旧版本)。同样，这可能是由于 CloudBees 提供的特定设置而发生的。这可以通过再次运行构建来解决，并希望这次提升作业在与其构建相同的实例上运行(这在我的理解中纯粹是运气)。

CloudBees 建议我们在运行升级作业之前进行代码检查，因为工作区是短暂的，并且不能保证它存在或它是最新的。但是，如另一个 StackOverflow thread 中所述，晋升工作中的 shell 脚本似乎不尊重环境变量。 ，即使它们链接在 textarea 字段下方。所以 svn checkout ${SVN_URL} -r ${SVN_REVISION}不起作用。

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

感谢您的任何指点并阅读所有内容到最后!

Answer 1

您面临的最大问题是您实际上希望将构建作为促销的一部分。提升的构建插件旨在执行一些小操作，主要是在构建的存档工件上，或者执行标记或其他此类操作。

该设计确保它在从站上获得工作空间。但是(这是 Jenkins 的一般事情，而不是 CloudBees 特定的)首先，您获得的工作区不必是用于您尝试推广的构建的工作区。它可能是:

一个空的工作区

项目最新构建的工作区(可能比您尝试推广的构建更新)

项目较旧版本的工作区(当您无法进入具有项目最新版本的从站时)

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

因此，您在促销 Activity 中采取的行动应该是“自给自足的”。例如，他们会将存档的工件复制到特定目录中，然后使用这些复制的工件来做他们的“事情”。或者它们将触发下游构建，传递来自被提升的构建的参数。或者他们将在不使用任何本地状态的情况下在远程服务器上执行某些操作(即在蓝绿部署中翻转开关)

就您而言，您是在多条战线上作战。您正在战斗的第二条战线是您正在与 Maven 战斗。

当构建配置文件处于 Activity 状态时，Maven 不喜欢它产生不同的、非等效的工件。

Maven 可能可以忍受 release profile 生成了一个带有 JavaScript 缩小版本的工件，并且可能会删除调试信息(尽管如果可以避免它会更好)……但那是因为这两个工件是等效的。一个带有 JavaScript 压缩的 web 应用应该和没有被压缩的一样好(除非压缩引入了错误)

您可以使用配置文件来构建完全不同的工件。这很糟糕，因为 Maven 不会将 Activity 配置文件存储为部署到 Maven 存储库的信息的一部分。因此，当您声明对其中一个工件的依赖时，您不知道构建该工件时哪个配置文件处于 Activity 状态。这样做的一个常见副作用是，您最终会得到裂脑工件，其中复合工件的一部分与开发 DB 对话，另一部分与生产 DB 对话。当开发人员经常运行 mvn clean install -Pprod && mvn clean install -Pprod 时，您可以看出这种糟糕的代码味道。当他们想切换到构建生产版本时，因为他们过去曾被裂脑工件烧毁。这是糟糕设计的症状，而不是 Maven 的问题(除了能够创建特定于架构的 Maven 工件构建……但它们可以提出自己的问题)

处理为不同部署环境创建不同工件的“Maven 方式”是使用单独的模块重新打包“通用”工件。正如 Maven 处理不良架构的微妙方法的典型特征一样，您需要为每个要定位的环境添加重新打包模块......这不鼓励拥有大量不同的目标环境......(即如果你有 10部署和三个目标部署环境，您将拥有 10 个通用模块和 3x10 目标特定模块......提供 40 个模块构建)并希望鼓励您找到一种方法，让工件在部署时自我发现其正确配置。

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

在主构建期间，创建一个文件，该文件将 check out 与正在构建的相同修订版，例如

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

虽然你可能想写一些更健壮的东西，例如确保您在 SVN 工作副本中，确保工作副本使用正确的远程 URI，删除任何不需要的文件等

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

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

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

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