How Can DevOps Concepts Provide Value in Digital Transformation Projects?

For some of us, DevOps means startups, cloud, fast-moving social media applications and Extreme Programming (XP). What about large corporate IT initiatives, Digital Transformation projects, and business process re-engineering? Can DevOps be relevant and appropriate? Mohammad Rizvi argues from experience that it most certainly can be.

The word ‘DevOps’ describes the many ways that operations and development experts cooperate in a team to deal with the difficulties that have to be overcome to allow rapid development cycles of Analysis, Design, Coding, Testing, Deployment and Feedback. DevOps achieves many of its results by automating as much as possible of the support for Agile methodology, and by changing development techniques to make deployment quicker and less risky. At its core, DevOps is the automation of agile methodology.1

The main differences from other development methodologies are the emphasis on closer collaboration, higher levels of automation, shorter development cycles and earlier operations feedback. The main objective of this is to respond to business requirements faster than has ever been possible.

Development methodologies have generally focused on development itself, to the neglect of the delivery of the software into Production, and the effective support of the software that is in production.

Where corners were cut in the course of a development project, Testing, Security and IT operational aspects always suffered because the deliverables were harder to quantify. The results of this are well known and extremely costly to put right. If the project happens to be of an IT Transformation type, then skimping on operational aspects will have an obvious widespread impact. The practice of DevOps provides several ways to avoid this sort of mistake.

Background

When the business environment allowed businesses to take a more measured approach to change, they could afford to take a more disciplined approach in software delivery through defined phases of design, development, testing and release – the Waterfall model. In this Waterfall model, there was little or no feedback during the phases of the delivery pipeline until the project went into the User Testing/Acceptance phase.

Agile methodology reduces the development cycle time and improves the feedback by iterative-incremental development. This is done by gathering user feedback at the end of each sprint, and responding to it in the following sprint. This not only provides a way of rapidly making changes but also reduces the cycle time. It also means that user concerns do not build up and become unmanageable.

In Agile methodology, developers write code that is shipped for testing in increments at every 3-4 weeks’ interval. Agile focuses on potentially shippable code at the end of each sprint.

While DevOps and Agile are about faster delivery of finished product, an aspect that was overlooked in Agile before the introduction of DevOps was the important contribution of Operations to the development cycle. DevOps emphasizes the importance of collaboration between Development, QA and Operations teams to make continuous delivery possible. By working together in a team release(s) can even occur every day. This allows the change in functionality to be even more easy to describe, document, test and deploy. It can be managed in production in such a way that new features can be switched in and out or presented to just a subset of users. This allows very rapid feedback and improvement and avoids the risk of flawed software being exposed to end-users for any length of time. DevOps requires that teams communicate rapidly and effectively, whether they are business analysts, system analysts, QA analysts, release or operation teams.

The longer the cycle, the greater the number of changes; this will inevitably lead to a higher risk of failure. As delivery models have moving from Waterfall towards DevOps in response to the fast pace of changes in business dynamics, the cycle time has become progressively smaller and so the risks to individual deployments have reduced.

DevOps Principles

Agile is an integral part of DevOps. DevOps brings new techniques, attitudes, tools and principles. It brings the experience and knowledge of operations to development teams, enabling more effective use of such practices as Continuous integration (Branching and Merging), automated testing, scripting, toolchains, and container-based infrastructure for release and deployment etc. Cloud infrastructure plays a very important role in enabling these practices to work effectively. However, there is little to restrict DevOps in having to exclusively use on premise systems because DevOps processes can exist either entirely in the Cloud or on premise: They can even work well in hybrid configurations.

To keep development cycles short, DevOps depends on a high level of automation, whether it be configuration management, release management, testing, or infrastructure.

Continuous development, release and deployment are all achievable and work well for bespoke applications due to nature of the project.

DevOps and Transformation projects

Most of the long-standing Fortune 500 and Fortune 1000 companies already have well-established IT processes. These organizations have many systems of records and applications on legacy platforms. Most of these organizations have initiatives for ‘Digital’. Their business case for Digital is to provide innovative offerings, implementing applications of differentiation and want to do it at fast pace. These Transformation initiatives have to deliver new functionality while keeping their legacy systems operational as “key” participants of the forthcoming IT architecture. These long-standing enterprises have fewer “new age” systems that inherently support Agile.

Irrespective of such projects’ commitment to Agile, these transformation projects can benefit throughout the software development lifecycle by introducing continuous integration, testing and delivery. This allows the business to experience new functionality being delivered to the business at frequent intervals during the project, rather than it all coming at a single release.

Large enterprises that have established Development, Testing, Infrastructure and Operations teams and matured processes can still leverage DevOps concepts. Automation, Collaboration and Communication are the main areas of opportunity.

DevOps does not compel a daily release of new software, but it does emphasize frequent delivery through the deployment pipeline through to staging. This prevents work piling up for IT operations. The business can then count on predictable outcomes. Deployments to production should happen as frequently as the business can draw value from it. With the breaking down of silos of IT expertise (Development, Test/QA, Governance and Operations) and with frequent delivery, DevOps requires a cultural change.

Newer technology platforms are easier to work in DevOps. Even if the core systems are legacy, DevOps can provide immense value by, for example, bringing efficiency in SDLC wherever possible, and in rolling out digital services that involve newer Agile systems that are integrated with the company’s core systems of record, ERP and CRM systems.

Success Factors

  1. Environments

    Ensure that all development and deployment environments are available early and working throughout for continuous integration, testing, deployments and releases.

    Use Cloud Infrastructure

    Cloud and DevOps go hand in hand. Nearly every major cloud services provider have PaaS service2. The cloud platforms provide support for continuous integration and continuous delivery tools. Using cloud infrastructure increases efficiency, lowers cost for Development, Testing and Operations.

    Containerization

    Run applications and services in containers. The container technology uses virtualization to allow you to maintain the usual deployment model (one application per server) while sharing hardware (OS) resources. Unlike Virtual Machines, containers do not bundle the entire operating system. The container need only have the libraries and settings that are required to run the software. The containers isolate software applications and services using boundaries defined by software, and allows you to create many private execution environments within single instance of the operating system. This means that one system can support multiple applications, can be scaled to meet demand, and can reduce cost while maintaining service levels. This is a very flexible and secure model for rapid application deployment on the production, development, and test environments.

    LXC, Docker and Solaris containers are among the most popular containerization tools.

  2. Branching and Merging

    Legacy version control tools can’t keep up with the DevOps requirements whereas Bitbucket or GitHub are considered to be efficient tools for pull requests, branching strategies, permissions and scalability.

  3. Creating Development Environments with the click of a button

    Engage IT operations in coming up with a tools and process to create Development, E2E Test, Prod-like (QA), and Prod environments at one click. This will bring consistency in the environment and remove the environment variable between different stages of code progress in the Dev to Prod journey.

    There is a wide variety of tools available – Solaris Jumpstart, Redhat Kickstart, Puppet, and custom shell scripts etc. among many others.

    “If your infrastructure is special, you’re doing it wrong.”

    – Luke Kanies, Founder of Puppet Labs

  4. Continuous Integration

    Continuous integration is a cornerstone of DevOps – automating the build and testing of code the developers commit to the version control. It requires the code of the development branch to be merged continuously into the main branch after which automated builds and tests are run. It should flush out all the bugs, gaps quicker and reduce the time it takes validate and release new software version.

  5. Reliable automated build process

    There must be an effective process to build a working software package from the version control repository with the click of a button. This process must be repeatable and standardized to weed out any flaws and inconstancies. This will be able to create a working software package for Production and all the environments in the deployment pipeline leading up to Production. It must be reliable, consistent and quick. To do this effectively, the code, system configurations, environment variables, automated tests, scripts to build the environment etc. must be versioned and must be in one place.

  6. Automated Delivery

    Automated Testing

    Automate all testing activities that can be automated; whether they are front end, backend, functional, performance or even parts of acceptance testing.

    Release and Deployment

    Automation to consistently create and deploy releases that are repeatable. This will standardize the operations and ensure that deployment procedures are not release specific.

  7. Security

    Use automated Code Analysis tools and processes in order to identify potential security problems in the code that is part of the release.

    Increase security with automated, repeatable processes that serve to eliminate fat-finger error and, even more importantly, build security controls from the very beginning.3

    Role Based Access Control (RBAC) gives team members sufficient access to work as per their role. It ensures that the organization is complying with policies and compliance requirements. With its implementation, tasks will be completed by the right people, who have access to right work space and right machines. It will also allow to share the infrastructure with team members without stepping on other’s work.

  8. Feedback Loop

    Feedback loops are one of the differentiators of a DevOps culture, and enablers for rapid response. Feedback loops should be comprehensive and focus should be on amplifying, shortening and closing the feedback cycles. To shorten feedback loops, hand-offs must be reduced and feedback irrespective of the source (Front office, Back Office, Customers, Testers, Security teams etc.) should reach to the developers directly and quickly.

  9. Collaboration among Cross Functional Teams

    Create cross-functional teams from Dev, QA and Operations. Inculcate and build trust among team members to focus on the problems without blame games and foster respect. There should no silos. Silo working is antithesis to DevOps.

Typical problems faced by the enterprises

What

Typical Challenges

Solution

Infrastructure

  • Environment Dependencies
  • Many hand-offs
  • Fool proof build process and automation
  • Virtualization
  • Infrastructure as code
  • Break silos (single ownership)

Development (Part of Build)

  • Manual Unit Testing
  • Limited capability for testing Integration stories due to lack of prod-like data, mock (or real) integrations
  • Longer development time for sequential/dependent stories
  • Delayed feedback
  • Testing automation
  • Continuous integration
  • Rapid test data generation process
  • Make Stories small enough to fit in the Dev cycles and testability
  • Use nimble tools

Testing (Part of Build)

  • Inclination towards manual QA process
  • Multiple integrations with surrounding applications
  • Testing automation
  • Continuous integration
  • Environment assurance of dependent systems

Release & Deployment

  • Dependent systems’ development and tracking of code merge to ensure build does not fail during release
  • Slow rollback in case of failures
  • Manual deployments
  • Deployment automation
  • Strong code branching and versioning process and tools
  • Environment creation assurance
  • Rapid roll back to previous working version

Operations

  • Rollback is very difficult due to data ‘changed’ during the lifetime of a defect.
  • Silo-ed analysis, fix and test
  • Delayed feedback

Identify and resolve issues as soon as possible so that ‘changed data’ that will need to be reconciled – is within reach.

  • Automated testing and thorough test coverage
  • Deployment automation
  • MTBF to MTTR*
  • Cross-functional teams
  • Amplifying, shortening and closing the feedback cycles

MTTR: Mean Time To Resolution

MTBF: Mean Time Between Failure

Tools landscape

You will need tools that support all the different types of team processes. The tools specifics will depend upon core IT systems and newer Agile applications.

Process

Tools (example)

Plan

CA PPM

HPE PPM

Development

Git (GitHub or Bitbucket)

HPE ALM

CA Agile Central

IBM CLM

Build

Jenkins

Nexus

Maven

Subversion

Ant

HP CDA

Git (GitHub or Bitbucket)

Gradle

Test

HPE ALM

IBM CLM

Selenium

Test Studio

Ranorex

TestComplete

Deploy

HP CDA

Puppet

Chef

IBM UrbanCode

Nexus

Octopus

Release

Atrium

Puppet

Nexus

Operate

HPSM

BMC Remedy

Nagios

Conclusion

DevOps is appropriate even when transformation projects are complex and involve legacy systems. The confluence of open source technologies and cloud computing has provided technologies that have made it easier to adopt the DevOps culture in order to deploy systems into production quickly and iterate frequently. For project involving legacy systems, Collaboration, Automation, Closed Feedback and Continuous innovation improve the product quality, shorten time to market, and enhance flexibility. The larger is the organization and/or product portfolio, the more the organization can benefit.

References:

  1. DevOps dictates new approach to cloud development. Retrieved Sep 28, 2017, from https://techbeacon.com/devops-dictates-new-approach-cloud-development
  2. DevOps and Cloud: Like Chocolate and Peanut Butter. Retrieved Sep 25, 2017, from https://www.cio.com/article/2938919/cloud-computing/devops-and-cloud-like-chocolate-and-peanut-butter.html
  3. The Relationship Between The Cloud And DevOps. Retrieved Sep 29, 2017, from https://www.forbes.com/sites/forbestechcouncil/2017/07/21/the-relationship-between-the-cloud-and-devops/#542797fa2957