Home/ Questions/Q 8343147
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-09T05:58:12+00:00

We are about to start splitting our web application into multiple services, each being

  • 0

We are about to start splitting our web application into multiple services, each being their own repository. We use git as our scm and I am wondering if anyone has any recommendations for a workflow for our scm (in this case git).

Right now we use a similar workflow to what is shown here: http://nvie.com/posts/a-successful-git-branching-model/.

I would like to move to a simpler model, such as how Github works: http://scottchacon.com/2011/08/31/github-flow.html. Is this feasible for developing SOA?

Curious as to if anyone has an opinion on this. Thanks.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Github flow relates feature branches to a single product, but there is no reason it couldn’t be implemented . Your workflow options depend on how you deploy your application. Consider “MyApp”, which has three component services:

    MyApp
|- ServiceA
|- ServiceB
|- ServiceC

    If you can deploy ServiceA independently of ServiceB and ServiceC, and more importantly deploy all of those independently of code contained by MyApp but which exists in none of the Service* repositories, then just apply Github flow, your preferred workflow, to each repository and team.

    If the services are heavily intertwined, and deploying ServiceA necessarily requires a deploy of ServiceB or more importantly, MyApp represents a significant chunk of scaffolding or routing code that has to advance every time one of the Services* repos do, then you might want something like submodules or subtree. In that model, you’d have one Github flow, and an additional step between #4 and #5, namely collecting submodule (or subtree) updates to the services before deployment. I would avoid repository nesting without subtrees or submodules, unless you (and your team) know git extremely well.

    All of that written, I’d suggest you take a deep look at your motivations for splitting the application at all. There are advantages to it and successful workflows on it, but they come at a cost: It’s more difficult to get a “whole picture” of your history; in certain circumstances it can be harder to debug with tools like git bisect; each new developer has to learn your git infrastructure before he or she can be comfortable working your codebase. These aren’t reasons to abandon your plan, just food for thought.

    • 0