While it’s good that the idea of considering production issues early now has a name (Dev Ops), what matters in the end is delivering software more reliably, reducing waste in the product delivery process, and making stakeholders happy. Since product’s don’t deliver value until they are deployed and working it’s good to take a step back and consider operations and deployment processes and team as first class stakeholders earlier.
Agile methods address the issues of complexity in technology and requirements by acknowledging that it’s hard to design products and processes up front, and it is better to iterate in small steps and adjust based on your results. While much discussion of agile methods focuses on the development process, this approach also applies to deployment and infrastructure. To iterate effectively, you need to have repeatable processes that you can evaluate periodically and improve as you discover flaws. Software configuration management techniques are thus natural enablers of agile software development. Repeatable development processes can happen at many levels.
Repeatable workspaces and builds help developers collaborate effectively on a code level and give you practice building and running the application in a variety of environments. By having a private system build that allows anyone to build, configure and run product teams can quickly identify configuration and environment aspects that vary, and make the build and configuration mechanisms more robust. [Berczuk]. Continuous integration practices give you the ability to develop reliable integration testing practices, in addition to simply ensuring that the build works in a “canonical” environment. [Duvall]. The next logical step to improve product quality is to get more practice with your deployment practices and consider continuous deployment [ Humble].
While automating and practicing your deployment practices will address some of the issues you might have with deployment quality, just executing the practice that developers implement is not enough, you want your system to have a deployment process that serves the needs of the key stakeholders in that process: the operations team. To enable this, you can benefit from considering what makes agile software development effective.
The Agile Difference
Agile software development methods seek to break down walls between the various parts of the traditional product development process. Rather than having distinct requirements, development, and testing phases for a project, agile teams divide the development process into iterations where the whole team works together as one. Agile methods do this by introducing project management and technical practices that allow for frequent, rapid feedback on the quality of the code and the requirements so that teams understand the state of the project all the time based on the artifact that matters most: working code.
The technical practices that are most obvious in an agile team are developer testing, continuous integration, and automation. Testing is no longer a hands-off process, reserved for a QA team. And by building the software ( and running automated tests) after every commit you work to ensure that your code always build and works. In an ideal world, you can release your product at any point.
While continuous integration is a necessary precondition for software to deploy, it is not sufficient for deployment into a production environment if your deployment mechanisms, these mechanisms are development centric. To be successful at creating reliable deployment processes you need to extend your agile stakeholder model to include the operations team and their concerns.
On to Dev ops
Dev ops is an extension of agile[Cowham]. Most software developers have heard of continuous integration and unit testing ( even if they do not use it). Most teams understand the value of versioning all source