将多个 Maven 目标组合到一个事务中（例如部署和站点部署，如果站点部署失败怎么办？）[关闭]答案

【问题标题】：Combining multiple Maven goals into one transaction (e.g. deploy and site-deploy, what if site-deploy fails?) [closed]将多个 Maven 目标组合到一个事务中（例如部署和站点部署，如果站点部署失败怎么办？）[关闭]
【发布时间】：2017-07-07 07:18:50
【问题描述】：

我配置了构建服务器来做

clean javadoc:jar deploy site-deploy

现在如果站点部署失败（因为站点没有构建，或者有人使用了错误的父 pom），构建服务器会显示构建失败，但部署已经应用。

有没有办法以事务方式“组合”部署和站点部署？

或者我应该使用不同的目标/阶段链（例如install 在site-deploy 之前）？

【问题讨论】：

因此，如果它是某种与构建服务器相关的问题，那么您应该使用服务器名称对其进行标记。我想没有一个知道答案的人会这样读。
这只是一个我们从构建服务器 (Quickbuild) 调用的 Maven 命令链，但对于 Jenkins、Bamboo 等来说也是一样的。
我猜，那么你必须编写你的回滚方法并根据maven命令退出代码触发它。
我可能不是第一个想要在一个构建中进行部署和站点部署的人。
下面的bash脚本怎么样？ mvn clean install site-deploy && mvn deploy。尽管在发布工件时出现网络错误，这将失败。

标签： java maven deployment transactions

【解决方案1】：

在这里，我提出了一个使用帮助 bash && 运算符的解决方案

mvn clean javadoc:jar install site-deploy && mvn deploy:deploy-file {PARAM}

这会让你

如果任何目标在install 阶段失败，则构建失败
如果站点部署失败，那么您的工件将不会被推送/部署到您的远程存储库
如果site-deploy 失败，则无需编写任何自定义回滚机制

唯一会失败的情况是当您的deploy 目标失败时，将不会回滚site-deploy。我认为deploy 阶段的失败将非常罕见。

【讨论】：

“部署阶段失败的情况非常罕见” 我们怎么知道？如果deploy 失败并且site-deploy 有效，那该怎么办？这仅解决了事务问题的一个特定示例。
据我了解，deploy 可能由于以下原因而失败（可能更多，但我首先想到的是）1）无法访问远程存储库 2）网络问题 3）网络安全规则（上传大小）。我在上面已经明确提到这是close solution，如果在我的解决方案deploy 中失败，则不会有rollback 或site-deploy。

【解决方案2】：

deploy 和 site-deploy 通常通过 HTTP 完成并可能部署到不同的地方，因此实现事务语义可能是不可能的，您需要将其视为最终的一致性问题。

在 CI 上下文中（您提到您正在使用），如果 site-deploy 失败，您需要：

回滚deploy；
重试site-deploy 目标。

我不熟悉 quickbuild，但使用其他常见的 CI 工具，您可以将任务拆分为单独的作业，以便轻松应用任一解决方案。

由于目标（双关语）似乎是在构建网站时捕获错误，因此可以选择创建一系列作业：

mvn install site 运行定期测试并构建网站；
两个并行运行的作业，如果失败可以重试：
- mvn deploy;
- mvn site-deploy。

这可能或多或少复杂，具体取决于作业之间共享工作空间的方式。

【讨论】：

如果错误不是网络问题，重试站点部署通常没有意义，但由于 pom 或源代码中的问题，站点创建失败。回滚部署也不是一个好主意，因为当您尝试从 Nexus 中删除它时，该工件可能已经被使用/下载。
那么您可能需要的是运行install site 来捕获这些问题的阶段，然后是运行deploy 和site-deploy 的另外两个阶段（可以并行运行并在以下情况下重试）失败）。

【解决方案3】：

我能找到使用 Maven 核心功能的唯一方法是通过发布插件的rollback 目标。然而，这意味着您最好将原始构建命令也更改为使用发布插件，因为文档中的this page 提到了以下内容：

要回滚版本，必须满足以下要求：

您还没有在项目上运行release:clean。这意味着上一个发布命令中的备份文件和发布描述符仍然存在。

但是，这样做似乎很容易，因为 Release 插件的 perform 目标已经默认执行 deploy site-deploy，这正是您正在做的。至于javadoc:jar 目标，可以附加到this FAQ 中提到的发布配置文件中。

如果由于某种原因无法使用发布插件，那么我认为解决此问题的唯一方法是通过构建环境本身。您可以将构建分为两个阶段：

第一阶段运行deploy 目标。
第二阶段运行site-deploy。

如果第二阶段失败，您手动通过执行第一阶段但针对 SCM 中的先前版本（上次成功部署的版本）进行回滚。

【讨论】：

release:clean 仅恢复项目和 SVN 上的更改。它无法将部署恢复到 Nexus（这在 Maven 中可能是不可能的）。您的第二种方法的问题是相同的：部署不能轻易恢复。我知道真正的交易行为可能是不可能的。也许我应该使用install site deploy site-deploy，这样在大多数情况下，构建在部署之前就会失败。
@JFMeier 这很奇怪。我认为当我们执行release:rollback 时，Maven 也应该在远程仓库上回滚。也许有人应该请求这个功能。对于第二种方法，是的，实施起来肯定要困难得多。但就像我提到的，部署恢复可以通过重新部署在 Nexus 上成功部署的最后一个修订来手动完成（它本身不是“恢复”，更多的是在旧 SCM rev 上重新部署）。但这需要将构建分成多个阶段，以便对构建步骤进行细粒度控制（这对 IMO 来说是更好的做法）。