Are you a Zuul user? Please take a few moments to fill out the Zuul User Survey to provide feedback and information around your deployment. All information is confidential to the OpenStack Foundation unless you designate that it can be public.
Zuul allows Wazo Platform to have cross repository dependencies in pull requests at the source code level, the Debian packaging level, and at the container level. Zuul also enables the Wazo team to reuse job definitions among all the repositories of the same type, which is very helpful for their organization.
T-Systems started using Zuul for the development of OpenStack client components like SDKs, CLIs, and other internal operational software components. After its team managed to get some changes merged into Zuul, they deployed it as their continuous integration system. Now, it is their CI system for the development of all open source tooling it offers to its clients. Furthermore, Zuul is currently used for monitoring its platform services quality. For that, its team periodically execute a set of tests. It also includes monitoring permanently their RefStack compliance.
Leboncoin, an online "flea market" that is one of the top ten searched websites in France, uses Zuulv3 with Gerrit. For each review, Zuul is triggered on three “checks” pipelines: quality, integration and build. Once results are correct, their engineering team uses the gate system to merge the code into repositories and build artifacts. They are using two small OpenStack clusters (3 Controller / 3 Storage / 5 Compute) in each datacenter. Zuul is currently setup on all Gerrit projects and some GitHub projects too and runs around 60,000 jobs per month which means around 2,500 jobs per day. Jobs average time is less than 5 minutes.
An additional development was introduced to Volvo in 2018, namely a new CI system based on Zuul. The newly introduced CI-based development chain is referred to as the Volvo Cars ECM CI chain. From implementation of the software onwards, every single new commit automatically triggers a set of integration and regression tests. The changes committed by the developers are validated by running automated tests against the build. This new development approach fully adheres to the concept of frontloading quality assurance processes. In addition, the key objective to reduce the number of post integration issues to the absolute minimum was achieved fairly quickly.
Tungsten Fabric, an open source project that serves as a networking provider for OpenStack, uses Zuul to test every change going into Tungsten Fabric’s Gerrit review system. It manages the process of compilation, packaging and containerization of the software. The VM-based test environments are well suited for them as some of the tested components need exclusive access to an underlying operating system. The Git-centric Zuul approach of doing things has helped them to get to the “version control everything” model, where all the things, from the CI jobs, through the third-party dependencies to the infrastructure configuration, are version-controlled, reviewed by team members and verified by the open source CI system.
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.