5

I am currently trying to figure out, how to do release management with git flow in a scenario where I have one git repository with about 15 projects in two solutions plus scripts for the database.

Each solution basically contains one project that will result in an executable and more than 10 projects containing base functionality used by both solutions like DAL, SAP access wrapper etc.
Solution one is an application with UI for the users.
Solution two is a Windows service.
The release of the two solutions and the database are not in sync. This means that frequently only one ore two of the three are being released. This results in different version numbers. For example, the UI is released quite frequently, the service is released seldomly. The database somewhere in between. So, the UI could have version 2.1.15, the service 2.1.1 and the database 2.1.5.

Now, what to do with the shared projects? Should they use the version number of the UI or that of the service?
How would I account for the fact that a change in one of the shared projects wouldn't automatically trigger a release of both solutions? This means that at the same time, the production environment contains two different versions of the same projects. This somehow needs to be reflected in the repository.

I am a little bit lost here, any advice, experience etc. would be appreciated.
I am free to structure the repository and code base in any way and I can create additional repositories if that helps.

Daniel Hilgarth
  • 171,043
  • 40
  • 335
  • 443
  • git is not a package management system, but a version control system. Understanding that a VCS should not be used as a distribution tool is the first step to reliable releases. – William Pursell Jan 15 '13 at 13:39
  • @WilliamPursell: I don't see how that answers my question. I don't want to distribute anything with git. – Daniel Hilgarth Jan 15 '13 at 13:49
  • It does not answer your question. It is a comment. – William Pursell Jan 15 '13 at 13:54
  • @WilliamPursell: One that is not related to the question. What are you trying to tell me here? – Daniel Hilgarth Jan 15 '13 at 13:55
  • I'm suggesting that that when the releases in your production environment are out of sync with where you want them, you have a distribution problem. Such a problem is best solved by a package management system, not a version control system. – William Pursell Jan 15 '13 at 13:57
  • 1
    @WilliamPursell: But that is not the case. Please try re-reading the question. If it's still not clear, please tell me and I try to improve it. – Daniel Hilgarth Jan 15 '13 at 13:59

1 Answers1

3

First off, if you have different (even though somewhat dependent) projects, that are different enough for them to have different versions, then by all means put them in different git repositories.

If you have all your products under the same repository you are just being inefficient. For example, if you are working on the UI and another is working on the service and made a small fix to the UI, then when you merge your work with them, you get their change of the service too (which you didn't care for).

From your 15 projects, if some are too tightly related, you could keep them in the same repository (for example the components of the UI).

Now that you have different repositories, you can easily manage separate releases for them and separate version numbers.

One thing you want to be careful with though, is compatibility. For example, your UI with version 2.4.5 may be compatible with the service with version in the range 2.1.7-2.2.9, and likewise, the service with version 2.1.10 may be compatible with UI with version in the range 2.4.3-2.4.8. Each version of your software components should then be able to check the version of the other components for compatibility.

Shahbaz
  • 46,337
  • 19
  • 116
  • 182
  • Thanks for your answer. I want to point out that both products depend on other projects for most of their functionality, e.g. the DAL or the Domain layer. Putting each of these projects in its own repository is not feasible... – Daniel Hilgarth Jan 15 '13 at 11:17
  • @DanielHilgarth, I have no idea what DAL or SAP are, but I'm pretty sure a UI uses the DB and service, but not the other way around. So UI by itself can be a repository. Likewise, the DB and the service, even if they use each other, they are logically separate (and I hope your code reflects that). Think of Gimp for example, it uses gtk, which uses gdk which uses glib. Practically they are never used without the other, but they are put in 4 different repositories. – Shahbaz Jan 15 '13 at 11:38
  • In your question, you clearly have 3 different entities with 3 different versions. To me, that screams 3 different repositories. – Shahbaz Jan 15 '13 at 11:39
  • I can agree that I have one repository for the UI, one for the service and one for the DB. No problem here. But both the service and the UI use the Data Access Layer (DAL) and the [SAP](http://en.wikipedia.org/wiki/SAP_ERP) wrapper which both are defined in their own projects. WHere to put them? How to version them? The UI doesn't use the service at all, they don't know of each other. – Daniel Hilgarth Jan 15 '13 at 11:46
  • I don't know how their implementation looks like, but have you considered using [submodules](http://git-scm.com/book/en/Git-Tools-Submodules)? That is put the DAP and SAP wrapper as separate repositories and include them in both the UI and the service as submodules. This way, you wouldn't be copying code around and you'd still share that code between two repositories (UI and service). Also, since those submodules aren't independent, you don't necessarily need to make them "compilable", as long as when included in other repositories they work. – Shahbaz Jan 15 '13 at 13:08
  • Thanks, that looks promising. I need to check in detail if that makes sense in my scenario. – Daniel Hilgarth Jan 15 '13 at 13:15