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 withv10.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 withv9.6
- QA validates it and deploy it to production
release-v10
(preferably automatically) merges changes fromrelease-v9
;- We tag the release
v10.2
- QA validates it and deploy it to production
Related subjects
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).