Search code examples
versioningrelease-managementgitversion

Versioning Approach In Custom Git Strategy

Overview: Here is the git strategy I have:

  • main branch reflects production
  • developer creates branch from main with feature/jiraTiketNb and implements it there
  • developer can merge any time feature/jiraTiketNb to develop branch and deploy it to lab env
  • develop branch is unstable and can be deleted anytime and recreated from main
  • when feature is ready, the developer creates a release/jiraTiketNb branch from main and do PR from feature/jiraTiketNb
  • after PR and merge to release/jiraTiketNb, program can be deployed to QA env
  • if a bug is found another PR will be created to release/jiraTiketNb and app will be redeployed
  • after QA verify app can be deployed to production from release/jiraTiketNb branch
  • then we merge to main and add tag with version number

Do you know the name of this git strategy? Maybe it already exists.

Purpose: This strategy tries to cover cases when we have many features develop simultaneously and don't know the order of deployment. It's possible that two independent features will be release together or one by one.

For each deployment, we create a docker image with tag that corresponds to version of the app. There should be a possibility to do rollback between each deployments, so version should be unique.

Concerns: Could you suggest possible ways for versioning?

I tried to set up git version to perform versioning for releases branch be like: Major.Minor.Patch-branchName-revisionNm. Example: 1.2.0.-release/jiraTiketNb-2. Not sure it's ok? For QA environment actually, it doesn't matter. But for prod it could look strange. I thought to create another docker image for prod after QA and deploy it to prod with updated version to be like 1.2.0, but it will be not tested docker image, so I'm not sure it's correct.

Solution

  • In this case, the main branch probably reflects the release versions. the release branches sound like RC versions, that could become releases, and would bump a version.

    The develop branch seems like it would be development on top of that version, and the feature branches, further on top of the last time they were cut from develop.

    I would perhaps version like this:

    • Releases: v1.2.0

    • Release candidates: v1.3.0-rc.1 (which could become v1.3.0)

    • Develop: if the v1.3.0-rc series was the last bump, this would be v1.3.0-dev.n where n increments as stuff gets merged into develop branch. Or the last main it was created from.

    • For the feature branches, if there is an associated ticket number then this could have the extended version: v1.2.0- where v1.2.0 was the last main tag this was branched from (or merged up).