1

我们即将开始将我们的 Web 应用程序拆分为多个服务，每个服务都是它们自己的存储库。我们使用 git 作为我们的 scm，我想知道是否有人对我们的 scm（在本例中为 git）的工作流程有任何建议。

现在我们使用与此处所示类似的工作流程：http: //nvie.com/posts/a-successful-git-branching-model/。

我想转向一个更简单的模型，例如 Github 的工作原理：http ://scottchacon.com/2011/08/31/github-flow.html 。这对于开发 SOA 是否可行？

好奇是否有人对此有意见。谢谢。

4

2 回答 2

1

Github flow将功能分支与单个产品相关联，但没有理由无法实现。您的工作流程选项取决于您部署应用程序的方式。考虑“MyApp”，它具有三个组件服务：

MyApp
|- ServiceA
|- ServiceB
|- ServiceC

如果您可以ServiceA独立于ServiceBand进行部署ServiceC，更重要的是部署所有这些独立于 MyApp 包含但不存在于任何Service*存储库中的代码，那么只需将您首选的工作流 Github 流应用到每个存储库和团队。

如果服务紧密交织在一起，并且部署ServiceA必然需要部署，ServiceB或者更重要的是，MyApp代表每次一个Services*存储库执行时都必须推进的大量脚手架或路由代码，那么您可能需要类似submodules或subtree的东西。在该模型中，您将拥有一个 Github 流程，以及 #4 和 #5 之间的额外步骤，即在部署之前收集服务的子模块（或子树）更新。我会避免没有子树或子模块的存储库嵌套，除非你（和你的团队）非常了解 git。

写完所有这些，我建议您深入了解拆分应用程序的动机。它有其优点和成功的工作流程，但它们是有代价的：获得历史的“全貌”更加困难；在某些情况下，使用以下工具进行调试可能会更加困难git bisect；每个新开发人员都必须先了解您的 git 基础架构，然后才能熟练使用您的代码库。这些不是放弃计划的理由，只是值得深思。

于 2012-08-07T15:22:06.853 回答
0

您会希望每个服务的存储库都有指向您的消息或合同存储库的子模块。这个 repo 将强制执行仅添加模型。这意味着您一旦发布了消息或合同，就无法删除它。您可以简单地添加新版本的按摩并停止使用旧版本。这使您可以进行增量部署。

于 2012-08-07T04:40:33.473 回答