如何用微服务管理持续交付？
How to manage continuous delivery with micro services?
现在我们正在使用 Jenkins 作为我们的 CI 和 CD，我们也在使用敏捷方法（sprint）。我想知道如何管理我的软件版本。
例如，我们正在为企业开发购物网站。开发包含一个应用程序，该应用程序使用 3 个微服务。
组件：
应用：是用户界面
微服务一：销售
微服务2：用户
微服务3：产品
购物网站的初始状态：
我们从头开始开发购物网站。正如我之前所说，我们正在使用敏捷方法论 (Sprint)。
冲刺 1：
- 开发产品微服务。
- 开发用户微服务。
Sprint 1 结束
此时我只能进行微服务测试，如单元测试、契约测试等。因为我没有准备好应用程序，所以无法基于整个应用程序进行端到端测试或功能测试系统，我也无法部署到 UAT 环境（向用户展示测试版），因为用户将无法进行探索性测试。所以现在我需要等到应用和销售微服务完成，这样我才能向用户展示测试版并应用任何其他类型的测试。
冲刺 2：
- 开发销售微服务。
- 开发应用程序。
Sprint 2 结束
现在完成用户要求所需的所有组件都已完成，我们可以继续管道。在我们向用户展示测试版之前应用所有需要的测试。
所以百万美元的问题是，你将如何使用 Jenkins 和 GitLab 来完成这个场景？
我理解微服务应该独立于系统中的每个组件，但最终整个系统相互依赖，例如如果我添加一个新的微服务"shipping"，这个新的功能应该在应用程序界面中看到，所以这意味着在发布新系统之前我依赖于 "shipping" 微服务和应用程序界面，因为没有这两个开发我无法在部署到生产之前完全测试用户需求.
P.S。对于此 post 中的任何混淆，我深表歉意，但我对这个主题完全陌生。
微服务的 "independent" 方面在这里至关重要。基本上，您应该能够将每个服务视为一个独立的应用程序，并且您的 UI 不应像 "libs" 那样依赖 sales/users/products 服务（例如 C# DLL、Java Jars、等），但应该使用某种 API（例如 REST API）来互相调用。
为了说明区别，你不应该有这个：
但是你应该有这样的东西。
现在假设您在 UI 和每个服务之间使用 REST API 的精彩微服务世界。
在 Jenkins 中，它变得相当简单。对于每个服务（+ 主应用程序），您需要一个 在目标服务器上编译、测试和部署您的服务 的作业。
只要您的服务是独立的，并且如果您正确处理应用程序版本控制，您就不需要在任何 Jenkins 作业之间进行任何类型的同步。
当然，build/test/deploy 流程将在一个公共管道文件中外部化，因此您可以在不同的作业中重复使用它。在提交使用新销售端点的 UI 部分之前，只需在销售服务上提交一个新的 API 端点...但我认为这只是常识！
如果您是 Jenkins 的新手，一个好的开始是 pipeline documentation !
现在我们正在使用 Jenkins 作为我们的 CI 和 CD，我们也在使用敏捷方法（sprint）。我想知道如何管理我的软件版本。
例如，我们正在为企业开发购物网站。开发包含一个应用程序，该应用程序使用 3 个微服务。
组件：
应用：是用户界面
微服务一：销售
微服务2：用户
微服务3：产品
购物网站的初始状态：
我们从头开始开发购物网站。正如我之前所说，我们正在使用敏捷方法论 (Sprint)。
冲刺 1：
- 开发产品微服务。
- 开发用户微服务。
Sprint 1 结束
此时我只能进行微服务测试，如单元测试、契约测试等。因为我没有准备好应用程序，所以无法基于整个应用程序进行端到端测试或功能测试系统，我也无法部署到 UAT 环境（向用户展示测试版），因为用户将无法进行探索性测试。所以现在我需要等到应用和销售微服务完成，这样我才能向用户展示测试版并应用任何其他类型的测试。
冲刺 2：
- 开发销售微服务。
- 开发应用程序。
Sprint 2 结束
现在完成用户要求所需的所有组件都已完成，我们可以继续管道。在我们向用户展示测试版之前应用所有需要的测试。
所以百万美元的问题是，你将如何使用 Jenkins 和 GitLab 来完成这个场景？
我理解微服务应该独立于系统中的每个组件，但最终整个系统相互依赖，例如如果我添加一个新的微服务"shipping"，这个新的功能应该在应用程序界面中看到，所以这意味着在发布新系统之前我依赖于 "shipping" 微服务和应用程序界面，因为没有这两个开发我无法在部署到生产之前完全测试用户需求.
P.S。对于此 post 中的任何混淆，我深表歉意，但我对这个主题完全陌生。
微服务的 "independent" 方面在这里至关重要。基本上，您应该能够将每个服务视为一个独立的应用程序，并且您的 UI 不应像 "libs" 那样依赖 sales/users/products 服务（例如 C# DLL、Java Jars、等），但应该使用某种 API（例如 REST API）来互相调用。
为了说明区别，你不应该有这个：
但是你应该有这样的东西。
现在假设您在 UI 和每个服务之间使用 REST API 的精彩微服务世界。
在 Jenkins 中，它变得相当简单。对于每个服务（+ 主应用程序），您需要一个 在目标服务器上编译、测试和部署您的服务 的作业。
只要您的服务是独立的，并且如果您正确处理应用程序版本控制，您就不需要在任何 Jenkins 作业之间进行任何类型的同步。
当然，build/test/deploy 流程将在一个公共管道文件中外部化，因此您可以在不同的作业中重复使用它。在提交使用新销售端点的 UI 部分之前，只需在销售服务上提交一个新的 API 端点...但我认为这只是常识！
如果您是 Jenkins 的新手，一个好的开始是 pipeline documentation !