Traditionally, DevOps has been viewed from a requirement to release perspective, which is essentially the ‘Dev’ side of DevOps. In effect, this signifies that various technology groups have visibility from the time a request is received from business to the time it gets implemented, and the customer realizes the requested benefits. However, our ALM view of DevOps characteristically straddles across ‘Dev’ to ‘Ops’ integrating not just the ‘Dev’ side but also the ‘Ops’ side, specifically monitoring and IT service management, thereby enabling a continuous feedback loop from ‘Ops’ to ‘Dev.’
DevOps (software DEVelopment and information technology OPerationS) is a practice emphasizing collaboration, communication while automating the process of software delivery and infrastructure changes using tools and technologies. Aimed at establishing a culture and environment, where building, testing, and releasing software can happen rapidly, frequently, and more reliably.
Increasing levels of automation at different stages of the application lifecycle enable Development, Testing, Infrastructure and Support professionals to realize numerous benefits. However, there is something amiss.
Limitations in Classical Orchestration of DevOps
DevOps, conventionally, has been practiced spanning Requirement to Release. Continuous Integration and Continuous Delivery are considered the two pillars of DevOps. Automation occurs in siloes at different stages, such as Build, Release, and Deployment. Essentially, various components of the application lifecycle are not integrated, limiting the span of automation to Development and Testing teams. There are a few problems with this approach:
Distinct view across Dev and Ops for a single application change being planned, developed, tested, deployed and monitored across environments. Partial automated/manual flow actually slows down the velocity of application change to reach production. Alerts and Incidents raised after production and deployment are rarely traced back to the requirements delivered with limited transparency of changes being planned to fix those support issues. Disparity between environments from code and configuration perspective is found.
Realizing the Key Benefits
To realize the full potential of DevOps, we need to look at the entire application lifecycle from Requirement to Support. Automating across the entire application lifecycle ensures integration on pillars of Environment management, Continuous Integration, Continuous Deployment, Continuous Validation, Continuous Monitoring, ITSM and resulting in Continuous Feedback thereby touching upon Development, Testing, Infrastructure and Support teams.
This unleashes a host of benefits:
Single View to Business and IT across ALM Enablement of
integration of DevOps processes in
each phase of the application lifecycle
Automated end-to-end flow for moving application changes seamlessly from planning to production
Agility and
faster time-to-market for application functionality to customers
Virtualization of environment and dependent applications for
expedited application testing
Single Configuration Management Database (
CMDB) to version artefacts across ALM thereby
syncing environments and source code
A single view across Development, Testing, Infrastructure, and Support for application changes traversing across ALM becomes imperative in view of greater focus on delivering customer experiences. Earlier, it was just about integrating Development and Testing teams for application changes and the flow used to stop at release to production. A typical example is one, when a number of alerts or incidents are being triggered and those are not tied back to the requirement, earlier developed by Dev not being visible to Ops.
In our proposed ALM DevOps view (see figure above), we have mapped DevOps processes (requirement management, environment management, continuous integration, continuous validation, continuous deployment, continuous monitoring, ITSM etc.) to each of the ALM phases and integrated those processes across ALM starting from requirements all the way to support in the backend to provide a single view.
