Integrating OpenShift Into Your Release Pipeline

| March 27, 2018 | 0 Comments

I won’t be making a controversial statement when I say that container technologies are becoming increasingly important for enterprises. 2017 saw a consolidation of container technology around Kubernetes, and I expect the high rate of innovation to continue in 2018. Which platform will still be standing when the dust settles remains to be seen. In the meantime, OpenShift has a good head start; we see a lot of adoption of OpenShift in the enterprise.

Read on to learn how to get the most out of your OpenShift investments by using the new XL Release OpenShift plugin.

OpenShift logo

What is OpenShift?

OpenShift is an enterprise-grade container platform that extends the container orchestration capabilities of Kubernetes with build, image registry, routing, and many other advanced features. These features turn it into a powerful container-based platform-as-a-service that can be run on-prem (OpenShift Container Platform), on RedHat’s public cloud (OpenShift Online), as well as in a dedicated cloud instance (OpenShift Dedicated).

But how can you integrate OpenShift into your release pipeline? The OpenShift documentation that explains how to promote applications across environments is a good starting point. Let’s see how we can implement that in an enterprise.

Triggering a Build

Let’s start with the basics: triggering a build. OpenShift offers a few ways to trigger a build. A build can be trigged through a webhook. A build can be triggered when an image changes. And a build can be triggered manually.

However, in more complex enterprise setups, one might require additional ways to trigger a build. For example, because of network limitations, GitHub can only be polled, or the build needs to be triggered as part of a release process. For use cases such as these, the XL Release OpenShift plugin defines a task that allows you to start a build at any place in your release pipeline.

WHITE PAPER

Enterprise Software Delivery in the Age of Containers

How can enterprises take advantage of the benefits of container technology without creating more work for their teams? Download this free whitepaper to learn where containers fall short and how Release Orchestration and Deployment Automation tools can bridge the gap between the promise of containers and the realities of complex enterprise application delivery.

Copying an Image

Many organizations set up multiple OpenShift clusters, for example, one for development, one to run acceptance tests, and another one for production use. By default, each OpenShift cluster includes its own integrated image registry that is used to store the results of builds by way of image streams.

That means images will have to be copied from the registry in the first OpenShift cluster to the registry in the second OpenShift cluster. The XL Deploy Docker plugin defines a control task to copy an image from one registry to another. You can invoke this control task from XL Release to promote the image at a certain point in the pipeline, for example, after it has been verified to not contain any security issues or after an approval gate.

Triggering a Deployment

OpenShift’s Deployment objects manage the containers that make up an application (through replication controllers, jobs, and pods). You can configure them to automatically roll out new images by using an ImageChange Trigger. However, the downside of this approach is that there is no control over whether or when a deployment happens.

The XL Release OpenShift plugin defines a task that starts a deployment. You can place this deployment task wherever you want it in the pipeline, such as after an approval gate or orchestrated with other deployments.

Putting It All Together

If we put it all together, this is what the pipeline looks like in XL Release:

XL Release pipeline and OpenShift

This pipeline will build the application, check before proceeding to the QA phase, and then promote the application to the QA environment, and deploy it there.

Adding Enterprise Value

Of course, this is a simplistic pipeline that only focuses on the capabilities described above. In a real-world case, this pipeline would be extended with more integrations, more tasks, and more phases to cover the complete pipeline as you’d need it in an enterprise context. See, for example, our recent blogs about integrating compliance and quality into your DevOps pipeline and taking control of your release process with customizable risk intelligence.


About the Author ()

Vincent Partington is the CTO of XebiaLabs. Vincent founded XebiaLabs and is the driver of technology planning, strategic direction, and strategic partnerships for the company. Vincent ensures the company continues to lead the field in engineering and innovative technologies.