package and version strategies in a multi repository environment

Question

We are a small-ish firm with multiple teams who manage their own git repositories. This is a web platform and each team's artifacts are deployed at the end of the day for nightly tests. We are trying to formalise the process around versioning and packaging.

Every team has a master branch where they do day-to-day development. Quality assurance members of each team want the artifacts from their team's changes deployed into a test bed where all the components are combined by chef. Artifacts are tarballs but I would like to convert them into RPMs so we can think and reason about versions correctly.

The release process involves cutting off a release branch from the development branch (master in most cases) of each the git repositories. This is then given to quality assurance who run tests and sign-off on a set of artifacts.

For eg this is a typical git repository with its associated release branches:

 0-0-0-0-0-0-0-0-0-0 (master)
   |           |
   0           0
 (rel-1)       |
               0
            (rel-2)

I am stuck trying to figure out a scheme to perform versioning of packages coming from development branches. We don't want to excessively tag the master branch of each repo and restrict tags to release branches only. But we should be able to query the deployed packages in the test machines using standard yum/rpm semantics. What would development versions look like when the master branch has no tags? I understand that git describe can provide me a useful representation of a build version but that works well when various release points on the branch are tagged.

EDIT1: In response to @Urban48's answer

I figured I should explain our release process a little more. For purposes of this discussion let's assume we have branch master in all repositories. The master branch is considered the development branch and is deployed to an automated CI-CD enabled QA environment. This is where a subset of nightly tests run to ensure the stability of master. We look at this pipeline of jobs before cutting a release branch. Our release branches are short lived. Say, after cutting a release branch (from a stable master), a full regression is run, fixes are made and deployed to production. This takes about a week to do. We release almost every two weeks to production.

Our feature branches are always cut from master and undergo some amount of developer testing before merging with master upon which they undergo the CI-CD stability checks.

Hotfixes are made on hotfix branches (cut from release branches) and deployed with minimal impact testing into production.

Our versioning strategy for release and hotfix branches follows semver. Release branches during the QA cycle go through versions like v2.0.0-rc1, v2.0.0-rc2 and finally after QA sign-off become v2.0.0.

We sometimes do dotted releases for small features which are merged to release branches (and then to master) where the versions become v2.1.0. And hotfixes assume the v2.1.1 pattern.

The question however, is not about versioning these branches. I would prefer not to change this versioning scheme altogether. The only change comes about for development branch ie. master. How can I indicate reliably in the CI-CD environment which version exists wrt the previous release into production. This would ideally be done through smart git tagging but something that does not excessively tag the master branch is preferred.

Answer 1

Hmm, well I have a .net example which might be technology agnostic.

I'll just do a quick summary.

• git repo per component with gitflow branching strategy

• all commits to develop trigger a team city build

• teamcity build amends the version with manual major minor + the build number in AssemblyInfo.cs ie 1.1.hotfix.build

• teamcity triggers nuget packaging using the same version number for nuget published libraries

• octopus deploys finished build to qa for manual testing (assuming all tests pass)

• if everything is good, manually deploy version to production via octopus.

Now this does mean you get A LOT of versioned packages floating about. We did experiment with use of the -prerelease flag but this required a further manual move package from prelease to 'normal' step and a requirement to rebuild components which depended on them.

The key thing is to version every build uniquely via some central process.

Then you are in the situation of 'hmm what versions do i want' rather than 'omg, what version have i got??'

Edit: re comments.

Just to underline that key thing really. Decide what branch constitutes completed software and version ALL commits to it. only deploy versioned software from this branch.

My view though is that you need to address your branching strategy.

• don't version feature (or any dev) branches.
• do version master
• only use packages from master

Answer 2

Let me offer alternative workflow, that may solve your versioning problem, or just help you think of more ways towards the solution.

A bit of philosophy first..
(I'm making few assumptions about your workflow, please correct me if I'm wrong)

1. Tests are run retroactively:

   Branch out of maser to feature branch, then turn it into an artifact for testing by QA.
   the problem is: what if the tests fail, then master may be broken!

   side effects:

   • It make the developers not trust master

   • Since you branch out from master to release branches, what happens if previous release is broken? it stops your new feature integration until master is fixed again.

   • when bug is fixed in the release branch, merge back to master may create merge conflicts. (and we don't like conflicts)

2. small code merges and fixes:

   Its hard to keep track of all code that is merged to master, like small fixes or changes that are not part of a certain feature.

   side effects:

   • developer is not sure if he should marge this small fix now or later.

   • should i version this new small fix as well?

   • At any point of time its not clear what is the state of master branch, and what code is floating in there

   • something broke the build, that is not part of the new feature. and its really hard to track where it came from

My idea for git work flow is as follows:

branch out of master for new feature development like you do already. but now instead of releasing from this newly created branch, have this feature cherry-picked and merged into the release branch.

Now you have better control over what is going into a certain release.
Now its really easy to isolate development versions and stable versions.

You can keep on building artifacts from those feature branches for QA.
If everything is ok, merge that feature back to master, and cherry-pick this feature/bug-fix/hot-fix into the release branch.

versioning
The feature branches version can use some name convention like 1.2.3-rc.12345

the the versions in the release branch will only use 1.2.3 (1.2.3 > 1.2.3-rc.12345 also one less thing to worry about)

This workflow fixes the problems mentioned above, and more.
It also propose sane versioning strategy, and most of this release cycle can be automated.

I hope it will help you in some way, i'll gladly discuss any edge cases you can come up with.

p.s:
I apologize for my English, its not my main language.

Answer 3

Your process seems very convoluted and getting a bit number of tags seems unavoidable.

Two ideas come to mind:

1. You treat the "master" branch as what we typically have into the "develop" branch. This pollutes the message branch a lot.

2. When the QA finish with their job you can have the build/CI server to create a report (eg. A text file) with the tags of all the repos in use. Now you will have a file with the versions which can be posted to the repo. Then you tag the branch with the release version only and if you want to check the versions of they individual components you can check the report.