管道和版本与快照构建

Question

我想使用jenkins管道进行持续集成，但不是cd，我仍然使用maven的快照和发布模型。如何使管道根据某些条件执行发布构建或快照构建？另外，你如何触发一些事情，比如在其他平台上测试，集成测试，等等？我不希望每次提交都要在windows上执行长时间的测试和耗费大量资源的启动。

Answer 1

欢迎来到不那么微不足道的持续集成世界。当使用在生成服务器上手动触发生成的传统方法时，可以选择是否生成

• 一个快照，用于播放并向同事展示
• 版本，如果通过所有测试，该版本应该会投入生产。

在纯CI中，每个提交都应该是一个可能的释放，因此以上两者之间的区别变得很困难。你可以--我也有人这么做--只有在进行自动提交-触发器-构建构建时才生成快照构建。然后，构建只用于反馈，而不是为了以后使用。这也使得在硬盘出现问题时删除它们变得更容易。在这种情况下，您将手动启动发布构建。

如果你想变得更像CI，你可以把每次提交都看作是潜在的版本，并给出一个版本号。是否运行所有测试由您决定。如果您的测试时间太长，您可以告诉Jenkins，您的自动管道仅运行到"alpha“级别，并且"alpha to beta”管道仍然在必要时手动启动。

有些人会说，你应该总是运行所有的测试并保留所有的版本，而且硬件很便宜，你可以很容易地构建一个集群。这些人可能从未见过大型官僚公司的内部。

Answer 2

我们这样做的一种方法是基于分支名称。我们在git中有发布分支，比如v1.0_release，我们还有integ分支：v1.0_integ。

我们在分支名称上使用when子句设置了一个多分支管道。当分支名称为*_release时，我们将该构建交付到发布工件存储库。其他分支转到快照存储库。

任何时候，任何其他分支被推到git (比如功能分支)，它们也会被构建，根据应用程序的不同，我们通常将这些构建归档到Jenkins中。这为开发人员提供了有关他们使用的任何分支的快速反馈，并可以轻松访问工件。

开发人员可以在他们想要的任何分支中使用任何代码，当他们喜欢这些代码并准备好构建一个发布候选版本时，他们推送到发布分支，Jenkins就会处理它。

Answer 3

我决定的是:我不会区分有没有集成测试的构建。它们会运行很长时间，特别是它们运行在windows和linux上，但不确定我是否有理由用另一种方式来运行，你觉得呢？

至于快照和发布版本之间的区别: maven使用配置文件来对发布或不发布执行特殊操作。但是，当在distributionManagement中决定是部署到快照还是发布存储库时，maven会使用版本号来检查部署到哪里。因为你不能激活基于当前项目版本的概要文件，所以我决定合并它，因为如果你有一个快照版本，你肯定不会发布，如果你的pom有一个发行版本，你就不会构建快照。因此，通过手动将pom设置为发布版本并提交来触发发布，此时ci将读取pom，检查版本是否以"-SNAPSHOT“结束，如果不是，将激活发布配置文件并执行其他仅发布的事情，例如将部署maven站点。