By Ted Cordery, product manager and Rasmus Selsmark, DevOps engineer, Unity
If you’re into video game development, you’ve probably heard of Unity. We’re the world’s leading platform for creating and operating interactive, real-time 3D content. Thousands of game creators use our platform to build more than half of the mobile games on the market and 60 percent of augmented reality and virtual reality content.
Behind the scenes at Unity, we’re always working to keep our platform on the leading edge of the industry and well ahead of the competition. Our job is to provide tools, services and support to all of our engineering teams. We have about 150 teams and more than 1,500 engineers around the world who use the dev tools we provide every day. One of the most valuable and versatile tools we’ve been leveraging recently is shared Jenkins Libraries.
Our work primarily supports Unity Ads. We help our customers – game creators – make money by inserting relevant, purposeful advertising into their games. The scale of the service is massive: Unity Ads reports, as of the six months ending June 30, 2020, that it reaches more than 2.4B players per month, with more than 22.9B average monthly ad impressions globally. In fact, mobile measurement firm AppsFlyer said Facebook held the number one spot in mobile advertising, followed by Google and Unity Ads in the first half of 2020, according to the company’s biannual Performance Index study.
With demand for this service exploding, we realized that to handle the scale – and the 10-fold increase in traffic – we had to change our architecture. Specifically, we needed to move away from a monolith service and move into microservices. But this presented us with a challenge: How do we coordinate all our microservices deployments?
Write once, share often
Luckily, we had shared Jenkins libraries to help out, and we’ve started building a shared library designed to be used by all our microservices. This means that instead of having the same code running in different pipelines, we only have to write it once. Our development teams love it because they can spend less time managing deployment pipelines and more time building features and generating business value.
Today, we have more than 200 microservices using the same shared Jenkins library in an environment where we’re doing more than 150 production deployments per day. More than 40 teams use the shared code library and we have about 30 different contributors constantly adding features to the repository.
One of the things we’ve found since starting this project is that you get a high degree of ownership within the organization when people contribute to a common library. It’s not just some tool that has been forced on them. Shared Jenkins libraries also promote cross-team collaboration because the features developed by one team, such as canary deployments, can be easily picked up and used by other teams.
Empowering Unity Ads Teams
Using shared libraries dovetails with the type of DevOps culture we’ve wanted to nurture in our Unity Ads division: one that emphasizes shared learnings and empowerment of teams, as well as transparent tooling. Everybody can look inside our shared Jenkins libraries and see what’s happening there. It’s not a black box, and that has helped dispel any doubts developers might have about whether they can rely on it for their deployment processes.
We view shared Jenkins libraries as a critical infrastructure component. If the Jenkins library isn’t working, then it may mean we can’t deploy into production. And if that happens at the wrong time, it could be very critical.
CloudBees CI, we should point out, has been a big part of the success of this project. By giving us the ability to configure controllers in a standardized way, we see CloudBees CI as a great opportunity for us to deliver the shared library to the individual development teams. And as teams build on top of our shared library, and as we see the benefits for the wider company, we can incorporate the additions and extend the library.
With CloudBees CI, we're able to incorporate the shared library into our controllers right off the bat and preconfigure all the integrations required for the shared library. That means it takes less time for developers to figure out how to set up their pipelines, so they're able to start deploying sooner.
To sum it all up: We're tremendously excited about shared Jenkins libraries. In fact, we feel the shared library has really helped the Unity Ads division continue its upward trend of success.
Watch our full presentation “How Do I Mock It? – Open Source Examples of Unit Tests for a Jenkins Shared Library” from DevOps World 2020 On Demand.