Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Four Steps From Legacy to DevOps

DZone's Guide to

Four Steps From Legacy to DevOps

The first step is to identify legacy code by determining which systems have been running the business since inception.

· DevOps Zone ·
Free Resource

Is the concept of adopting a continuous everything model a daunting task for your fast moving business? Read this whitepaper to break down and understand one of the key pillars of this model in Continuous Governance: The Guardrails for Continuous Everything.

In his April 12 piece in the Register, Michael Coté addresses the challenge of transforming ‘legacy’ (pre-DevOps) software and services into workable infrastructure in the DevOps era. Coté explains how addressing the ‘technical debts’ of dated code segments and systems enables businesses stand to develop “more resilient, more productive” software. Here’s Coté’s how-to:

The first step is to identify legacy code by determining which systems have been running the business since inception. Experimentation with changes at this core level will naturally seem risky, since these models are least subject to testing or critical review. Next, making use of portfolio analysis, quarantine lowest-value and virtualize dormant applications. What remains is an isolated set of base applications for DevOps adaptation. Concentrate on these applications, and adapt strategically by means of forklifting, strangling, re-writing, or ignoring:

  1. Forklift: adapt directly to a DevOps-driven, continuous delivery approach; looks the easiest but has the worst long-term payoff
     For legacy applications that are “written to be… self-contained and [independent of] vendor-proprietary services or… network file shares.”
  2. Strangle: introduce a new layer of abstraction – an API or set thereof – that fronts the legacy services, eventually replacing capabilities in the legacy system with new code that’s more aligned with your new approach to software development
     For new applications that must use legacy software and services
  3. Rewrite: revise dated code for use with DevOps approach; most time intensive and if done slapdash, risk-laden choice, if done properly achieves frequent change benefits of continuous delivery
     For interdependent legacy applications
  4. Ignore: right answer is often to carefully do nothing and instead to focus on your net-new software without letting your legacy software and processes drag you down.

Are you looking for greater insight into your software development value stream? Check out this whitepaper: DevOps Performance: The Importance of Measuring Throughput and Stability to see how CloudBees DevOptics can give you the visibility to improve your continuous delivery process.

Topics:
legacy ,solutions ,services ,engineering ,code segments ,defense ,portfolio ,infrastructure

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}