WHITE PAPER

DEVOPS FOR LEGACY SYSTEMS –

THE DEMAND OF THE CHANGING
APPLICATIONS LANDSCAPE

Abstract
The pace of business is getting faster as game-changers like
digitization, cloud computing and big data take over the business
world. Enterprises are looking to deploy new features rapidly,
resulting in frequent application releases as opposed to the earlier
one-time release scenario. To support these frequent releases,
businesses need agility and continuous delivery. The DevOps (a
blend of ‘development and ‘operations’) approach introduces a
collaborative working style in the development and operations
teams, leading to rapid and continuous delivery. However, while
implementing this methodology for legacy systems, businesses can
encounter various challenges. In this paper we outline some of the
technical issues in adopting the DevOps methodology for legacy
systems and ways to achieve continuous delivery and successfully
handle frequent releases.
 With the advent of the web-scale DevOps methodology offers and developers start afresh and have the
IT model, increasing competition opportunity to take into consideration
is driving businesses to introduce
a solution
the requirements of CD. For instance, the
differentiating features at a rapid DevOps (a blend of ‘development’ and developers can write code that is easy to
pace. Multivariate testing provides ‘operations’) is a practice that encourages unit test, testers can incrementally build
the ability to quickly test different
collaboration between the development automated test packs, and architects can
variations of a feature with actual
end-users, and choose the one and operations teams. Breaking the design the application in a host-agnostic
that the customer likes the best. barriers provides the teams with a holistic manner. On the other hand, in case of
Consequently, the time taken for a view of processes and constraints involved legacy systems, which have evolved over a
feature to be implemented – from in the workflow of both the teams. The period of time without any consideration
ideation to production deployment approach provides an understanding that of automation, the adoption of the
– is shrinking fast. This has resulted
helps design applications for rapid delivery. DevOps approach may result in large-scale
in more frequent application releases
and the change has drastically The core tenet of the DevOps practice refactoring or redesign. It may prove to be
impacted the dynamics of the is Continuous Delivery (CD). CD is a set a significant challenge to automate the
development lifecycle. vast amount of legacy code and processes.
of processes that allows automated
deployment and verification of an
The traditional approach where application across a set of environments.
a development team develops a
DevOps roadmap for
Automation not only reduces manual
feature and then passes it on to a continuous delivery
errors but also allows for quick, reliable
separate operations team may not
and repeatable deployment of rapidly A typical DevOps roadmap involves
address the needs of the frequent-
release scenario. The delays involved developed code. building a CD pipeline with the supporting
in acknowledging, testing and capabilities (shown in Figure 1 below). Let
When teams adopt the DevOps
deploying the application in the us discuss the challenges at each stage in
methodology for a greenfield project, they
traditional manner increase the time the light of a legacy system project and
to market of the feature. may find it easier to enable CD than for a
look at a few suggestions to overcome
legacy system project. While designing and
these.
developing a greenfield project, architects

Build Automation and Source Monitoring

Quality Management Test Automation Automation

Infrastructure Automation

Deployment Automation

Build
Static code
analysis
Unit
test System Integration Performance
SCM Production
test test test

Development
team

Continuous Integration Continuous Testing Continuous Monitoring

Fig 1: The DevOps roadmap

The adoption of the DevOps methodology and CD in a legacy system project involves three key aspects:

Standardization Automation Shifting left

External Document © 2018 Infosys Limited

Standardization accelerates the processes by eliminating issues much earlier in the lifecycle. This can
manual involvement and makes them give the development team ample time
Standardization here refers to identifying
repeatable (so that a process can be to work on the issues and takes away the
the small variations in processes that have
configured to activate at regular intervals pressure of fixing these in a hurry before
entered the legacy system over time, and
or on-demand) and reliable (with better the release. This can prevent the team from
modifying the systems and/or processes
alerting and monitoring via the scheduling deferring such issues to the next release.
to remove these variations. For instance,
tool). Ensuring standardization before The process of ‘shifting left’ also reduces
only one parameterized build script,
automation is important since the process the cost of fixing bugs since it is more cost-
deployment script and test script must
of standardization reduces the number effective to fix a bug in development than
be used for a particular application type
of processes to be automated and in production.
(web application, web service, etc.). This
maintained. Automating a disorganized The use of the same deployment scripts
script can be reused for any new or existing
process can in fact increase the effort across environments all the way through
application by modifying the parameters.
required to maintain the various flavors of production ensures that the deployment
At a higher level of abstraction, the
scripts. scripts have been thoroughly tested
infrastructure necessary for the systems
and bugs have been addressed in lower
must also be standardized. For example,
Shifting Left environments. Enabling a standardized and
standard scripts must be used to create a
automated process for build, deployment
web server, application server or database Identifying processes that can be
and testing helps shift left.
server. performed earlier in the development
lifecycle rather than at a later point in time
Automation is referred to as ‘shifting left’. For instance,
instead of running a regression test or
Once the processes are standardized, they
performance test after the development
are ready to be automated. Automation
and system test, a subset of the regression
involves the use of tools to configure and
suite or performance test suite can be
trigger various scripts. It removes errors
run during system test in order to catch
introduced by manual intervention and
integration problems and performance

Build Automation and Source Monitoring

Quality Management Test Automation Automation

Infrastructure Automation

Deployment Automation

Build
Static code Integration
analysis test
Unit
test System
SCM Production
test

Development
team Performance
test

Shift Left

Continuous Integration Continuous Testing Continuous Monitoring

Fig 2: ‘Shifting left’ – a key aspect of DevOps for legacy systems

External Document © 2018 Infosys Limited

 Infrastructure automation example, adding a new file server role on
all application server instances is as simple
Infrastructure automation is the process of
Successfully adopting identifying the infrastructure requirements
as modifying the base script for application
server and running the tool to update the
DevOps for legacy of the various systems, and creating an
existing instances.
systems automated way of provisioning these
Let us look at some infrastructure needs. While infrastructure
automation may seem like an optional Continuous integration and build
suggestions to address
step, for a true CD pipeline, the team must automation
the challenges of DevOps
for legacy systems. implement this step to achieve the benefits Continuous integration (CI) is the process
These are ways specific to of complete automation. of periodically (mostly on every check-in to
the various stages involved Infrastructure automation also promotes the source control) checking out code from
in a typical CD pipeline. efficient use of available hardware or the source control system and building
cloud-based machines. The team can spin it on a clean development environment
up a system test environment only when (typically the build server). In addition to
it is needed, and spin it down when it is compiling the source code, CI also runs
not needed, allowing some other system static code analysis tools, unit tests and
to use the infrastructure. In a cloud-based measures the code coverage. This ensures
model, this can even translate into direct that the changes being checked in by
cost savings. It allows speedy recovery in various members in a team are compatible
case of a disaster. The team can spin up and that the code works as a whole.
new machines in an alternate data center Mostly, in legacy systems CI processes are
in case of a disaster in the main data center. not followed at all, and even when they
Manual infrastructure provisioning takes are followed, they are ad-hoc. There are
longer and involves the risk of affecting legacy systems that do not use version
day-to-day business operations by control, or use ancient version control
increasing the mean time to recovery of systems not amenable to CI. Branching
the failed systems. is another area where legacy systems
One of the key challenges of an enterprise are deficient, and the choice of a version
with legacy systems is identifying the control system has a direct bearing on the
current infrastructure landscape. Often, branching strategy adopted. Since the
each system has its own hardware system often evolves over time, there may
requirements and is provisioned manually not be a known configuration for the build
on a need basis. A web server, for instance, server or a standard way of compiling the
could be a Windows 2003 Server with IIS sources. Non-standard build processes and
6.0, 4GB RAM and 4 cores for one system branching strategies hinder the adoption
and Windows 2008 Server R2 with IIS 7.5, of CI.
8GB RAM and 4 cores for another. Instead of trying to introduce CI into a
For legacy systems, it is always legacy system in one step, it is helpful
recommended to standardize the to slowly introduce components of CI.
infrastructure requirements into categories, For example, as a first step, the source
such as web server, application server code can be moved to a modern version
and database server with small, medium control system. SVN5 and Git6, for
and large instances, based on capacity. instance, are FOSS central and distributed
These standardized infrastructure needs version control systems respectively that
can then be scripted and automated provide good compatibility with other
using tools like Chef , Puppet , Ansible ,
1 2 3 development tools. Simultaneously, the
or Salt . In addition to provisioning, these
4 minimum requirements for the build server
tools also facilitate maintenance. For (compiler version, tools and OS version)

External Document © 2015 Infosys Limited

External Document © 2018 Infosys Limited

can be identified. Then a standardized maintaining the baseline or improving it. parameters such as business criticality and
build management tool such as MSBuild7 It could be mandated that all new code risk of failure and automating the top-
for .NET or Maven for Java can be adopted.
8
written must have unit tests and whenever priority ones first. This risk-based test suite
Once a version control system, build server a bug fix or feature is implemented in can serve as the regression test suite that
and the necessary tools are in place, there legacy code, unit tests are written for the is always run to verify the build. This way
are many build automation tools (both legacy code. the existing functionality is not broken
commercial and open source – Bamboo , 9
due to the changes made in this release.
By following the Boy Scout rule “Leave
Build Master10, Jenkins11 and TFS Build12) When defects are identified, test cases
it better than you found it”13, over time
that can be used to set up automated should be written for these scenarios and
the legacy code can be re-factored and
builds. added to the regression test suite. When
brought up to the current standards
new features are added, test cases for
providing long-term benefits in readability
these should be scripted and included in
Source code quality management and maintainability of the code.
the regression test suite based on business
Project Quality Metrics (or PQMs) are criticality and risk of failure.
metrics that help identify the overall Test automation
Over time, the addition of risk-based and
quality of the source code. Some of the key
Test automation is the process of change-based test cases to the automated
PQMs are Lines of Code, Code Coverage,
automating the execution of tests, regression test suite covers the most critical
Complexity, Comments, Package Tangle
publishing the results and measuring the business scenarios. Running such a suite
Index and Dependency Matrix. Measuring
code coverage. Running test cases helps strengthens the confidence of the business
and following these metrics helps track the
in verifying the behavior of the code about the functional quality of the code.
trends in source code quality. For instance,
and measuring code coverage helps in
an increasing trend in Lines of Code and
determining the source code that needs
a decreasing trend in Code Coverage Deployment automation
additional testing, which means functional
indicate that the code is being checked
scenarios that are not being tested Deployment automation is the process of
in without unit tests. This also allows the
currently. identifying and automating the movement
team to identify potential areas of concern.
of code to the environment where it is
For example, a piece of code with no code Legacy systems tend to have low code
intended to be executed. This also involves
coverage is a high risk since it has a high coverage due to few or no unit tests.
automating the setup of the environment
probability of failing in unanticipated ways. Testing is typically done in higher
itself such as website setup, Secure Sockets
environments and is manual. As more
Typically, legacy systems have little or no Layer (SSL) configuration, etc. The ultimate
features are added to a legacy system, the
unit tests, causing the code to be extremely goal of deployment automation is to make
manual testing effort increases drastically,
fragile. In such cases changes made to one the release a non-event, as opposed to a
eventually slowing down feature delivery.
component can cause bugs in an unrelated huge, all hands procedure that needs the
This problem is amplified when there are
component. Evolving coding standards entire system to be offline for the period of
multiple teams working on the same code
and neglect (following the rule of the deployment.
base.
thumb: “don’t fix it if it ain’t broke”) cause
Most legacy systems do not have a
the code to accumulate a large number of Big-bang test automation for any non-
standardized deployment process, and
static code rule violations. Compromises trivial business application is an extremely
practice the ‘done-coding,-now throw-
made during the design process – either difficult and time-consuming task since
it-over-the-wall-to-another-team-for-
due to lack of time or of technical maturity such a system would entail hundreds
deployment’ approach. Often, the various
– add to the overall poor quality. This or thousands of use cases. Moreover,
environments that the code needs to
technical debt causes resistance when no system is static. There are bound to
be deployed in through its lifecycle are
PQM measurements are introduced in be additions of new features and bug
inconsistently set up, due to which every
legacy systems. fixes, further increasing the scope of test
environment needs a specific deployment
automation.
One way to measure and track PQMs in procedure. Attempts to automate such
legacy systems is to start with a baseline Test automation can be adopted in disparate processes often result in a
number for the metrics and then ensure a legacy system by working with the disorderly system that is impossible to
that any new code added or legacy business team to identify the core test maintain.
code re-factored contributes to either scenarios, prioritizing these by using

External Document © 2018 Infosys Limited

 Deployment automation can be gradually and resolution of disruptions, rather than dashboard. Off-the-shelf systems are also
adopted in legacy systems by following reactive or passive issue detection. It available for monitoring system health.
a step-by-step approach of consolidating involves monitoring system health (server’s These include SCOM17 for Microsoft servers
the application inventory, standardizing CPU, memory, disk usage, etc.) as well as and Nagios for other platforms.
the deployment process by application application health – for instance, ensuring
Application Performance Monitoring (APM)
type and then automating the deployment that the website is up and responding to
is another key component of monitoring
process. It is important to reuse the same user requests within the specified SLA.
that allows insight into the actual
deployment script across environments
Automated monitoring provides a close performance of the system in production.
and application types by ‘parameterizing’
feedback loop with the development team, Off-the-shelf systems such as New Relic18,
the deployment script. A web application
ensuring that the team is able to address dynaTrace19, and AppDynamics20 are
deployment script, for instance, should be
the common cases of system failure and available to help measure and track end-
able to deploy any web application as long
reduce the mean time to recovery. to-end performance metrics.
as the package source and destination web
server(s) are specified as parameters. Legacy systems typically undergo very
little or no monitoring. Issues are detected
In order to prevent outages during
due to customer or end-user complaints.
deployment, feature toggles or active-
passive deployment can be used. Feature
The process of troubleshooting of the Conclusion
reported issues is time-consuming as there
toggles14 allow a newly added feature to
are insufficient logs to pinpoint the root While we looked at technical
be turned on or off using a configuration
cause. In cases where logging is a practice, challenges in detail, the
switch. A feature could be deployed to
miscalculated logging configuration causes successful adoption of the
production using a one-server-at-a-time
too many or too few logs. Too many logs
approach with the toggle turned off. DevOps methodology for
make it difficult to find the useful ones for
The toggle is turned on only when the a legacy system is possible
resolving issues.
deployment is complete to all servers only if the teams working on
and the feature is verified as ‘ready for IT teams can enable legacy systems to
legacy systems also change
production’. Active-passive deployment adopt automated application monitoring
their processes and mindset
involves segregating the servers into sets. by working with the business team to
identify critical business exceptions which towards Agile and CD. Often,
A load balancer can control whether traffic
impact end-users. Once such exceptions these teams are accustomed
is routed to a particular set of servers or to
both the sets. The feature can be deployed are identified and automated, alerting to developing features for an
during a non-peak time on one set of can be set up using tools such as Nagios , 15
extended period of time without
servers which are not servicing requests, Truesight16, etc. The alerting mechanism deployment into any production-
and then brought into rotation. The same should be concise, timely and targeted
like environment. Their detailing
process is repeated on the second set at the right group. For instance, an alert
of formal release notes and
of servers. This overlapped deployment “Order submission errors – 50 errors in the
last 30 minutes” could be sent to the order handovers to operations teams
process prevents a complete outage during
management development team, when finally result in one-time difficult
deployment.
such errors occur. Periodically analyzing and complicated deployment.
Infrastructure automation is a key step
the application logs can help identify gaps Having a CD pipeline capable
that helps achieve complete deployment
such as missing logs for a particular use of deploying features into
automation since it enables the elimination
case or too much logging for another,
of environmental inconsistencies. production daily or hourly
allowing the development team to address
is effective only if feature
these gaps on an ongoing basis.
development is quick and if the
Monitoring automation System health monitoring can be
operations team is capable of
Monitoring is a key process that ensures performed by using the features provided
accepting frequent updates from
that systems are functioning correctly and by the underlying platform such as perf
counters on Windows and collecting and the delivery team.
business continuity is intact. Automated
monitoring allows proactive detection aggregating the metrics exposed in a

External Document © 2018 Infosys Limited

 About the author
Gangadhar Hari Rao has worked in
large e-commerce transformational
programs for Retail and CPG clients. He
has more than 10 years of experience
which spans across architecture
definition and evaluation, technology
strategy for Continuous Delivery
and DevOps, implementation, and
performance engineering.

References 9. https://www.atlassian.com/software/ 16. http://www.bmc.com/it-solutions/

bamboo truesight-operations-management.
1. https://www.getchef.com/chef/
10. http://inedo.com/buildmaster html
2. http://puppetlabs.com/
11. http://jenkins-ci.org/ 17. http://www.microsoft.com/en-in/
3. http://www.ansible.com/home server-cloud/products/system-center-
12. http://msdn.microsoft.com/en-us/
4. http://www.saltstack.com/ 2012-r2/
library/ms181710(v=vs.90).aspx
5. https://subversion.apache.org/ 18. http://newrelic.com/
13. http://programmer.97things.oreilly.
6. http://git-scm.com/ com/wiki/index.php/The_Boy_Scout_ 19. http://www.compuware.com/
Rule en_us/application-performance-
7. http://msdn.microsoft.com/en-us/ management.html
library/wea2sca5(v=vs.90).aspx 14. http://martinfowler.com/bliki/
FeatureToggle.html 20. http://www.appdynamics.com/
8. http://maven.apache.org/what-is- solutions/application-performance-
maven.html 15. http://www.nagios.org/
management/

External Document © 2018 Infosys Limited

For more information, contact [email protected]

© 2018 Infosys Limited, Bengaluru, India. All Rights Reserved. Infosys believes the information in this document is accurate as of its publication date; such information is subject to change without notice. Infosys
acknowledges the proprietary rights of other companies to the trademarks, product names and such other intellectual property rights mentioned in this document. Except as expressly permitted, neither this
documentation nor any part of it may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, printing, photocopying, recording or otherwise, without the
prior permission of Infosys Limited and/ or any named intellectual property rights holders under this document.

Infosys.com | NYSE: INFY Stay Connected