Microservices act as a constellation of apps, or a software ecosystem that works as a team to improve the workflow. Each aspect of the workflow functions through its individual application. Ultimately, this ecosystem makes things run more smoothly. This is a long journey from a one size fits all software that did everything.

Of course, with so many smaller apps, a change in code could have an impact on the entire system due to the dependencies between applications. A code that may work well for one application may cause another to crash. This is where Zuul comes in. Since all applications depend on each other, Zuul makes sure that merging broken code is a thing of the past.

Ultimately, cross-project dependency in Zuul allows users to be specific with their dependencies across all projects. Keep reading to find out more.

Cross Project Testing

If your projects are as close as two peas in a pod it’s essential that all changes going through the gate will test adequately with the versions of other relevant projects that are currently waiting at the gate. If these are poorly merged then some of the software can break with the new code.

You can ensure that broken code will not merge by configuring projects in a shared queue with a well thought out pipeline. If there are changes in the project, they will enter a shared queue where all changes are tested together to ensure that there will be no broken builds. There’s no limit to shared change queues in a dependent pipeline. This task ensures that groups of related projects can share a change without disrupting other projects.

Cross Project Dependency

One of the features of Zuul is that it allows users to set out specific dependencies across their projects. Through the use of a special footer, it causes a change to depend on another change in any repository known to Zuul. This means that your first change might depend on your second, but your second change may not necessarily depend on your first change.

Directed acyclic graph (DAG) behaves similarly to Zuul’s cross-project dependencies. It demonstrates a one-way dependency between changes in different Git repositories. If you’re using a Gerrit based project this footer needs to incorporate into the Git commit message. Gerrit acts as a code review system and its driver supports sources, triggers, and reporters. Just a note, if you’re using an older syntax specifying dependencies using Gerrit change-ids, it’s still supported but it will be removed in future versions. Moreover, if you’re using a GitHub based project you must add this footer to the pull request description. GitHub supports the same three functions as Gerrit. It can also interact with public GitHub service and site-local installations of GitHub enterprise.

Finally, thanks to cross-project dependencies in Zuul, microservices are able to run exactly as they should. If you’re an enterprise-grade organization running large and complex software, Zuul is an ideal option. From the benefits of co-gating, cross-project dependency, and parallelization, Zuul helps your workflow run in a way that encourages optimal results. Contact our team of experts to learn more.

Would you like to know more about Zuul? So download our white paper and get reading!

How to up your DevOps game with Project Gating

How to Up Your DevOps Game with Project Gating:
Zuul – A CI/CD Gating Tool