6

作为更大 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中还有其他方法可以管理这种分组吗？

4

1 回答 1

9

子模块和回购管理

您可以将它们与子模块分组 - 如果需要，可以递归。ProGit书很好地解释了这一点。您可以使用gitolite非常轻松地管理大量存储库- 直到用户可以访问哪些存储库以及该存储库中的哪些分支。

每个功能的分支

至于标准 SVN 分支策略的一个很好的替代方案，谷歌“每个功能的分支”，你应该看到我关于这个确切主题的文章。我们提出的策略部分是由于处理了大量的存储库。

因为您使用的是Oracle，所以我应该为大家指出显而易见的：不要通过数据库集成。如果你是，就在这里停止阅读。我为你的灵魂祈祷。

建筑胶

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

挂钩

向此存储库添加一个钩子，以仅允许转发在架构级别体现OCP（打开关闭原则）的更改。您根本不允许对已发布的类进行任何更新。一旦发布，您必须支持它。Gitolite 使得远程管理钩子变得非常容易。它本身使用它们来透明地添加它的功能。

合同迁移

此外，事件溯源状态使消息版本迁移（除其他外）变得更容易。这是 CQRS（命令查询职责分离）的一个子集。甚至微软也在这样做，我很幸运能参与其中。相关的是来自DDD（域驱动设计）的上下文映射和反腐败层，用于管理服务外部存在的消息与服务内部使用的消息。可以在 Ubiquitous Language（也来自 DDD）和 Domain Specific Language（参见 Martin Fowler在此处的文章）下找到有关这方面的更多指南。

执行

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

于 2012-10-12T17:41:07.907 回答