Podcast: CI and CD for legacy applications
How do you define Legacy? What are some of the best practices to bring DevOps practices to legacy applications – where should you start? This week, I appeared in a panel discussion on CI and CD for legacy applications, as part of Continuous Discussions (#c9d9), a series of community panels about Agile, Continuous Delivery and DevOps.
Continuous Discussions is a community initiative by Electric Cloud, which powers Continuous Delivery at businesses like SpaceX, Cisco, GE and ETRADE by automating their build, test and deployment processes.
The expert panelists included: Myself, Deepak Karanth, Jean D’Amore, Consultant at ThoughtWorks; Manuel Pais, DevOps Lead Editor at InfoQ and consultant at Skelton-Thatcher; Tarun Arora, Microsoft MVP in Visual Studio Development Tools; and, as always, Sam Fell and Anders Wallgren of Electric Cloud.
In this episode, we covered legacy systems in depth – from definitions and addressing challenges, to the best practices for refactoring legacy code and DevOps-ifying your legacy applications.
How do you deal with all your pre-DevOps applications?
Should you embark on a journey to ‘DevOps’ify your legacy applications? If so, how can you bring legacy code and technical debt into the fold – as part of your CD pipelines?
On the show, we discussed:
- How do you define Legacy?
- Should you poke that bear?
- What are some of the challenges doing CI and CD for legacy applications?
- What are some of the best practices to bring DevOps practices to legacy applications- where should you start, and how to go about it?
What resonated during the live podcast was the importance of culture and teams, and first making sure refactoring code is going to drive business value, before going all-in. Continue reading below for some of the top insights that were shared during the event.
Watch the discussion here!
The highlights of the discussion is provided in the transcripts below.
How do you define Legacy?
Karanth says “You know you have legacy code when “you look at [it], you feel like throwing it away.” In other words, it’s code which you do not want to change, or are afraid to change, because there’s no way to know if it will cause side effects in other parts of the system.”
In D’Amore’s opinion, anything that is developed without DevOps and CD in mind is automatically legacy. He goes on to advise against letting code go dormant. “For example, you may have created something great six months ago, but if you have not touched it since and the mindset of changing and improving isn’t there, it is legacy.”
Fell furthers by saying there is an “inertia” factor: if you sit still for too long, it becomes harder to move forward. “Always be thinking about how you can make your product more efficient, even if you aren’t touching the code frequently.”
For Pais, legacy is an evolving definition, but is mainly applications that you cannot change at the speed your business needs them to change. Ipso facto, “If you don’t have processes in place to move quickly, you are working in a legacy app.”
“When dealing in legacy applications, it’s not the end-state, it’s the path,” says Arora. “Legacy begins with the fear of change.” He notes how management often respects stability in business applications, resulting in an increase fear of modifying. “If you can’t change on-demand,” he says, “you are on the path to legacy.”
“The core of legacy is fragility: you think or know it will break every time you touch it,” explains Wallgren. “This creates a positive feedback loop where you learn to stop touching the code entirely.” However, he says you need a little “TLC” in your code base so it doesn’t go to waste.** **
Should you poke that bear?
Arora says “To take a business-case driven approach here. Go through your enterprise, take stock of applications, the turnaround time on them, and ask what value do they deliver to your organization? If they aren’t delivering enough value it may not be worth it to poke the bear.”
Pais puts his focus of refactoring around teams and people. “It’s more important to start with awareness that a team has become legacy, rather than the code or application itself. Legacy teams working in older processes don’t allow systems in those teams to evolve as quickly as they need.” Pais’ advice? “Make it a priority to enable teams to work better and stay on par with the more advanced teams in terms of tooling, processes and collaboration.”
“Do you have the ability to rewrite the legacy code? Is there a part of the application that is less risky to replace? Is the system fit for the purpose?” These are all questions D’Amore would ask before considering refactoring legacy code. “If there’s an investment at the organizational level that says the system is right for us and we want to keep investing in it, then poke the bear.”
Advice per Karanth, “Don’t poke the bear just for the sake of it. It’s important to have a clear vision for why you need to poke the bear and what the outcome is of the whole process. Two important aspects to consider: 1) internal 2) customer.” Karanth says “You know it’s time to refactor the code when customers start complaining, and when your own developers are having a hard time changing the code.”
The age-old answer Wallgren gives is: “It depends. The practical problem with legacy applications is you have no tests, if you’re lucky there are specifications. The decision to refactor depends on many factors, such as the size of the legacy code base.”
Challenges with CI and CD for legacy applications:
“The biggest challenge in CI for legacy applications is off-the-shelf package apps,” says D’Amore. “Essentially, you are at their mercy.” However, D’Amore says “If you are forced into a package application situation, it should become a decision-making process – ask how is this going to affect my environment, how are we going to be able to make changes in the ecosystem alongside the package app?”
Karanth mentions the challenge of politics when making a technical decision. “For example, when different departments are handling different parts of the delivering process, how do you automate? What happens to the jobs of those people when you do automate? The technical challenges are easy to solve – version control systems, unit tests – the biggest challenge is the people.”
Pais further emphasizes the challenge of changing people and culture in legacy systems. He says, “To evolve your practices, and at same time evolve how people think about those practices. Often, there are one or two people that are really into the process of refactoring and create their own “hero crusade.” This is good, but not if everyone else stays where they were before.”
Arora says an outcome-drive approach is best when implementing CI in legacy systems. “Being able to see where you are getting the biggest bang for your buck is crucial. It’s all about decomposing in a fashion where you can create a façade around it, or identify end-points that you can use to do automation testing to speed up the CI pipeline.”
For Wallgren, the challenge becomes, “who do you throw at this problem? Oftentimes, it becomes the “sustaining engineering” team’s problem, but in actuality you want your best people on this project.” He advises to “Think about the skillsets required to go into an unknown code base, understand it, figure out how to write tests for the part you want to refactor, and/or how to extract the part you want to tear out and write it as a new service.”
Bringing DevOps practices to legacy applications- where do you start?
Karanth emphasizes again that “The starting point should always be the culture; find out if the team has the necessary people to do the job. Management often treats this process as just another development task, which is the wrong approach,” according to Karanth. “Finally, understand that refactoring and building a support environment (both people and tools) takes several months to do.”
“There is no value in doing it, if there is no value in doing it,” says Arora. “There needs to be business value, appetite for change, a roadmap and a vision.”
Advice per Pais: “When you realize it’s worthwhile to refactor, first deal with reality, take things step by step, seize opportunities to change and improve, and change the technical side along with the culture and mentality.” Culture is important, but Pais reminds us to “Have metrics in place to make sure you are going in the right direction.” (ie. deploy frequency, time-to-repair)
D’Amore advises to “Visualize your current state – the latencies, what changes often and what is the hardest to change.”
Wallgren says to “Make sure you invest enough time and resources in understanding the change you are about to make. Try not make too many decisions on scope until you have spent time on investing. You are likely dealing with code that isn’t well-defined in terms of what it’s supposed to do – bite off less than you think you can.”