WAKE UP…Red Hat starts releasing OpenShift nightly builds

OpenShift Nightly Builds
OpenShift Nightly Builds

OpenShift has joined the ranks of projects offering nightly builds in a bid to help companies better plan deployments and integration work. 

As in other projects, these builds offer interested parties early access to whatever it is the OpenShift team is currently working on. At the moment this means version 4.2 of the container application platform. 

Users should be aware that a nightly build should not be used in production, as it is an unsupported work in progress. This also means documentation can be patchy, so you might be on your own if something doesn’t work out as planned.

If you wonder why this has become available just now, Red Hat product manager Mike Barrett uses the announcement post to share a bit of insight into the behind the scenes changes in the OpenShift world. 

Since acquiring CoreOS, the team has been busy taking a page from the cloud-native company, engineering tooling to improve OpenShift not only as an application platform but as a Kubernetes distribution as well.

Amongst those is a new software distribution system which runs as a SaaS service and allows for automatic OpenShift 4 cluster updates “over the air”. OS4 also includes a component called telemeter that can give feedback when something isn’t functioning properly so that the team can start finding a solution earlier. 

Apart from that, the frequency in which z-stream patches are released has been upped with the goal of offering one per week (which doesn’t mean you’ll have to update that often, but you could if you wished). This meant that there was also a need for better testing infrastructure, which now makes sure updates work on all the available platforms.

According to Barrett, all of these elements – especially the automated integration, testing and rollout capabilities – are now leveraged for the nightly builds. To him, they symbolise another step in working closer with the company’s customers, since they offer direct access to improvements as well as information that might not have been otherwise available to them. The additional insight can for example help teams planning deployments or those developing integrations, as they’ll have a better idea of what will change and how it might affect their work.