注：如需了解更多最新信息，请参阅我2019年3月的后续帖子。像任何构建工具一样，Maven提供了多种方法来完成任务。Maven与其他构建工具的区别之一是Maven固执己见。这意味着Maven将使首选路径成为简单路径你现在需要问自己的最佳路径是什么？我会让你摆脱痛苦。。。答案是否定的。首选的路径就是适合大多数人共同需求的路径。所以，举例来说，当我们看一下Maven如何建议你发布东西时，我们有了Maven发布插件。。。首先，与其说这是一个插件，不如说它是一个用于构建发布插件的工具箱，以及一个与apachemaven项目的需求和需求相匹配的示例插件。如果您有不同的需求，apachemaven项目希望您创建自己的发布插件，使用Maven release API来完成您的需求。下一步，插件本身将构建您的项目两次，运行您的测试两次。。。因为大多数人更喜欢只创建应该构建的标记，而大多数人希望确保标记实际生成。所以第一个构建将验证要发布的代码是否应该构建。第二个构建是从一个干净的签出标记开始的，并验证实际的标记是否是构建发布的依据（例如，不必担心工作区中被.gitignore文件隐藏的文件）现在，当我们看到人们如何尝试应用连续交付时，我们看到很多人没有后退，看到他们没有给Maven提供打破的选择的假设。让我们来看看第一个阻抗不匹配的问题："我们应该部署快照吗？"在连续交付中，每个提交都应该是潜在的可发布的，所以大多数人尝试的想法是使用-快照版本，然后部署它们。。。持续交付的一个重要方面就是不断被遗忘。对于连续交付，每个提交都可能是可发布的。显然，如果提交没有通过测试，我们就不会发布它。但更重要的是，即使发布确实通过了所有测试，我们也可能不会部署提交。例如，即使在全自动的连续部署管道中，后期提交也可能必须在更快的构建代理上运行测试，并赢得部署的竞争。在那些依赖于人工干预的管道中，在真正进入生产的最后一步之前，您可能有许多提交可能是可发布的，但最终不会被释放。所以现在有一个我们需要解决的可追溯性问题。我们怎么知道现在生产的代码是什么？-快照并不能很好地帮助您解决这个问题。不要担心在确保从Maven存储库中实际解决了正确的快照时存在问题。下一个选择是发布一个版本。嗯，那么每次提交都会生成一个版本？好的，这样就解决了可追溯性问题，我们有一个唯一的版本号和一个标签。。。但是，天哪，git的历史现在有了[maven release plugin]prepare release。。。并且[maven release plugin]为下一次开发迭代提交每个普通提交做准备。。。我们必须努力阻止Jenkins在[maven release plugin]准备下一次开发迭代提交后触发构建。。。而且由于pom.xml文件文件夹。。。我们现在把每样东西都造了两次。好吧，那太糟糕了。因此，人们开始与之抗争，要么有一个单独的发布步骤，要么已经远离了"每个提交都应该是潜在的可发布的"的持续交付原则。。。或者他们试图破解发布插件（因为人们似乎喜欢在Maven周围进行黑客攻击，而不是停下来做Maven想让你做的事情。。。编写插件）有一种不同的方式。首先，如果我们在进行连续交付，我们不希望构建任何不止一次的提交。如果提交没有生成，那么它就不会再继续了。如果它建立了，那么我们将尽可能通过测试管道运行它，直到它到达最后。因此，我们真正想做的是为每次提交运行一个发布版本，但是要为无操作做好准备，并且只在发布到任何地方时才推送标签。下面是一个解决这个问题的新方法的草图：在一个独立的头部进行本地结账使用Maven release插件来准备一个pushChanges=false（我们不会把发布提交推回到master）和preparationGoals=initialize（我们不在乎标签是否坏，因为我们只推送好的标签）通过测试管道运行stages版本当您准备好推送到生产环境（或者如果您愿意的话，在准备推送到测试时），您可以推送标记并释放登台存储库这会给你一个干净的主分支没有[maven release plugin]准备。。。承诺。从发布工件到标记源代码的良好跟踪性他们的开发人员没有合并冲突pom.xml文件现在仍然有一些问题需要你去解决，例如你可能会有项目间的依赖，你需要保持更新。。。如果两者都在运行连续交付，那么发布过程就必须找到一些方法来获取这些更新。。。但下面是一个启动程序管道脚本，可用于说明方法：节点{//将代码签出标记为"阶段"。。。。阶段"结帐"//从GitHub存储库获取一些代码git url:"…"//清理所有本地修改的文件，并确保我们实际上在源/主文件上//因为失败的发布可能会使本地工作区先于源站/主服务器sh"git clean-f&&git reset--硬原点/主控形状"def mvnHome=工具"maven-3.3.9"//我们想从pom上找到版本pomendef=pomendav文件pom.xml文件'定义版本=pom.version.replace（"-SNAPSHOT"，"${当前版本号}")//将代码构建标记为"阶段"。。。。阶段"构建"//运行maven构建这是一个保留开发版本的版本//未更改，并使用Jenkins提供版本号的唯一性sh"${mvnHome}/bin/mvn-DreleaseVersion=${version}-DdevelopmentVersion=${pom.版本}-DpushChanges=false-DlocalCheckout=true-dprepartmentgoals=initialize发布：准备发布：执行-B"//现在我们有一个步骤来决定是否应该发布到生产中//（我们在这里只使用一个简单的发布步骤）输入"发布？"阶段"发布"//按下标签（或者我们可以将它们推到单独的//git回购，然后我们从中提取并重新定价。。。后者可以是//在其他节点上运行发布时很有用嘘"吉特推"${伪影}-${version}"//我们还应该发行分期回购，如果我们已经将//登台存储库标识符的详细信息这很容易}了解更多多年来，各组织一直在与詹金斯合作。随着Jenkins和continuous delivery经验的深入，组织希望超越简单的管道，绘制复杂的流程图，以映射到他们特定的软件交付过程。对于Jenkins用户来说，使用Jenkins和Pipeline插件创建和管理复杂的管道变得更加容易。了解它是什么，它为您做了什么，以及如何使用它来设置交付管道。下载您的副本，您将了解如何更快地交付更好的软件。