How Agile Teams Use DevOps for Deployment
Working code is the primary artifact of interest that an agile team creates. However, a successful product delivery means more than building code that can pass developer tests. Remember, code only delivers value once it is deployed. Because developer testing is a prerequisite for successful deployment, it seems that testing deployment environments should be a reasonable thing to do.
Agile practices add value by helping teams detect problems early and avoid repeating them; these practices also help teams get feedback early and often. If you limit your testing to unit and integration tests, you are effectively passing tested code “over the wall” to an operations team to deploy—and this can hide problems. So, the entire team is responsible for deployment.
To extend the feedback loop into deployment, teams are taking a DevOps approach by including the needs of operations teams in the process early. Delivering a simple application to a production environment makes it possible to detect issues early and avoids situations where code relies on mechanisms that won’t work in production. While DevOps has challenges, addressing deployment issues early is very valuable.
Extending DevOps to use continuous delivery means that there are opportunities to exercise the deployment mechanism to quickly detect problems, both with the code and with the deployment process. DevOps helps avoid waste by finding problems early.
DevOps and continuous delivery help deliver value predictably. The only thing missing is a regular process that validates the deployment environment. Integration and acceptance tests validate that the application works as deployed, but they may not verify that the environment is correct. Though there are a number of frameworks that support developer and integration testing, there aren’t many well-defined ways to validate an environment.
Using a tool like Puppet or Chef can help ensure consistency and provide hooks for some validations. These tools are useful for creating known environments, but they don’t necessarily tell us if the environment supports the contract we expect. For example, a correctly configured machine could be placed in an environment where an external dependency like a firewall setting has been changed. It’s possible to develop tests for all of these things using your own tools, but testing at the DevOps level seems to be missing.
Recently, I had a chance to look at a tool that addresses many of these issues. ScriptRock provides a framework for testing configurations. With a library of existing, configurable tests that you can extend, this seems like a promising tool to identify problems in your deployment environment before they manifest themselves in your application.
Tools like ScriptRock and practices like automated environment testing after configuration changes are great examples of incremental improvements that are central to agile practices. As we test code in the small before committing it to a source code repository, we are pushing automated testing outward and now thinking about how to validate our deployment environments. Not everything will be amenable to automated testing, but automated tests will help us know where to focus our development time effectively.
Much like testing and software configuration management go together, combining testing and environment configuration tools can help you realize agile CM's real value: understanding the impact of a change.
