This has been a year of DevOps for me professionally. I spent some quality time with a couple of the must-reads: Continuous Delivery by Humble and Farley and The Phoenix Project by Kim, Behr, and Spafford and worked with some colleagues at Red Hat to demonstrate how a DevOps-oriented continuous delivery workflow could operate in the context of Platform-as-a-Service (PaaS).
PaaS is a key enabler of continuous delivery, and should be evaluated as part of any serious effort at DevOps transformation in a large IT organization. PaaS is maturing very rapidly. Offerings like OpenShift by Red Hat now satisfy, out-of-the-box, a lot of automation approaches teams used to have to develop ad hoc solutions for using tools like Puppet and Chef. For many use cases, there should be no need to roll your own development platform install and config automation, at least in any of the major platforms like Java, PHP, Python, Ruby, etc.
Push button deployment of application code to a newly created, containerized server is a solved scenario, available on public cloud infrastructure or internal data centers. My experience is mostly with OpenShift, and it works very well for typical web application deployment.
Humble and Farley’s Continuous Delivery positions the development of “deployment pipelines” as maybe the central practice in efficient software delivery. A deployment pipeline is a structured, automated, optimized process for moving software from idea to production. Deployment pipelines organize delivery into a series of stages, each of which validates a code release in a different, more restrictive way to make sure it’s ready for production.
For Continuous Delivery to work efficiently, the pipeline must be examined for automation opportunities. Wherever you see “environment configuration” or “deployment” in the pipeline, that’s an opportunity for PaaS to take care of automation for you. What’s missing is a central component that can encapsulate the deployment pipeline process and call through to things like the PaaS to drive the software release forward. This is the role typically played by a Continuous Integration/Continuous Delivery server, the most well known of which is the open source Jenkins project. I’ll talk about Jenkins integration with OpenShift in upcoming posts.
