Businesses are becoming more agile in order to more quickly respond to market disruptions, innovative competitors, empowered customers and fluid business conditions. Software development has turned to agile and Scrum methods to accommodate this new business imperative. However, IT operational processes beyond software creation have struggled to deliver similar advances.
DevOps is a response to support business agility and to bring much needed innovation to IT operations, facilitate continuous software delivery, and bridge the silos between the people that create software and the people that manage that software.
DevOps manages the end-to-end software delivery lifecycle and the continuous delivery of software-driven innovation. It increases the speed at which new applications can be released and existing applications modified.
It also does three additional things:
- Builds a culture of communication and collaboration among developers, QA and IT professionals;
- Automates the process of software delivery and infrastructure changes; and
- Creates an end to end platform where building, testing, and releasing software occurs faster, more frequently, and more reliably.
In many ways DevOps surfaced as a downstream response to cloud computing and a reaction to Agile software development methods. Cloud CRM systems facilitate change, decrease rigid constructs and increase the pace of innovation. Agile methods such as Scrum increase the delivery frequency of incremental software releases.
In any operational lifecycle the overall pace is constrained by the weakest link. More CRM software deliveries have created a bottleneck or put a strain on release management processes.
Synergies with Agile
DevOps is to coders, QA and IT what agile is to the enterprise.
DevOps and Agile are symbiotic, and together deliver a synergistic effect. Consider the similarities.
- Agile promotes collaboration among multi-disciplinary and self-directed teams. DevOps does the same. The teams include different roles but the principal is consistent.
- Agile promotes iterative and adaptive implementation methods. So does DevOps. Both methods are built on the empirical process which embraces the three pillars of transparency, inspection, and adaptation. More inspections and adaptations increase quality, reduce risk and deliver the right outcomes.
- Agile promotes the frequent delivery of incremental software releases. DevOps follows suit so that software operations move in lockstep with software creation.
As agile methods have evolved from pioneering movements to common practices they have created downstream challenges. DevOps responds to these obstacles by delivering the last mile of the software creation process, and getting new software capabilities into the hands of users and customers without delay.
On the flipside, failure to adopt or adapt a holistic software ops method to keep up with agile’s increased pace of software creation will most likely result in straining a rigid release process, incurring more errors and delaying software delivery to users and customers. Few software operations are capable of supporting continuous delivery without modification.
A CRM DevOps Framework
Advancing DevOps from principals to systemic execution requires a framework. However, unlike agile which benefits from many mature frameworks (i.e., Scrum, Kanban, XP), DevOps doesn't yet offer similar bodies of knowledge. In my opinion, as DevOps should be an integrated extension of your agile framework, DevOps playbooks should be similarly built on the constructs of your chosen agile method.
Scrum is the most popular agile method and built upon the constructs of roles, events, artifacts and rules. Here's how those four constructs can be naturally extended to DevOps.
DevOps roles include Developers, QA and IT staff. There is likely some overlap with the Scrum roles of Product Owner, Scrum Master and Dev team. In fact, if there is no overlap you probably need to reassign some participants in order to create some common members that can orchestrate a seamless transition from software creation to software management.
A core tenant of DevOps is to remove the siloes and create a bridge between the people that create software and the people that release and manage software. Like Scrum, DevOps teams should be self-directed and multi-disciplinary, meaning they may include enterprise architects, systems engineers, system administrators, network administrators, DBAs, IT infrastructure staff, information security staff or other participants required to complete the operation.
Scrum events are based on sprints. Each sprint is a container for the four time-boxed events of the sprint plan, daily Scrum, sprint review and sprint retrospective. DevOps can benefit from a similar event-based approach that includes iteration plans, daily stand-ups, release reviews and ops retrospectives.
Scrum uses six artifacts, including the product backlog, sprint backlog, definition of done, increment, sprint progress report (i.e., burn down chart) and project progress report (i.e., velocity chart). DevOps can benefit by reviewing the sprint backlog in order to plan future releases, reviewing increments to identify variations to existing software ops and producing similar iteration and project progress reporting.
Agile tools are generally limited to apps like Jira, Rally or Microsoft DevOps for program management; development environments; and a few utility programs such as planningpoker.com or something similar for user story estimating.
On the other hand, DevOps tools include a much more sophisticated toolbox – called a toolchain – to support the many operational requirements. I've seen simple toolchains grouped into categories of release management (with apps such as chef, jenkins, puppet, teamcity or travis), configuration management (ansible or cfengine) and operations management (docker, mesos, noah, vagrant and zookeeper). However, a toolchain hierarchy that I think works well for enterprise software such as ERP systems and CRM software applications segments tools into the following categories.
- Code Tools – for software development and continuous integration. These tools often lie at the transition from software development to DevOps and may include both integrated development environments such as .NET or J2EE and application specific tools such as xRM or Power Platform for Microsoft Dynamics CRM or Salesforce1 or Lightning for Salesforce.
- Build Tools – for migrating solution builds among staged environments (i.e., Dev to QA to UAT to Production). These tools manage source code, version control, code merging and automated builds among other things. When working with enterprise software applications they often provide SDLC and application lifecycle management (ALM) automation. Within a CRM software context, a popular tool is Microsoft DevOps. There is also a trend by leading CRM software publishers to advance their own integrated build tools. Microsoft is leading this charge with a tool called Lifecycle Services (LCS) that simplifies build management for its Dynamics software.
- Test Tools – for testing fit, quality, security, performance and scalability. These apps provide the highest value when they can be sequenced and automated to facilitate the testing journey from unit testing, to QA, to UAT, to regression testing, to system integration testing, to end to end testing, and beyond.
- Release Tools – for release approvals, release automation and change management. These apps are often designed to support continuous integration and continuous software deployment.
- Configure Tools – for infrastructure configuration and software management. There's a lot of innovation occurring in this category and we're seeing a trend of infrastructure as code apps.
- Monitor Tools – for infrastructure and software performance monitoring, utilization and even user experience.
DevOps principals supported by a framework or playbook enable more frequent releases which aid the company's mission of innovation and faster time to market. At an operational level DevOps facilitates improved code quality, more reliable releases, faster recovery, user satisfaction, operational stability and team productivity.