已过时的许多存储库的微服务

在微服务架构中，保持许多开发人员环境跨多个源代码存储库最新的最佳策略是什么？已过时的许多存储库的微服务

假设有10个团队的10个开发人员在git中处理200个微服务。每个开发人员都需要定期从每个存储库中取出。这可以用脚本来完成，但有没有更好的方法？我们是否这样做是错误的，因为它似乎是一个沉重的开销。

来源

2015-11-19 LL020

正在每一个微服务每一个开发商？开发人员是不是只关心他们正在开发的微服务和（或许）他们的直接依赖关系？ – Pace

不，他们一次只能工作几个，但需要保持其他一切都是最新的。如果需要的话，任何团队都可能在任何repro上更改代码。通常团队将在一个子集上工作。 – LL020

这里团队和所有权的明确区分是什么？所有10个团队都拥有200个微服务吗？在这种情况下，这听起来更像是一个组织问题。没有所有权，没有开发人员会理解整个服务系统以及他们如何为更大的产品做出贡献。 –

我不会建议让每个开发人员构建每个微服务。我会提出某种持续集成环境。一个集中式构建服务器连接到所有的git回购站。

每次更新回购时，构建服务器都应检测更改，构建代码，运行单元（或功能）测试，然后将服务推送到某种集成环境。然后，构建服务器也可以针对部署的服务运行一些集成测试。

大多数开发人员应该能够在不需要访问其他微服务的情况下进行所有开发和测试。如果开发人员构建服务X，该服务取决于Y & Z并且依赖于A & B，那么开发人员大部分应该只有服务X.对于单元测试服务Y & Z应该被模拟/模拟。

所面临的挑战是要通过更改服务X.那种集成测试的往往是作为服务X往往不知道细节的开发人员棘手可以防止显影剂打破服务的一个& B（或甚至如何使用）上游服务（例如A & B）。

解决这个问题的方法我相信会定期进行集成测试，无论是由服务X构建还是定期运行。通过一个项目，这个复杂的强大而强大的单元测试理念和集成测试框架将变得至关重要。

来源

2015-11-20 03:33:13 Pace

这归结为你的服务位置/检测技术是好的。所有服务需要知道的是在哪里发送请求X以便从特定服务获得响应Y.如果这是很好的实施。你可以非常好地让每个开发人员运行他在本地直接工作的任何子集的服务，并让其他服务在一个通用环境中运行（可以称之为远程）

远程将被配置为运行您的所有服务平台，并将有一些方法来获取最新的代码（基于节奏或基于定期）。可以将本地环境配置为：本地运行的所有服务都将知道本地运行的其他服务，并知道如何在需要任何信息时访问远程服务。对于开发人员环境，添加约定，每个开发人员运行生产开发所需的最少数量的服务。这意味着如果您不是将代码用作服务，请远程运行它，以便您知道您正在运行最新的代码并且不会过期。

这种方法夫妇陷阱的

，你可以在本地运行服务A和具有服务B上远程运行。你在本地测试一切，它似乎在工作，所以你决定推动。当你推动时，另一位开发人员也会将更改推送给B，而现在您的更改不再兼容。
如果您在本地运行服务A和C并且远程运行B，那么将请求发送到服务B到远程环境应该非常直接。但是，您应该小心，如果A呼叫B和B呼叫C，那么对C的呼叫需要从远程环境路由到您的本地C服务，而不是您的远程C服务。
测试 - 您可以通过两个单独的测试套件来解决许多与测试有关的复杂环境相关的问题。 1.单元测试 - 测试服务中的单个组件，并调用其他被嘲笑的服务。 2.环境集成测试 - 这些测试验证不同服务之间的通信。 Suite 1将检查您的服务的内部代码，Suite 2将在您将更改推送到远程后继续运行，并将继续确保服务间通信如预期。

希望帮助

来源

2015-11-20 23:29:30 KnightFox

已过时的许多存储库的微服务

回答

相关问题