Introduction

The idea here is to give an idea of the goals we should reach in terms of release management and why.

Postulate

We’re using GIT

Anything else sucks.

We’re using an issue tracking tool

Something like JIRA / Trello / Redmine that is connected to our SCM.

We want to be productive

We don’t want to spend any time preparing boring releases. We shall have tools for that.

Version numbers have no meaning

Release number are basically just numbers. What we need from them is to:

  • With the major version, identify a set of features
  • With the minor version, identify a fix

Version numbers are important

They should uniquely identify any built being produced. They should match a precise git hash, be tested by QA and if passing be deployed as is in production.

If a version has a defect, even a minor one, we increase the version number.

Features branch are dope

Features branch are important. They allow the developers to independently  work on their new features.

The branching approach

The dev branch

You have a dev branch where all developers merge their stuff.

Feature and fix branches

Developer work from their. They should name their branch with something that is easy to identify. Something like:

(fix|feature)-${developer_name}-${ticket_name}-${whatever}

Once they have finished their work, the pull-request is passing the automated tests and it has been reviewed by their peer (at least 2 is a good rule), it should be merged to the dev branch.

Site note: Having feature branch doesn’t mean you can’t have feature flags. And having feature flags doesn’t mean you can’t automatically test your code in both scenario.

Release branches

This is the important part. When you are in sprint 10 / iteration 10 / agreed deliverable 10 / work package 10 / set of features 10, you create a branch release-v10 from the dev branch.

After the branch is created the version files should be modified as well (your maven / gradle / npm / go resource file) by referencing the future version in the dev branch. This might seem a bit painful but it gives a better overview of where everyone’s branch is at, and this is especially important when it’s deployed.

Release tags

Release tags are not a big deal. You can create as many as you want, you should do one when you want QA to validate it.

After the tag has been created, the version files of the release branch should be updated to the upcoming tag.

If your dev branch was in a clean state, as soon as you generated your release branch (release-v10) you should tag it (v10.0).

Production branch

…also sometimes referred a the master branch.

We don’t care about that one. You are supposed to know what you have deployed to production.

Still if you want to have one you should merge it to each release branch and from each tag being released to production.

Example

We have to ship a new version of our product.

  • We merge the last things we wanted it to include in the “dev” branch.
  • We create a release-v10 branch
  • We tag it with v10.0 and send it to QA
  • We continue to work on our dev branch for all future features
  • QA discovers bugs
  • We fix our bugs directly in release-v10, we tag it with v10.1
  • QA discover bugs and some of them are also impacting the previous deployed release (the “v9.5”)
  • We fix our bugs in release-v9, we tag it with v9.6
  • QA validates it and deploy it to production
  • release-v10 (preferably automatically) merges changes from release-v9;
  • We tag the release v10.2
  • QA validates it and deploy it to production

Too for cascading changes

Whenever a merge is performed on a release branch, we should cascade it to dev and all the branches above our release branch. Any change made in the release-v9 branch should be cascaded to the release-v10 and dev branches.

Deleting branches

Old release branches should be deleted whenever a more recent version has been put to production. Recreating a release branch from a tag is pretty instantaneous.

Old feature branches should be deleted at your discretion

Build level version identification

You should modify your versions files whenever a branch is created.

Make sure your are in sync

You should use  a git management tool that forces your PR to be in sync with your dev branch.

Build with docker

Use an environment that allows to build with docker. You’ll be able to change everything (JVM version, Linux OS, etc.) in a separate branch.

Create an isolated test environment

Even if it’s not easy, you should make sure everything can run independently. Shared databases are hard to maintain between tests.

Release note generation

Everytime we tag a release, we should create two release notes, each one having:

  • The issue touched since the last tag for QA to focus their effort
  • The issues touched since the last release in production for production / end-users to see what’s new

Fortunately for us, this is fairly easy to do with GIT.

Deployment

Deployment should be made simple

Alternatives

Gitflow

Lots of process for very little benefits, except having very clean version branches (your release / hotfix branch).