介绍这篇文章是关于CloudBees DevOptics团队使用apachemaven获得连续交付/部署的方法。如果你不喜欢阅读博客文章，我会录制一段关于同一主题的视频：这不是我关于这个主题的第一篇文章，你可能会对这篇文章的一些背景感兴趣：利用Maven和Jenkins管道实现连续交付的新方法持续部署一年：经验教训（也可作为视频提供）我们的DevOptics内部版本编号方案（也可作为视频提供）持续交付/部署如果您像我一样，您可能会对连续交付和连续部署之间的区别以及它们与持续集成的关系感到困惑。目前的惯例给出了以下近似定义：持续集成-每个提交都经过测试持续交付—每个提交都会经过测试，如果成功，则会变成一个可以部署到生产环境中的版本连续部署—每个提交都要经过测试，如果成功，就会变成一个总是部署到生产环境中的版本交付将部署作为一个可选步骤，但理想情况下部署本身也应该是自动化的。注意：我要提到的是，上面的定义失去了持续集成最初思想的一个重要方面，即您不仅要测试提交，还要测试与其他所有最新版本集成的提交。例如，如果您在多个存储库中有多个服务，您会看到有人说他们有持续集成，他们只是孤立地检查每个存储库的提交。为了实现真正的持续集成，您还需要在与所有同级服务的最新提交交互时验证提交Apache Maven发布插件如果你使用ApacheMaven，你很可能已经遇到了Maven发布插件，这与其说是一个插件，不如说是一个用来构建发布插件的工具箱，一个与ApacheMaven项目发布需求和要求相匹配的插件示例。如果您有不同的需求，apachemaven项目希望您创建自己的发布插件，使用Maven release API来完成您的需求。当使用Maven发布插件进行连续交付/部署时，您会遇到四个主要问题：每次发布两次提交[maven release plugin]准备发布…[maven release plugin]为下一次开发迭代做准备pom.xml文件一直被修改，生成历史噪音和合并冲突CI/CD服务器需要忽略[maven release plugin]的提交，以防止永久循环每次构建和测试两次对于大多数人来说，最直接的反应往往是抛出Maven发布插件。这可能是正确的选择，也可能不是正确的选择，这取决于你需要什么释放，但我想避免把孩子和洗澡水一起扔出去尝试解决方案apachemaven发布插件所做的一件事是将下一个版本号存储在pom.xml文件. 版本号本身将每个版本标记为下一个版本开发的快照。换句话说，像1.56.2-SNAPSHOT这样的版本是Maven说"这将作为1.56.2发布，但这不是最终的1.56.2版本"。因为插件将版本存储在pom.xml文件需要每更新一次pom.xml文件两次。首先删除-SNAPSHOT，然后提升版本号并重新添加到-SNAPSHOT中。但是如果我们在发布之后没有真正地更改开发版本，会发生什么呢。没有人说我们不能像这样运行我们的版本：1-快照⇒1.56⇒1-快照或1.x-快照⇒1.56⇒1.x-快照如果我们保持开发版本不变，那么合并冲突将大大减少，因为它与pom.xml文件从发布之前开始，发布后将同样有效。此尝试的解决方案存在问题：它并不能消除每个版本中这两个提交的噪音。差异只是相互抵消。使用git rebase时，合并冲突会重新出现-不是一直都是这样，但它们会很烦人这个pom.xml文件现在有了一个额外的可变性来源，使得使用诸如git-crime这样的工具变得困难我们必须确定每个版本的版本号，因为它不再存储在pom.xml文件解决方案谁说我们必须推送那些[maven release plugin]准备…提交，如果我们只推标签会发生什么？这个pom.xml文件版本保持不变，因为它们是相同的：Maven发布插件提交导致的合并冲突被消除了-因为主分支永远不会看到那些提交标记反映释放有一些潜在的负面影响：根据自动化的方式，您可能需要使用一次性签出来发布可能更难确定某个特性的版本我们必须确定每个版本的版本号，因为它不再存储在pom.xml文件在DevOptics项目存储库中，我们从主服务器上防止这些问题的提交数量中获取版本号。教育学的实施我们的jenkins文件看起来有点像这样（去除了分散注意力的噪音）管道{阶段{阶段（"构建"）{什么时候{不是{branch'master'}}台阶{和马文在一起(maven:env.maven_工具_ID,globalEventSettingsConfig:'maven settings nexus internal'）{sh"mvn验证"}}}阶段（'释放'）{什么时候{分支"主"}环境{RELEASE_VERSION=getReleaseVersion（）}台阶{和马文在一起(maven:env.maven_工具_ID,globalEventSettingsConfig:'maven settings nexus internal'）{sh"mvn发布：准备发布：perform-DreleaseVersion=${RELEASE_VERSION}"}}岗位{成功{sshagent（['github-ssh']）{sh"git push origin devoptics平台父级-${RELEASE_VERSION}"}}}}}}除了主分支之外，所有内容都正常构建主分支始终是一个释放只有在将发布部署到专用集成测试环境时通过集成测试时，我们才会推送标记。使用以下步骤确定发布版本的GetAseVersion（）：计算主分支上的提交数列出Git中的标记列出作业的显示名称选取尚未用作Git标记或作业显示名称的下一个版本号交付与部署我们同时进行持续交付和持续部署对于DevOptics Jenkins插件，我们使用连续交付模型：Jenkinsfile设置构建描述和构建状态，以包括下游测试结果以及Sonatype Nexus Staging repository ID。当我们需要发布一个版本时，我们可以在Jenkins中看到版本状态，并且可以在作业屏幕上直接知道要发布哪个暂存库。对于DevOptics SaaS后端，我们使用连续部署模型：在这里，我们将成功的构建部署到生产环境（针对每个环境进行验证：集成、登台、生产，然后再继续下一个环境）我要说的一个关键点是，您需要为每个代码库使用正确的部署模型。一些代码库更好地针对连续交付样式，而其他代码库则可以一直持续部署。例子：在我们的例子中，Jenkins插件被我们的最终用户所使用，因此我们无法控制他们何时决定升级，因此我们必须接受一系列插件版本与我们的后端对话。此外，我们的一些最终用户有复杂的变更控制流程，监管机构已经强制要求，因此我们不能一直要求他们为每次提交更新插件。这两个因素促使我们决定为DevOptics-Jenkins插件使用持续交付你自己试试吧如果你觉得这个方法很有趣，你可以自己尝试一下。为了简化这一点，我创建了一个Maven插件来辅助，并创建了一个示例Git存储库，其中有一个项目设置，可以使用此技术工作。示例git存储库可从我们的"非官方示例代码"GitHub组织获得……该组织有一个奇怪的类似于CloudBees的logo……尽管可能更多的是关于享受啤酒的例子！GitHub存储库：https://github.com/cloudbeers/maven-continuous如果您想将此示例应用于您自己的项目，下面是必要更改的摘要：将项目版本更改为1.x-SNAPSHOT。4.0.0...……1.x-快照…...这不是绝对必要的，但是我更愿意指出真正的版本将是两个组件，而不是将版本作为1-SNAPSHOT 释放插件：禁用回推原点maven发布插件...truefalse...关键的更改是false这会停止将更改推回原点，但是一旦进行了更改，则在运行发布：执行目标当它试图签出还不存在的远程标记时，因此还需要指定true。 建造一次