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

Download the blueprint that can take a company of any maturity level all the way up to enterprise-scale continuous delivery using a combination of Automic Release Automation, Automic’s 20+ years of business automation experience, and the proven tools and practices the company is already leveraging.

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.

Download the ‘Practical Blueprint to Continuous Delivery’ to learn how Automic Release Automation can help you begin or continue your company’s digital transformation.

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

Published at DZone with permission of Yaniv Yehuda, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}