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.
rc
suffix? That would dictate themajor.minor
development version.rc
and build number can be obtained based only on that. Alsorc
on master doesn't make sense because we never release from master. We tag our release candidates today on release branches as parts of the release cyclerc
suffix.