-1

现在我们正在和Jenkins一起作为我们的CI和CD,我们也在使用敏捷方法(冲刺)。我想知道如何管理我的软件版本。如何使用微服务管理持续交付?

例如,我们正在开发一个商业购物网站。该开发由一个消耗3个微服务的应用程序组成。

组件:

应用:是对用户界面
微服务1:销售
微服务2:用户
微服务3:产品的

初始状态购物网站:

我们从头开始开发购物网站。正如我之前所说的,我们正在使用敏捷方法论(Sprint)。

Sprint 1:
- 开发产品微服务。
- 开发用户微服务。冲刺1


结束到这个时候,我只能应用于微服务的测试,如单元测试,测试的合同,等等。因为我不具备的应用就绪我不能让端到端测试或基于整个系统的功能测试,以及我不能部署到UAT环境(向用户展示测试版),因为用户不能够进行探索性测试。所以现在我需要等到应用程序和销售微服务完成后,才能向用户展示测试版本并应用任何其他类型的测试。

Sprint 2:
- 开发销售微服务。
- 开发应用程序。
冲刺结束2

既然所有组件都需要完成来完成用户需求,我们可以继续使用管道。在向用户展示测试版之前,应用所需的所有测试。

因此,百万美元的问题是,你如何与Jenkins和GitLab做这个场景?

我明白,微服务应该独立于系统中的每个组件,但最终整个系统相互依赖,例如,如果我添加一个新的微服务,如“运输”,这个新功能应该是这意味着在发布新系统之前,我依赖于“运送”微服务和应用程序接口,因为如果没有这两项开发,我就无法在部署到生产之前完全测试用户要求。

P.S.我很抱歉在这篇文章中有任何混淆,但我在这个主题上补充了新的内容。

+0

我不认为你正在使用微服务,“应用程序”将取决于微服务似乎很奇怪。此外,你不清楚你在问什么,你应该编辑你的问题,以更具体地说明你想要做什么,命名你的工作,告诉我们应该先跑哪个工作,等等。 – Pom12

+0

@ Pom12谢谢你的回应,对于缺乏细节抱歉,我只是改变了描述。我希望更好,我会很感激你的帮助,因为你知道我在这个话题上有点迷失。 –

回答

0

微服务的“独立”方面在这里很重要。基本上,您应该能够将每项服务视为独立应用程序,并且您的UI不应该依赖销售/用户/产品服务作为“库”(例如C#DLL,Java Jars等),而应该使用某种API(例如REST API)相互调用。

为了说明这个区别,你不应该有这样的:

enter image description here

但是相反,你应该有这样的事情。

enter image description here

现在让我们假设你在美妙的微服务世界,你的用户界面和各个服务之间的REST API。

在詹金斯,它变得相当简单。对于每项服务(+主应用程序),您需要一份编译,测试并在目标服务器上部署您的服务的作业。

enter image description here

只要你的服务是独立的,如果你处理的应用程序正确versionning,你不应该需要任何你詹金斯的工作之间的任何类型的同步。

当然,构建/测试/部署过程将在一个通用管道文件中进行外部化,以便您可以在不同的作业中重复使用它。在提交使用新销售端点的UI部分之前,只需在销售服务中提交新的API端点......但我认为这只是常识!

如果您是詹金斯新人,一个好的开始是pipeline documentation

+0

非常感谢您的解释。所以为了检查我是否理解,首先提交哪个组件的决定应该由人来完成,詹金斯无法管理这一点。 –

+0

确实。詹金斯只是一个CI工具,它可以自动执行一些操作(构建/测试/部署),但决不能推动您编写代码或构建代码的方式。 – Pom12