Migrating Legacy Code to CI/CD

Migrating Legacy Code to CI/CD

If you're working in IT, you've probably heard developers, engineers, and project leaders talk about legacy code—or rather complain about it. While the term "legacy" usually has a positive connotation, most developers would consider "legacy code" to be a negative thing, or at least something (annoying) they have to deal with.

But what exactly is legacy code? Is it just old or someone else's code? And does it make sense to migrate it to a continuous deployment workflow?

Here are some suggestions on how to deal with legacy code, how to implement Continuous Integration, Continuous Delivery/Continuous Deployment and how DeployBot can help you along the way.

What is Legacy Code?

First of all, it's code inherited from an older version of the software or even from someone else. In a lot of cases, but not always, that includes code you find difficult to read and understand, and as a result you're probably not too keen on touching it, either. Maybe you don't understand the code, maybe you're afraid to break something that has been working for a long time, or maybe you just follow the rule "never touch a running system".

Unless you're starting from scratch with a brand new software project, you're dealing with legacy code—sometimes only a few months or years old, other codebases have been around a lot longer. But just because the code is old, it doesn't mean it's bad. Admittedly, some older techniques and tools may be involved, but there is usually a (good) reason why someone else has written the code that way.

So, let's not judge, but think about how to improve things—not by adding a quick fix, but by carefully turning legacy code into a modern software project, including a version control system, automated tests, automated builds, and automated deployment.

Why CI/CD is cool

First, let's become more familiar with the terms Continuous Integration, Continuous Delivery, and Continuous Deployment:

  • Continuous Integration (CI): Source code is built and tested on a regular basis, for example daily, several times per day, or better still with every commit.
  • Continuous Delivery (CD): The intention is to always have code available that can be released at any point. CD relies on some automation for building and testing, but usually involves human intervention to release software to a production environment.
  • Continuous Deployment (CD): Everything happens automatically: building, testing, and releasing. In this scenario the new version is deployed to the production environment without human intervention.

So, you've decided you want to migrate some legacy code and you're aiming for continuous integration, delivery, and/or deployment? Then here are some ideas how to achieve this—step by step.

Migrating to a CI/CD pipeline: 6 Steps

Here are some suggestions for you if you’re planning to turn legacy code into a modern software project with a CI/CD workflow:

  1. Set up a Version Control System
  2. Implement Software Tests
  3. Automate Builds
  4. Set up Automatic Deployment
  5. Document your Changes
  6. Enable Monitoring/Error Tracking

1. Set up a Version Control System

If you're aiming for continuous integration, delivery, and/or deployment, you have to manage the source code in a version control system (VCS)—there is no way around it. Changes to the codebase must be handled by the VCS in order for a deployment tool to access it.

DeployBot works with platforms like GitHub, GitLab, or Bitbucket, and with self-hosted Git repositories. You can find an ever growing collection of beginners’ guides on our website:

Learn how to get started with DeployBot here.

2. Implement Software Tests

Most legacy projects don’t include tests, and if there are any, they’re probably outdated anyway. While your long-term goal should be implementing automated tests for your software, you can start with simple unit tests or functional testing. Admittedly, writing tests for legacy code can be a pain, but step by step you’ll get there. A good strategy could be: if you add or change a feature or if you fix a bug, write a test for it. That way, you will include new tests together with the actual code.

A successful CI strategy relies on automated tests, for example, every time you push a new commit. In combination with continuous delivery and deployment, developers can test the code in different environments, add some performance tests, and create other automated processes for every step until production

3. Automate Builds

Trying to get the legacy code to build on your machine or in your environment, is something you’ve hopefully accomplished already—before you started migrating to a CI/CD workflow. On top of that, you should consider build automation, i.e. the process of retrieving the source code and compiling it.

By the way, think of automation as a reminder of the way your code gets built. If you automate the entire process, you can’t forget anything, for example libraries which your project requires...

4. Set up Automatic Deployment

Setting up automated deployments for staging/development environments is a great idea. That way your code gets deployed automatically every time you push a new commit, for example. Of course, in some cases you probably prefer a manual deployment, i.e. when you’re deploying to a production system. 

A tool like DeployBot can be a great asset here: it’s easy to configure both, manual and automatic deployments. Just like with build automation, automatic deployments can help you and your team to remember how a project’s deployment works.  

5. Document your Changes

While you’re at it—consider taking some notes for your fellow developers or the next team to take over your codebase. Maybe the code you’re working on will be legacy code for someone else at some point in future. If the next developer understands the workflow and the tools involved, it should be a lot easier to fill in. 

Of course, taking notes and documenting your workflow is always a good idea, not just when migrating to new tools. Imagine a project which you haven’t touched in a few months. Do you remember all the steps necessary for building the software?  

6. Enable Monitoring/Error Tracking

Instead of infrequently checking the server logs, it's a good idea to set up professional monitoring with automatic alerts. If you're going to continuously deliver or deploy your software, you have to make sure all systems are healthy—and if not, you want to get notified.

DeployBot integrates with monitoring and error tracking solutions like HoneyBadger, Bugsnag, and New Relic—just in case you’re looking for a way to connect our favourite bot to another SaaS solution.

Legacy Code is Inevitable

Every developer has to deal with legacy code—sooner or later. This means she or he should find a way to handle this code, in the best possible way. It doesn't necessarily mean you should migrate the code to a CI/CD workflow. Continually delivering or deploying code might not be right for you, your software project, or even your team. But even then, you should consider automation, at least for tests and the build process.

If, on the other hand, you decide that a CI/CD workflow is a cool approach and works for you, then DeployBot can certainly help you—happy hacking!