BMW has been preparing a centrally hosted CI/CD instance based on Zuul V3 and many of the projects using previous CI/CD solutions are already in the progress of migrating to the new Zuul V3 instance. Hosting many projects on one central platform has many advantages for operation overhead and resource sharing in the cloud, but hosting many projects on one CI/CD instance directly translates to high stability and availability. To maximize the availability of their central CI/CD service, BMW is running Zuul, Nodepool and Zookeeper services in an OpenShift cluster, hosted on OpenStack. In addition to improved availability, they have seen several development and operation benefits for their internal CI/CD development team.
Zuul is in a pilot phase for GoDaddy, primarily in use for testing their OpenStack deployment automation and also for managing changes to some of their Kubernetes deployment automation. They also uses Zuul to test and deploy itself.
GoDaddy has replaced a lot of slow, brittle Jenkins jobs with highly parallelized, more realistic Zuul test jobs. They've also been able to accelerate development on some new projects by setting up rapid proof-of-concepts in PRs to GitHub. Some of these go nowhere, and some of them eventually become the deployment automation that goes into production.
Zuul is currently being used as an offering within OpenLab for projects, applications and tools that need CI gating and/or automation around testing. With the companion tool Nodepool, they are able to keep OpenStack virtual machines available, speeding up the process for developers of testing code changes.
With the introduction of Zuul-based CI/CD instances, projects were able to use the cloud resources for their automation in a very dynamic way. As a result, projects can do much more excessive testing in less time, which directly results in higher quality software, while being faster in development and integration.
With the introduction of Zuul V3, OpenLab also sees a lot of benefits from the operator's perspective by providing a centrally hosted CI/CD instance, as opposed to many small ones that require managing individually.
Software Factory is a distribution that integrates all the components as CentOS packages with an installer/operator named sfconfig to manage service configuration, backup, recovery and upgrades. The main Zuul advantages for their users are customizable deployments and simplicity of use. The RDO project has been using Software Factory successfully for about three years now. The goal is to keep the same user experience from upstream to downstream and to allow them to share configurations, jobs, pipelines and easily run third party CI jobs. With the addition of GitHub support to Zuul, Software Factory can now be used without Gerrit and people are looking into running their own gating CI/CD for GitHub organizations with SF to use the log processing features.
OpenStack ended up in a situation where it wanted to keep gating
changes to OpenStack but have the ability to merge more than 24
changes a day. Running tests more quickly, or running fewer
tests were either not possible or less than ideal options.
Instead the infrastructure team set out to build a system (Zuul)
which could parallelize the serial testing of OpenStack.
Initially, Zuul was the coordinator for Jenkins and the two
systems worked together, and around April 2016, Jenkins was
replaced with an Ansible
Packet Host built a community cloud to support OpenStack with 100 concurrent VM instances each with 8 GB RAM, eight vCPUs and 80 GB storage running on 11 bare metal servers. Working with the OpenStack Infra team has really opened my eyes up to the capabilities of Zuul and the frameworks they’ve put together, says John Studarus, who helped Packet Host put it together.