我假设您正在为您的CI / CD使用jenkins管道。因此，无论如何，您必须创建两个jenkins管道，第一个用于构建库，第二个用于构建微服务。

我会做的方式：

1）将代码提交到库

2）触发了库构建并生成了新的工件版本。

3）复制生成的lib工件的版本

4）在服务中更改pom文件并提交。

5）使用新的lib版本构建微服务。

这种方法不是完全自动化的，但是非常简单。由于您很少更改库，因此手动设置lib版本是非常好的。

我将其自动化的方式以及我们需要解决的问题：

• 在构建服务之前运行lib构建。

  我们将为每次对lib git repo的提交触发lib build。因此，您不必再次构建它。

• 获取库触发的生成版本并使用新版本更新微服务pom文件

  在lib构建期间，您可以将lib版本号附加到jenkins构建信息中（例如，构建显示的名称）。然后在微服务构建期间提取此信息。获得编号后，您可以更新pom文件并开始构建。

我看到的唯一一个优点是不需要您手动设置lib版本。它将从lib作业结果中提取。

缺点：

• 复杂的构建

• 无法控制构建版本更新（除非您将创建某种机制来决定是否要保留现有的lib版本->更复杂的构建，否则它将一直拉最新版本，

• 本地版本存在问题，因为GIT中的版本和jar的实际版本是不同的（因为您在jenkins作业中动态更新它，除非您直接从jenkins提交版本更新更改->复杂的版本）。

如果在开发阶段使用SNAPSHOT版本的公共库，则无需为库中的每个更改而用公共库版本继续更新微服务pom。 Maven可以根据时间戳每次从远程存储库中检索最新版本的SNAPSHOT（例如，elem = driver.find_element_by_id("element-id") text = "text to enter" for character in text: elem.send_keys(character) time.sleep(0.2) # pause for 0.2 seconds 命令行选项，或者默认每天一次）。创建发行分支时，请删除SNAPSHOT并使用公共库的发行版本更新微服务pom。

（没有直接回答问题，没有提供指导）

您确实需要将提到的每个组件都视为具有其自身生命周期的独立工件。其中包括共享库。

Maven和Jenkins分别在不同的级别上管理构建过程。两者都可以确保构建过程的完整性和一致性。

在Jenkins中构建共享库，作为maven工件，并带有pom和版本（将smae作为您的微服务）。您可以作为SNAPSHOT进行开发，但是需要将其部署到工件存储库（Artifactory，Nexus 3，or 2 (if just maven)等）中，最终要使用可靠的发行版（{{3} }，而不是SNAPSHOT）。您也可以在管道中完成所有操作，最终目标是发布到工件仓库，而不是PRod。

您的每个微服务都应使用该库的一个已知版本（完整版本＃），就像您使用任何其他第三方库一样。

开发，测试和发布（构建到您的工件存储库）您构建的共享库。然后在微服务中增加显式依赖。

在Jenkins中拥有所有构建版本。您要决定要使用semantic versioning，maven-release-plugin和Nexus 3 webhooks来实现自动化。等

您不太可能在每次发行新共享库时都同时重建和重新部署所有微服务-听起来过于单一。如果您在已部署的工件（尤其是生产环境）中没有共享库的显式版本，则将自己设置为蜘蛛式的网络泥潭，并更新微服务。

您可以设置一个新作业，该作业在释放递增的共享库时触发，为所有使用者准备SNAPSHOT，提高引用依赖性，将其提交给各种git repos，然后触发新的管道执行以构建微服务。这一切都取决于系统的复杂程度和规模，更新和发布的频率以及可供使用的工具和资源。 YMMV。