How DigitalOcean and Northwestern Mutual Use GitLab to Help Run CI/CD

GitLab sponsored this podcast.

Continuous integration/continuous delivery, the GitLab experience in new environments, and even mainframes were the topics of discussion in this latest The New Stack Makers podcast, which took took place at GitLab Commit during an interview with Eddie Zaneski, developer relations manager at DigitalOcean; Kyle Persohn, senior engineer at Northwestern Mutual; and Sean Corkum, senior software engineer at Northwestern Mutual. TNS founder and Editor-in-Chief Alex Williams hosted this podcast.

Launching the discussion was the topic of how organizations can get their teams involved with and building out CI/CD.

“It has to be ingrained in the culture of the team to really take full advantage of everything that you can get from that. Making sure you’re building fast, failing fast, and everyone understands and is totally on board like, ‘Yeah, this is the right way that we should go,'” said Corkum.

CI/CD in Kubernetes

Persohn followed that with an explanation of Northwestern Mutual’s internal core CI/CD team structure that leads and maintains its best practices, adding that,”CI/CD doesn’t just stop there, you have ambassadors out in the development teams that are becoming CI/CD practitioners or leaders that are trying to grow that same mentality and propagate that culture throughout the enterprise.”

At Digital Ocean, Zaneski noted that they also have a full CI/CD pipeline team under their Engineering department.

The discussion then moved on to discuss Northwestern Mutual’s move to GitLab, and what prompted that shift. “Once GitLab CI came about, it made a lot more sense for us to kind of transition to that. It pushed everything so much closer to the developers, they’re the ones that know how to test their code, they know how to build their code, so we can set up, ‘Hey here’s a template if you just want to go, here you go,’ but if you need to go off the beaten path for something, they can just take care of it themselves, they don’t have to worry about contacting another team like, ‘Hey, I need a change to this,’ they can just do it, get going,” said Corkum.

Later in the conversation, Zaneski dove into how Digital Ocean is making use of GitLab Runners, a workflow building tool. “So the GitLab Runners, I was super impressed with them. For my talk, I was doing a lot of preparation, running through it a lot of times. So, I was using the shared runners, and build times would take anywhere from a minute to six minutes sometimes, it was super in flux. If you’re not familiar, the GitLab Runner is just a binary that you can deploy on a server, you can deploy it to a Kubernetes cluster, there’s a bunch of different ways to run the runner. All the runner does is, it does a pull for jobs from GitLab to run, and that’s what’s unique about it too, is that it’s not a push thing, it’s a pull thing. So the runner will reach out to GitLab like, ‘Hey, you got anything for me to run?’ and then all of your CI/CD pipelines that are in GitLab can be kicked off into the runners to actually run and complete. And so by subbing in my own runners on my own VMs, instead of using the shared runners, I cut my build time down to a consistent 30-45 seconds. When build times are in need, that’s when you want to lean on those runners, they can do a lot for you.”

In this Edition:

1:17: Building out CI/CD.
3:05: Before GitLab.
9:29:  GitOps and continuous delivery.
11:04: Northwestern Mutual and workflows.
12:44: How DigitalOcean uses GitLab Runners.
17:39: Observability and GitLab Runners.