A successful software project consists of much more than actually writing software. There are product development concerns, usability concerns, aesthetic concerns, and, of course, delivery concerns.
It often seems that the delivery phase of software development project is neglected. The product is valuable, the design sleek, and the code well-written and tested—but the final handoff and deployment have been neglected. The problem is, “‘dev complete’ is a long long way from ‘live, in production, stable, making money'” (Nelson-Smith, 2010).
In recent years, the DevOps movement has emerged as a response to some of these problems—improving deployment and management of software that has already been written.
The Problem with Separating Development & Operations
In traditional software development (circa 1990’s and 2000’s), the development team would write software and then “toss it over the wall” to the operations team responsible for deploying and running the software. Often, no useful communication would occur between these teams prior to this attempt at delivering the software. The teams were siloed: they would not share information or work together.
Unsurprisingly, this often resulted in problems. For instance, the development environment used to write the software would not match the production environment in which the software was expected to run. This would introduce bugs, inconsistent behavior, and a general lack of confidence in the software.
After delivering a software product, these two teams were often antagonistic towards each other when making updates. Developers wanted to make code changes to build new functionality and introduce new technologies to make new and exciting things. The operations team, on the other hand, wanted to keep existing software running and didn’t want to jeopardize the stability of the system. This put the teams at odds with each other and contributed to building a cycle of mistrust and confusion.
Heavy-handed processes sprung up in an attempt to bring stability and order. For example, developers were often prevented from accessing the actual production environments, and painful change management workflows were required to deploy any code updates.
Together, all of this confusion, mistrust, and red tape often resulted in software projects never launching, or launching significantly over-budget and overdue.
How DevOps Helps
At a very high level, the DevOps movement promotes a culture of better communication between teams—usually development and operations (hence “DevOps”)—to improve the software development process. Its response to mistrust and confusion is to remove barriers between the development and operations teams.
Rather than waiting until software is approaching completion to “toss it over the wall,” DevOps seeks to start communication between all involved teams earlier so that problems can be identified, issues discussed, and the final delivery of the product planned so that it has a higher chance of success.
DevOps encourages a multi-disciplinary approach. Members development and operations work together (the earlier the better)—building bridges, breaking down barriers, shortening feedback loops, and increasing the probability that a software project will be successfully delivered and provide value. Similar to principles in Agile software development, shorter feedback loops and closer collaboration help ensure that problems are discovered and addressed quickly. As with many aspect of software development, problems are much less costly to solve earlier rather than at (or after) launch.
In practice, DevOps manifests itself in several ways, and from both ends of the spectrum. For example, a member of the operations team may join a development team early on in project to participate in building the development environment and learn as much as possible about how the software will need to run in production and be supported. Alternatively, a member of the development team may join the operations team to help drive the build-out of automation and testing components to support the software in production. In some organizations, there may not even be dedicated teams, but individuals who have skills in both development and operations who can proactively work to ensure that the final delivery and handoff of their software project is a success.
What DevOps Isn’t
It is important to note that people are not DevOps, and DevOps is not a role. People on teams practice DevOps principles, similar to how development teams adhere to principles of Agile.
DevOps is also a much more sophisticated model than “SysAdmin who code.” It is a movement aimed at improving how software products are deployed and managed. Some of the common approaches include developers who can stand-up virtual servers and system administrators who make use of automation, but these are aspects of the paradigm and not the goal itself.
DevOps At Atomic
Atomic Object writes software that we ultimately must deliver to our customers. Members of our development teams are generalists who have skills in many different technologies and many aspects of the software development process, including product development, design, and delivery. While we have always worked in the spirit of many of the DevOps principles (there is much in common with Agile software development), the last few years have seen a more pronounced focus on ensuring delivery of our software goes smoothly by using tools often seen in DevOps contexts such as virtualization, infrastructure as code, and automated testing (of both the software and the infrastructure).
We work closely with our customers to ensure the delivery of the final software product is handled appropriately. Depending on the particular situation, this could mean working closely with the customer’s operations team to deploy to an existing infrastructure, submitting an application to a distribution service like the Apple AppStore, or building an entirely new cluster of cloud VM’s to host a high performance web application.
The key is that our teams begin communicating and collaborating early on with other teams, both internal and external, to ensure that the delivery phase of our software project isn’t an afterthought.