continuous integration - CI: One git repository fits it all? Or: gitflow for multiple projects

Question

Until now my team and I do and did not have anything like an automated delivery process in production. Which may sound surprising to some folks, but it simply did not seem to be essential to our daily work. At least we thought so. I am very sure it is something like a car navigation system or an automatic dishwasher - stuff you would die for if you just started using it.

However, as we are planning to launch a not so small project in the next couple of weeks, I want to take care that we are able to not only produce but also deliver updates for it as fast and often as possible. And by often I don't have in mind once a week but multiple times a day.

What I am still uncertain about is the organization of the underlaying git repository/repositories. We currently use a single repository with gitflow as a branching model. The repository contains the following parts:

• API
• CDN
• Website
• iPhone App

Currently we are using tags to mark new releases within the master branch, as we can't say every commit into master results in a new version, because it could be related to the iPhone App or one of the server side applications as well. As you can't just publish a new version of the app to the universe, it will always be asynchronous.

The advantage of having all these applications in one repository is a very simple initial setup for all of us and the guarantee that the iPhone app and the API are working fine together, as long as the developer uses the same branch on both the server (Windows) and the app development environment (Mac) while developing/testing.

However, it doesn't feel right. As written above going that way we are forced to use git tags to distinguish new "builds" for the app and the server applications. And on top we always have to publish all three web applications, even if one only fixes or adds something in one of it.

What we propably could do is to introduce development and master branches for each of these applications. That would allow us to give up using tags (which doesn't scale anyway) and kick off a new delivery process with each commit into one of the master branches.

I fear that would lead directly into chaos, because of at least 8 "base" branches and the countless hotfix and feature branches.

So my preferred option is another one: splitting it up into 5 repositories. One for each of the apps, one for utilities and other stuff not directly related to one of it.

What do you mean would make sense? How are you doing this? How does it work best for you? Thanks for feedback.

Answer 1

The advantage of having all these applications in one repository is a very simple initial setup for all of us and the guarantee that the iPhone app and the API are working fine together.

splitting it up into 5 repositories. One for each of the apps, one for utilities and other stuff not directly related to one of it.

That looks like submodules, and you can still reference said submodules in one unique parent repo in order to facilitate the initial setup.
This is also closer to a component approach (recommended here, see the criteria for switching to one), which allows for the 5 repos to evolve in their own pace, with their own set of branches and tags.