If you own a piece of legacy code, you might be crossing your fingers every time you release a new version. Silently hoping that nothing will go wrong like last time. I’ll tell you it doesn’t have to be that way. The way out of this mess can be long and difficult, but the situation can be improved. Here are some tips.
How can you know that the latest version of your application works as expected? How are you testing the version that you want to deploy? If the answer is that you’re mainly testing manually, then you’re in a bad situation.
Typically, projects that test manually are tested for the new features. Maybe some basic tests are performed for the older features. But as an application grows, it’s impossible to perform all these tests manually. So testing the edge cases is dropped first. Then, features that have always worked.
Yet it is exactly these parts of the application that will fall apart first. Especially if you stop testing them!
This is why you should have automated tests for these features and use cases. There are many different kinds of automated tests. But the important thing to note is that you should be able to test your application by the click of a button. Even legacy projects.
This might not cover every single possible case, but it will give you a lot more confidence. Projects with automated tests are cheaper to test, easier to maintain, and eventually have less bugs in them.
Just like you should automate (most of) your testing, so should you automated deployment. Deployment is a task that is prone to human error. It’s often more complicated than copying files to a server. A whole range of extra tasks might be necessary for a new version to become “live”:
- database updates
- network and firewall changes
- configuration changes
- service restarts
If any of these is forgotten, the application might not work as it should. Automating this reduces the chance of humans forgetting necessary steps, performing steps in the wrong order, or executing steps wrongly.
More And Smaller Releases
Managers of legacy projects with a reputation of being buggy often react by slowing down releases. This of course reduces the number of moments where things can go wrong. But it increases the chances of things going wrong. This is counter-intuitive, so let me explain.
When developers implement a feature, they make changes to the code. It’s possible that these changes break something. Even with automated and manual tests, it’s still possible that a bug goes unnoticed.
Let’s say you release this feature to your customers. The bug surfaces, people aren’t happy, but you provide a fix and all is well.
Now, let’s assume your developers implement 20 new features. You now have a higher probability of having one or more bugs slip through the system. When you release this version, you might end up in a messy situation where a new bug report comes in after each bugfix.
Also, in the first case, it’s probably clear where we should look for the bug: in the code for the new feature. In the second case, we’ve changed so much code, that it’s not always so easy.
Having smaller releases means taking smaller steps towards your goal. So you need to release more often to achieve the goal. But it allows you to reduce the surface area where bugs can occur. Releasing more often also gives you more opportunity for customer feedback. So you will be able to adapt faster too.
If you’re seeing bugs after every release over and over again, release smaller and more often, not larger and less.
If possible, discuss the idea of feature toggles with your developers. Feature toggles warrant a separate post, but in short, they allow you to switch a feature on or off.
Ideally, this also means enabling or disabling new code. If the new feature is too buggy to release, there’s no need for a hasty rollback or bugfix. Just switch the feature off and fix it stress-free.
If you take this a step further, you can even toggle features on or off for certain customers. This way, you could test a new feature on a customer that wants the bleeding edge and is prepared to accept some bugs in the process. Then, only if everything is stable, you can roll it out to more conservative customers.
This does require a different way of developing software and a change in mind-set of (project) managers. But when done right, it provides a powerful way of releasing new versions. It’s also a great solution if you don’t yet know the order in which new features should become active.
Don’t Be Afraid
I’ve outlined four strategies that can improve your confidence when releasing. This should take away the fear you feel when releasing new versions of your product. Being afraid and releasing less isn’t a good option. It will increase the chances of things going wrong, and give your competitors the advantage. Automate as much as possible and reduce the surface area where things can go wrong.