0

我们的项目是多模块 Maven 项目。该项目依赖于另一个多模块 maven 项目。poms 的关系（聚合和继承）就像

parent-super-pom
|---parent-module-1
|---parent-module-2
|---parent-module-3
|---...
|---parent-module-n
|---child-super-pom
    |---child-module-1
    |---child-module-2
    |---child-module-3
    |---child-module-4

项目中的所有parent内容都由一个单独的团队管理，我们称之为framework. 项目中的所有child内容都由我们的团队管理，我们称之为product.

现在framework已升级为spring-boot与许多其他重大更改一起使用。我们需要开始开发以升级product以使用framework最新的技术。这个升级过程大约需要一个月的时间（有很多无法编译的提交），因为需要注意很多更改才能使应用程序正常工作。同时，product也将在旧的 Maven 环境中自行开发功能。处理这种情况的最佳方法是什么？

我们使用 Gerrit 代码审查。更改首先推送到 gerrit，有自动 jenkins 作业触发器来运行基本测试。只有在构建通过时才能提交更改。还有一些构建可以通过 gerrit 注释基于一些触发器来要求，例如运行耗时的 web 测试、集成测试等。

我的想法

通过在以下上下文中强制推送，我的意思是它必须绕过 gerrit 即直接推送到分支，而不是重新创建 git 历史记录的实际强制推送

  • 为升级创建一个功能分支product，比如说feature/upgrade
  • 确保为此分支设置了临时 CI 作业 wrt 新环境，包括按需作业
  • 将升级所需的更改推送到此分支，直到应用程序可以正常运行
  • master不时重新启动分支以避免在升级结束时发生批量冲突（需要 force-push on feature/upgrade）
  • 最后，将所有更改从feature/upgradeto推送到master（需要强制推送master），现在在 master 上配置 CI 作业以开始使用类似于新创建的临时作业中的配置

这个想法的缺陷是强制推动。我们确保分支机构被锁定以防止此类推送，因为它使分支机构容易出错，并且组织中只有少数人可以进行此类提交。可能是我不知道我可以在这里利用的一些 gerrit 功能，或者我的想法完全错误。我需要知道处理这种情况的最佳方法是什么。

4

1 回答 1

0

为什么不设置监视 gerrit 事件的小进程，如果提交被推送，refs/for/$your_feature_branch那么它会自动将Verified标志设置为 +1。您甚至可以等待 JenkinsVerified在该分支上设置为任何值，然后根据该事件Verified再次设置为 +1。这样，您就可以保证能够独立于在 Jenkins 中失败的构建合并您的提交。

于 2017-12-18T17:01:48.707 回答