1

我们的构建系统非常稳定,由 Maven 和 Nexus 和 Jenkins 的 CI 组成。只要我们在开发(使用 SNAPSHOT),一切都很好,但发布总是需要很长时间。

这就是为什么我想知道你们是如何进行发布的……尤其是在持续部署即将到来的情况下。

我们的构建系统

我们有三个分层的父 POM:

  • 定义插件及其配置的“构建”父级。
  • “外部版本”父级,它定义了外部工件及其版本,以使它们处于控制之下。
  • “内部版本”父级,它定义了我们自己的工件及其版本。

然后我们有通常的实用程序项目,其他基础项目等。它们在开发过程中用作 SNAPSHOT 依赖项。

我们的发布

当发布的时候,项目的首席开发人员在 SCM 中创建一个分支,并切换到 SCM 头上的下一个 SNAPSHOT。

然后,构建团队继续在所有这些分支上工作,以发布 POM 和项目。

基本上,我们必须分层发布,以确保使用发布的组件。这意味着我们首先发布三个父 POM,然后开始自下而上:发布实用程序项目,然后是使用实用程序项目的基础项目,然后是同时使用实用程序和基础项目的其他项目,依此类推。

这是一个我们必须手工完成的过程。据我所知,没有任何工具可以自动执行此操作,对吧?

为了在项目发布后更新“内部版本”POM,使用版本插件(救命稻草!)自动更新该 POM。这意味着:将项目发布到 Nexus,然后确保所有其他正在发布的项目现在都使用该发布版本。

最后,当每个项目都发布并可以在 Nexus 中找到时,我们构建 EAR 以使用这些发布的工件进行部署,并将 EAR 交给操作人员。

总而言之,每次发布都需要大约一天的时间,这似乎浪费了很多时间。此外,我们混合了普通的 Maven、shell 脚本(使用我们的构建实用程序类和 Maven)和 Jenkins 作为 UI(发布插件)。

这就是为什么我要问你:我们可以做的更好更快?你如何发布你的软件?

4

1 回答 1

1

我建议两个选项。首先,考虑将所有东西放在一个 Maven 构建下。如果这些模块总是同时发布,那么单独对它们进行版本控制和跟踪可能不值得。

此外,我们混合了普通的 Maven、shell 脚本

将其置于单个构建下需要您将这些 shell 脚本集成到 Maven 生命周期中。

或者,如果您的构建足够复杂,请考虑在 Maven 之外对其进行自动化。您现在拥有的任何步骤都应该合并到一个 shell 脚本中。

这是一个我们必须手工完成的过程。据我所知,没有任何工具可以自动执行此操作,对吧?

了解您的项目的脚本可以进行适当的检查和versions:set调用。

将所有内容放在一个自动化脚本下可能会将构建时间缩短到不到一天;如果它仍然那么长,那么您可以看到需要加快哪些阶段以实现持续交付。

于 2013-06-10T10:32:43.890 回答