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).

How forked are these services going to get? Are we talking completely different product paths, one application modularized into subsystems, or "pretty much exactly the same just with some different config files"?
–
ChristopherAug 7 '12 at 3:18

one application split up to separate pieces that talk to each other.
–
jhsuAug 7 '12 at 13:15

2 Answers
2

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.

You would want each of your services' repos to have submodule that points to your messages or contracts repo. This repo would enforce an additive only model. This means that you once a message or contract has been published it cannot be erased. You can simply just add a new version of the massage and stop using the old one. This allows you to have incremental roll-outs.