In Part 1 of this blog series, I explored what legacy software is, and in Part 2, I discussed how to use tests to provide a layer of safety.

In this part, I'm going to talk about how continuous delivery can help you avoid surprises by getting a hard task out of the way early.

Werthers Original Moment

Many years ago, when I first started working in the industry, web development was still in it's infancy. The software being delivered was a collection of files and folders that were manually copied onto a folder on the server and that was it. Any proper code that ran was interpreted in the file and displayed to the user. We would work on a copy of the folder then copy and paste the changed files to the server and the website was updated. There wasn't even source control in the first few places I worked.

This all seemed fine at the time, but then someone wanted to make a change to a file I was working on - so they copied their file and then I'd copy mine to live and of course all the changes were overwritten - the customers must have had no idea why features appeared and disappeared at random across the site!

Then there's the classic drag and drop of the wrong folder, where all your spacer.gif files ended up in the jpegs folder. All affecting the one live instance you had of course!

Thankfully, we've moved on

I still occasionally see this happen with some of the legacy code I've worked with recently and as much as customers are keen for new features, safety is the key aspect once again, and that process I've described above is quite the opposite of that.

First stop - source control

First up, we need a single source of truth for the source code of our application. If you're reading this, you probably know what source control like Git is, but if that's not familiar to you, then I should probably explain what source control is. It's a method of managing the files in a software project in such a way that every revision is checked in or out. That way we can know every change, who did it, and when. There's also tools to deal with conflicts.

I was working with a project recently where each client of the software had a fresh copy of the code cut from the last client. This meant there were over 100 copies of the code base, and of course each client wanted some changes. We had to go through a long process of merging changes and adding feature toggles and configuration changes to ensure we could have a single code base.

Modernise

Now that you have one source of truth, I'd suggest looking at upgrading your platform where you can. If this isn't feasible or would be a breaking change, then this could be something to do later, but you should now have a safety net of tests so you should be comfortable upgrading now.

The main reason for doing this is that the tools available for continuous delivery right now will be aimed the most modern version of your platform, and this will make the process smoother in the long run.

Continuous Delivery

Delivery is the process by which we take the source code, compile, run tests and other quality processes against it and then deploy it to where it needs to go. The Continuous part comes in when this process is part of a workflow where something triggers that delivery.

Using our source control, we can detect when a developer has committed code and then automatically deploy to the test or development environments without any interruption to the service.

This is a massive step forward, the main reason being that cutting the feedback loop from a developer making changes to those changes being tested improves your team's flow massively.

In the case of our legacy software, it means the safety net can be acted upon quickly if an issue is found.

Conclusion

Our legacy project feels a lot safer now - we have tests, a single source of truth for the source code, we've modernised the platform and now when we make a change, we can test it within a very short space of time and fix any issues that come up.

In the next part of this series, I'll talk about how we record these issues, find more automatically, fix them and make sure your software is fit for the user.