web-services - SOA Web 服务 - 如何在 Git 上管理个人服务开发

Question

作为更大的 SOA 计划的一部分，我们在 Oracle Service Bus 上开发了许多 Web 服务。目前这些都是在 SVN 上管理的。 SVN 允许我们管理单个服务的版本控制，因为它允许我们在单个文件夹级别创建标签和分支。以下是我们遵循的典型结构，

+- Services
   |
   +- Service1
   |   |
   |   +- tags
   |   |
   |   +- branch1
   |   |
   |   +- trunk
   |       |
   |       +- artefacts
   |
   +- Service2
   |   |
   |   +- tags
   |   |
   |   +- branch1
   |   |
   |   +- trunk
   |       |
   |       +- artefacts
   |
   +- service N

Git 绝对不允许在文件夹级别进行版本控制。我们有 150 多个 web 服务，每个服务都可以有自己的开发周期，并且可以构建为可部署的。我们当前策略到 Git 的直接映射是将每个服务作为一个 git 存储库，并遵循 git 的原则，但这使我们拥有超过 150 个 git 存储库。

这种做法对吗？有没有更好的方法？有人在开发大量网络服务方面有类似的用例吗？

我们还考虑过创建某种逻辑分组并为该组创建 git 存储库，但我认为这是一个错误的策略，因为这会使我对单个服务的版本控制和标记变得困惑。在 git 中还有其他方法可以管理这种分组吗？

Answer 1

子模块和 repo 管理

如果需要，您可以将它们与子模块分组 - 递归地。 ProGit book很好地解释了这一点。您可以使用 gitolite 轻松管理大量 repo 协议(protocol)- 详细到用户有权访问的 repo 协议(protocol)以及该 repo 协议(protocol)中的哪些分支。

每个特征的分支

关于标准 SVN 分支策略的一个很好的替代方案，谷歌搜索“Branch per Feature”，您应该会看到 my article关于这个确切的主题。我们提出该策略的部分原因是要处理大量存储库。

因为您使用的是 Oracle，我应该为每个人指出一个显而易见的事实:不要按数据库集成。如果您是，请停止阅读这里。我为你的灵魂祈祷。

---

建筑粘合剂

根据 SOA，我会指定一个存储库来保存您的契约(Contract)或版本化消息 - 版本化意味着您支持同一消息的多个版本(通常是 3:当前的、已弃用的和特定的异常 - 所有之前的都应该引发未处理的异常)所以在处理客户端-服务器和发布-订阅关系时，您可以推出新版本的横向扩展服务并在零停机部署期间支持新旧客户端。此存储库是所有具有集成端点的存储库的子模块。

Hook

添加 hook到此存储库以仅允许转发包含 OCP (Open Close Principle) 的更改在建筑层面上。您根本不允许对已发布的类进行任何更新。一旦发布，您必须支持它。 Gitolite 使远程管理 Hook 变得非常容易。它本身使用它们来透明地添加它的功能。

合约迁移

要补充的是，事件溯源状态使得消息版本迁移(除其他外)变得更加容易。这是 CQRS(命令查询责任分离)的一个子集。 Even Microsoft is doing it我很幸运能参与其中。相关的是来自 DDD (Domain Driven Design) 的上下文映射和反腐败层在管理存在于服务外部的消息与服务内部使用的消息时。可以在 Ubiquitous Language(也来自 DDD)和 Domain Specific Language(参见 Martin Fowler 的文章 here)下找到关于此的更多指南。

实现

考虑 0MQ (ZeroMQ)用于交付以避免其他“消息总线”想法的潜在大量技术足迹。这确实把持续排队的责任放在了你的肩上—— push 了一个更强大的整体战略。有关如何完成的线索，请参阅上一段。考虑 Service Stack如果在 Windows 环境中遇到 WCF。技术中的魔法/自动生成代码越少，您在困难的冲突解决方案、部署、测试等方面遇到的问题就越少。