This article is part two of a multi-part series focused on looking at DevOps through the People, Process, Technology framework. In part one, we looked at DevOps through a people or organizational lens. While shifting to a DevOps model does require some reorganization of existing team members, the more significant change happens in the underlying mindset and culture.

The DevOps shift requires the implementation of various processes. However, DevOps processes implemented without a change in culture and mindset will fail. The most notable shift in process in a DevOps environment includes the shifting towards continuous everything: delivery, testing, integration, and monitoring.

The initial planning and requirements processes may shift to an agile process (release planning and backlog grooming instead of project planning and project schedule development), but the impactful DevOps changes occur during software development and deployment. In the traditional software development model, development and deployments occur as scheduled activities in a finite timetable.

In the DevOps world, the deployment model truly shifts towards an infinite schedule allowing for quicker integration of code and less drama around, “who broke the build!” However, while DevOps does not completely remove the build drama, at least you find out about broken builds much sooner!

One agile focused organization I worked with spent two days out of every 10-day development sprint focused on build issues. A constant back and forth occurred between the development team on what components broke the build. As time went on in a sprint, the more significant the build issues became. When they shifted to a DevOps mindset, the builds would still break but the changes required to fix them were less impactful, they would take a total of 2 hours spread over 10 days to address. This example is analogous to the home building process often used when describing some of the project planning required in software projects. It is easiest and least expensive to make changes, such as electrical outlet relocations, on paper in the design phase. Relocation is still easy after construction starts, and even after framing concludes. However, after the sheetrock and paint are up, relocation becomes time consuming, effort intensive, and costly. Similarly, code or configuration issues in a software build that can be fixed in a few minutes before a deployment can take hours or days after code from multiple sources is checked in and deployed (sheet-rocked, spackled, and painted). Additionally, the continuous quality assurance principals ensure the code is always working instead of verifying only at certain stage gates.

The continuous integration component of DevOps is the largest adjustment for most teams. The implementation of a software tool-set supporting continuous integration as well as the general process of ensuring code is working before checking it in causes angst among many development teams when initially implemented. This angst stems from the perceived increased scrutiny. However, once the Continuous integration process is up and running for a few weeks, most teams never look back. Continuous integration gives the team ownership of providing a working product in shorter, more iterative sprints – like other Agile methods.

In part three of the DevOps evaluation, we will look at some of the tools that support a DevOps shift including continuous integration platforms and continuous testing.