A true software engineer wants to be able to release at any time with any application. An unexpected problem can require a hotfix, so you want to be ready for it. When maintaining more then ten, twenty or maybe even thirty applications, this becomes a problem. What is a good strategy for keeping software releasable? Lets put on our release manager hats.
What is “releasable software”?
The position that you want to be in when releasing an application, is where the only thing that will change is the bugfix that you just did. This is for various reasons:
- You don’t want to be dependant on other people.
- If a problem occurs with this release, you know it’s this bugfix that caused the problem. So it’s clear where to look.
- Should this problem require a rollback (undoing the change), this will not undo the other feature that was released as well. Features enabling and then disabling can cause problems.
- Perhaps the other features still need to be tested, and you have to wait on it.
When you have enough programmers working on a project, the last thing is bound to happen. At a certain point in time I became aware of just how often it was happening. We started to call them traffic jams. When unattended, those traffic jams can become really big really fast. It becomes very hard to release your software once this happens, so how can we prevent these?
Keeping software releasable
Since it’s a problem that is created by many programmers, it should be solved by those programmers themselves. If you create the problem, you’re responsible for solving it. If you’re allowed to make a change to an application, you’re allowed to be a release manager for it. It puts the responsibility where it belongs. This also scales with the programming team. It’s logical for a self organizing, agile team to do it this way.
This really is a story of how a simple, low tech, maybe even childish solution was useful in a software engineering environment.
We made cards for every application. They state the name of the application with their icon, and two words: “Release manager”. When someone makes changes that would be possibly blocking for a hotfix, they receive the card of this application. This gives them the responsibility to release the application, and then put the card back.
So why do these cards work?
- They give a visual reminder that you still have work to do.
- You’re aware that this reminder is also visible for anybody that might be close to your desk.
- From a management perspective: it takes very little time to manage the releases. Basically everybody is promoted to be a release manager.
To make this work these cards have to be recognizable, hence the name and icon. The cards have to be durable, so a colleague of mine had the brilliant idea of laminating the cards. Doing so made them really robust. The cards we made are about the size of a business card.
Have a board that has all cards, so that you can see if one of the cards is missing. After a deployment the cards should be handed in again.
Problems encountered in practice
Just like any solution for any problem, there are some downsides.
- You have to measure the thing you give the cards for. If the cards do not reflect the accurate state, the system starts falling down. One way to do this is a daily e-mail, where the first person that comes into the office hands out the cards.
- Sometimes multiple people have pushed commits that are not released yet, and the card is handed to the wrong person. Just ask them to give it to the right person in that case ;-).
- Cards can get mysteriously lost at peoples desk, it can take some time to find them.
- This probably does not solve all your problems, consider using (a possible subset of?) Git flow.
This works because for a web application a release is very cheap. This might not work for you if it’s physically impossible to release your software often (cd/dvd/blu ray), you’re dependant on a third party (app store, play store) or you’re not in control of all your release environments (wordpress upgrades).
Are there other cool uses for cards like this?
Cards like these can be a good reminder for any common task within the department. It could also be used for ensuring some batch job is running. Or that there is a high prio ticket that needs to be done asap.
Anyway, try them out! They worked for my use case, so why not yours?
The post Keeping software releasable appeared first on nschoenmaker.nl.
