为Java项目设置暂存流程

Question

我目前有大量具有复杂依赖结构的项目，这些项目是由50+开发人员使用Maven2/3和Nexus和Jenkins开发的。我们的开发速度很快，而且更多的时候，我们并不是在构建和部署带有快照依赖的版本。大多数时候，我们不能等待一个团队或另一个团队在我们必须部署之前构建一个发布版本。由于这一点，我们遇到了许多问题，如进入生产阶段的bug和在制品，并且不知道这些快照中有哪些更改。

我希望做的是消除快照，使用versions-maven-plugin自动发布，并实现发布阶段策略。

这就是问题所在。对于开发人员和CI构建，需要将其配置为解析来自"Staging“和"Release”的依赖关系，并仅发布到"Staging“。然后，我们希望能够将该构建作为一个版本进行“升级”，重新构建它以解决“发布”和“发布”之间的依赖关系(最初这将是一个手动升级，但我们可能也希望将其自动化)。这一切听起来都合理吗？

我不想使用maven-release-plugin，因为我们以前尝试过使用它，我们不喜欢它自动修改pom并在我们的scm中进行更改，从而触发更多的构建。

此外，有没有一种方法可以告诉maven使用一个存储库进行解析，并使用另一个存储库进行发布？我能和gradle一起做这个吗？

任何关于这方面的意见/想法都将不胜感激。

Answer 1

我建议不要使用maven发布插件，也不要使用快照。看一看here以一种快速干净的方式发布。

Answer 2

这听起来很像我的构建系统。

我使用gradle和2个独立的nexus存储库(这两个都是“发布”存储库，1个阶段和1个最终版本)来完成这项工作。构建具有目标成熟度的概念，并使用它来计算版本号(使用语义版本控制)，因此RC构建生成类似1.0.0-rc1的版本，而最终构建生成类似1.0.0的版本。然后，我们以不同的方式标记测试(testng组，黄瓜标记等)，以便测试的不同切片在不同的时间运行。构建基于目标成熟度决定依赖或发布到哪些存储库，因此可以确保只使用足够成熟的工件。

这被配置为通过teamcity构建链自动运行，因此一些核心库中的提交会在下游构建中产生涟漪，并在必要时继续集成测试/部署(通过rundeck通过其java api和一组gradle任务)。

Gradle发布和解析存储库是分开配置的，因此可以有所不同。在maven中也可以做到这一点。

例如，给定一个依赖关系图，例如

corelib -> mylib -> myapp

每一件事都会有一组与之相关的测试，这些测试要么被标记为beta，要么被标记为rc。其意图是，生成RC的构建是通过beta测试的构建(即，如果您通过beta测试，那么您就足够成熟，可以成为RC) &该构建是快速完成的构建(例如，只进行单元测试)，而rc测试(生成最终构建)可能会进行一些集成测试或一些更长时间的运行测试。这是我们自己的定义，完全是任意的，您可以根据自己的喜好进行任何区分。我们的基础是，只有当你对产品有一定的信心时，才会应用越来越严格和/或持续时间更长的测试。

然后，我们设置一个构建链，以便rc构建依赖于上游rc构建，而最终构建依赖于上游最终构建和您自己的rc构建

即

             --> mylib final --
           /                   \
mylib rc --                     --> myapp final
           \                   /
             --> myapp rc -----

诸若此类。在此示例中，流程为

• 提交对mylib的更改
• mylib rc build运行
  • 运行beta测试
  • 将结果发布到rc build

​

mylib最终版本和myapp rc可以在parallel

• mylib final build中运行运行

• 运行rc tests
• publish result to final repository

​

• myapp rc build runs
  • 依赖于rc存储库，因此会获取之前mylib rc build
  • 运行测试版的结果

​

• myapp final runs
  • 依赖于final存储库，因此会获取之前mylib final build的结果
  • 运行rc final

​

每个点的版本号都是通过询问源代码管理来计算的

依赖于我们自己的工件，是动态的(例如，常春藤术语中的1.0.+ )，major.minor是静态设置的(在源代码控制中)，构建留下来自己生成补丁和候选编号，即myapp1.0将依赖于mylib 1.0.+。使用两个单独的存储库作为过滤机制要简单得多，而不必深入gradle/ivy中的解析逻辑来过滤掉我们不想要的。

Answer 3

看看maven-version-plugin，特别是锁定/解锁快照目标。它们可以帮助识别程序集正在使用的依赖项，并且可能足以满足您的需求。

如果没有，是的，maven可以使用staging repositories，但是如果你想存放的东西也放在本地开发人员存储库中，这可能会导致混乱。

我们现在用来解决类似问题的是一个相当于maven-release-plugin的“脚本化”(实际上是调用它来执行某些操作)和一个笨拙的版本控制方案:我们的开发分支保持1.2快照，但我们发布/发布的构建使用不同的版本控制方案(1.2.3，1.2.4)。我们的脚本也标记了git。