Version Management

I like to think of version management as placing chapters into the story of your codebase. Every time your code changes and is pushed out to production (whether that be an executable, a web application, an API or anything else), you should mark your source control system with a version.

Just to clarify, this doesn’t mean every commit or every feature gets a version, instead every release gets a version. A release may consist of just one commit or feature, but it will likely contain many commits and features.

Very simply, when you deploy your latest code to production you should add a tag to the last commit that was in your release branch in source control (for me, this is Git). I tend to tag commits in develop however I know some people argue that this should be done in master. I think this is entirely up to you, however I like to mark as soon as I can where my version is (e.g. if I tag my version in develop and then another commit gets merged into the stream, I can still pull my release branch from this tag, which I feel just makes things a little easier). You will just need to update your tags if the release branch receives some bugfixes prior to deployment on the latest commit, when tagging develop.

Wherever you decide to tag your version, simply add the tag against the latest commit that will go live. This means that after every release, you should be able to go back to master and view all of the tags and checkout a previous version directly from source control with ease.

How do I version my releases? I suggest using Semantic Versioning, which is quite a simple way of representing the state of your releases. For example, in the software world we are all used to seeing versions such as 1.7.3 or 1.7.3-beta.

This denotes {major}.{minor}.{patch}-{pre-release} (see the full details at semver.org).

I believe that this simplified version numbers, it is fairly standard so that most people know what it means and puts rules in place that means your developers, release managers, DevOps, etc. don’t invent their own versioning system that can lead to inconsistencies. There is nothing worse than a large update (yet not considered major) correctly incrementing the minor version and another, smaller release, incrementing the major version just because whoever made the release felt it was a bigger deal than it really was.

If you’re using Git via command line rather than a GUI, it is very simple to tag commits. If you’re tagging the latest commit you can simply type:

git tag -a <version>

Example:

git tag -a 1.7.3

This will add a tag with an annotation, where the annotation is your version number. It is entirely up to you if you prefer 1.7.3 (or your actual version number) or v1.7.3.

If you’re trying to add versions to a commit that is older than the latest one (say, you forgot to add a tag to your release) then it is as simple as appending the commit to the end of your tagging command:

git tag -a 1.7.3 8ac74d

Where 8ac74d is your actual commit.

Once you’ve created your tag, you will need to push it to the origin which is not done via a normal git push on your branch. It is very similar, but you need to push your tag explicitly.

git push origin 1.7.3

Where 1.7.3 is your actual tag.

You should now see your tag on your remote. Do this for every release and you will build up a history of releases. You can then simply check out by a tag via a Git GUI, such as Source Tree, or you can checkout from the command line in the same way that you checkout a branch:

git checkout -b ver1.7.3 1.7.3

This will checkout a branch named ver1.7.3 against the tag with the name 1.7.3. Only, be careful not to make any changes and check them in as this will change the code for this version.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s