The development and operations (DevOps) role combines several traditional roles: operations, programming and quality assurance. Instead of viewing this as a problem and a violation of "process rigor," DevOps proponents view this as a benefit. After all, it eliminates the friction, miscommunication and handoffs between the roles. It also adds an entire set of techniques for more classic Agile software teams that have a dividing line between programming, support and testing. The question is which techniques to add, and how to implement them, which is addressed in this article.
DevOps in practice
Meanwhile, traditional Agile teams are getting a build from the continuous integration server, manually installing it, manually testing it, then filling out a ticket to have operations move the software to production ... in a day or two.
Between two worlds
Extreme programming (XP) grew out of Chrysler, running a batch-oriented payroll system that might run, at most, once per day. DevOps came from a different world, the world of Web-based Internet properties of Flickr, Twitter and Facebook, where deploys occur continuously. The ability to create test environments, roll changes, monitor and deploy changes in real time is significant for a Web team, much less so for batch.
For a batch environment, that investment might cost more than the value they offer.
Most software teams sit somewhere between those two worlds, in a place where quick, cheap deploys have some value but, thanks to legacy applications, building a continuous delivery framework would be very expensive.
My suggestion is for teams to take small, incremental steps toward DevOps. At every step, you can stop, declare victory and be in better shape than you started. Here are a few ideas; you do not have to take them in chronological order:
Create a database rebuild script. Instead of sharing one database (that may be periodically refreshed, causing a loss of data), create a small number of test databases that can be wiped, refreshed and have test data loaded all in one command or shell script. As a rule of thumb, the sample database should be small enough that it can load in ten minutes or less. You do not need a private cloud for this, just a half a dozen environments and a reservation white board or webpage. The one drawback to this is that you may not have enough environments for every person or, occasionally, someone will wipe and existing environment by mistake.
Create push-button virtual environments. Server virtualization software is cheap and requires little hardware. Tools like OpenVZ (free, Linux-based) or Hyper-V (Microsoft) allow each technical person to have their own environment. One way to start is to hand each person their own personal virtual server.
Create push-button deploys. Once your technical staff have their own environments, script up the deploy and installation of the software, so it can happen at the push of a button.
Enable self-service. Sometimes testers need multiple environments. A tester might want, for example, to compare the behavior of the old software to the new, by running the applications side-by-side. Enabling self-service means the end user, but also the tester, programmer or product owner, can create a new test environment, based on a build number, through some interface. At one company I worked with, this was command-line, which was cheap to build and quick to run. Commercial tools tend to provide user interfaces and dashboards to show what servers are running when.
Tie the continuous integration server into this process. Once deploys are self-service, we can have the build server do more than run its own tests -- it can create virtual servers and run those tests on the software, just as it would occur in product. After that, you can have the CI upgrade a staging server with every build, allowing testers and developers to work on (and monitor) the latest and greatest.
At this point, your team can build, run checks on and deploy the newest version of the software at any time. If you and when your team moves production into a cloud environment, it won't take much to build a big green deploy button for builds. Suddenly, your Agile team is a functioning DevOps team, supporting infrastructure through code.
This article provides a short list of techniques for an Agile team to move to a DevOps approach. They are designed so that each step is reasonably small; they will not require any purchase orders, permissions or help from outside of your team until you have made enough progress to justify the investment.
If you feel pain and loss of opportunity because it takes too long to deploy, or you creating environments takes too many signatures and too much paperwork, then DevOps might be something to look into. If not, that's fine.
I just wanted to give you something to think about, and a solid path to walk on if you liked it.
This was first published in September 2012