What if you could make DevOps easy and reliable?

by Jurgen Hoffman (Red Hat)

OpenShift is great! Developers can quickly start development on a new project. Just log into the web console, create a new application, select a gear and start coding. When you are done implementing a feature you push to OpenShift and after a few seconds you can admire and share your work with the whole world.

But there is more to consider when working with OpenShift. What if you develop in teams? Usually applications are not directly deployed into production. How can I implement a staging process harnessing the OpenShift Infrastructure? How do I know if my changes passed an Acceptance Test or failed it? How does a test team know which features have been implemented?

The answer to these questions are usually not easy, and every company has implemented their own set of processes to address these problems. Although some Organizations have automated some of their IT Infrastructure, there are still a lot of manual processes and changes involved when it comes down to taking a particular software release from development into production. On the other hand, the business stakeholders have a high interest into a fast and efficient Release process, because every day that my feature is not in production and available to my users, is lowering my ROI.

The industry has responded to that problem by establishing a process called DevOps. DevOps is a philosophy that stresses the communication, integration and collaboration between software developers and IT operations. DevOps is focussing on the Delivery of Software. DevOps makes everybody involved in the process of releasing software responsible for the success of the delivery. It promotes an agile software development process and tries to reduce the handover delays and communication barriers of siloed teams. By making everybody responsible for a successful Software Release, there is a greater willingness to transfer configuration responsibility from IT Operations to Developers and Developers on the other hand have a better understanding of how their applications are operated in production.

Now wait a minute, isn't that what OpenShift provides? I as a developer have the possibility to change the configuration of my EAP 6 Instance. Do I have access to other parts of the Runtime Environment? Yes, but only to things that are important for my project for example which JDK Version to use or whether or not to run maven. The other complexities of the Runtime are hidden from me. The underlying Cartridges that provide the functionality are provided through the IT Operations Department. If I need access to change a certain configuration file, IT Operations can make use of the cartridge build lifecycle and decide whether they want to copy the file from my application to its destination or whether they want to merge it with other changes. OpenShift has a well defined Application Lifecycle that is easily extendable.

The cartridge System allows IT Operations to provide mocked service instances to the developer. This enables the IT Operations Department to provide the developer predefined production environments making it easy and fast to reproduce production errors in the developer environment. Wouldn't it be nice to be handed over an exact replica of the production environment configuration in case you have to troubleshoot a production problem?

Usually it is considered good practice to create a binary application release only once[1]. Then take this binary release and deploy it into your different stages. Everything that is different between the stages should only be configuration files. Adhering to this practice unfolds deployment errors early and give builds confidence that if a deployment fails, that the failure should be in the configuration and not in the binary release.

OpenShift integrates well with jenkins and maven. If you want to adhere to the above principle you can leverage jenkins to create software releases for you and release them to nexus. The OpenShifts RESTful API enables you to implement your staging process deploying only that binary release.

DevOps implementation is no longer a long, complex to implement and a long and cumbersome journey. If DevOps is a Process Description of an Agile and Efficient Enterprise, OpenShift is its Implementation.

[1] This is actually one of the key principles of Continuous Delivery. I do not want to delve into Continuous Delivery here, that will follow in the next article, I just use it as it applies to some extent to DevOps as well.

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.