The Cultural Impact of Changing CI/CD Tooling

Last week was Harness’ Company Kick Off for FY22. If you’ve never had a CKO before (I hadn’t), the best way to describe it is a couple jam-packed days of action. We go over every department’s plans for the current year, reviewing last year, and have good talks/sessions with inside and outside speakers. We had a great speaker on the first day - a client, actually - that said something truly profound: CI/CD isn’t just about the technology - it’s about the cultural impact, too. 

I had never actually considered the cultural impact something like that could have - and I’m a bit ashamed to admit it, since I have a DevOps engineer as a partner and we’ve talked about that before. I guess it just didn’t register on my radar as “that big of a deal.” But, he’s been in DevOps for over a decade, and from company to company, he’s gone through a lot of CI/CD tools. He’s touched everything from Jenkins, CircleCI, and Travis CI to Harness, FluxCD, and currently Argo CD (whew). And yes, he had indeed mentioned some migrations from one tool to another and how it impacted the DevOps/engineering culture. 

Let’s talk about that. 

DevOps Is More Than “Just a Job Title”

From the moment I met my partner, he spoke about his job with a twinkle in his eye. You could tell it’s his passion just by spending 10 minutes talking to him. He gets excited talking about DevOps and any new tech he can get his hands on. And he also explained to me, fairly early on, that DevOps isn’t just a job title: it’s a culture and a mindset, too. 

That culture lays its foundation on evangelizing cross-team collaboration and communication. Remember that; it’ll be important later.

The Cultural Impact of a New CI/CD Tool

A very large chunk of DevOps/engineering is focused on CI/CD: getting a basic pipeline/process up and running, modifying it, extending it, molding it to exactly what it needs to be. Lots of companies tend to start with a low or non-existent budget, so you’ll see either DevOps engineers or developers start with Jenkins (or another open-source CI tool) and then spend inordinate amounts of time maintaining it, getting the right plugins and integrations in, scripting to extend it into CD. You get the point, right? CI/CD becomes a very time-consuming thing since there’s not much of a budget for it. 

But eventually, hey, money comes around! The higher-ups in engineering decide it’s time to reevaluate the CI/CD process since it seems to be taking a lot of person hours to maintain (sometimes taking between 2 to 5 DevOps engineers to manage), and they go for a ~fancy~ platform that does it all natively. Boom, no more plugins to maintain. Containerized everything. No more scripting. No more dependency hell. Easy Canary deployments. Great, right?! Yes... but also no: the teams who built the original CI/CD solution now feel super shafted, because 1) they spent so much time building CI/CD scripts, and 2) they were not involved in the selection process for new tooling.

I’d venture to say the latter is probably the more painful of the two. 

Where’s the Collaboration?

It can be really hard for engineers to let go of their homegrown solutions. Having change forced on them without being 100% on board can shift that collaboration culture to the side, making adoption harder to accomplish, and creating an unpleasant working environment for everyone involved. 

And, since collaboration is so important in DevOps culture (which impacts all who are in engineering), wouldn’t a better path be to involve both DevOps and developers in the decision-making process? 

DevOps engineers are amazing - the unicorns of the engineering world - and they want to do what’s best and most efficient for engineering teams. If you value that in your culture, include them in the decision. 

Developers, meanwhile, are the end users that have to live with and utilize the CI/CD solution(s), and it’s almost impossible to gain high adoption of a CI/CD solution without their buy-in. 

Have each group collaboratively test-drive multiple platforms - or even separate CI and CD vendors - and let them come to a conclusion on which is best. 

DevOps, the All-Seeing Eye

While you may have certain needs/wants in a platform, DevOps engineers have their pulse on the heartbeat of CI/CD at all times. Take advantage of that! They probably have a great idea of what to look for - not just for what you need right now, but what you might need in the future as well. Additionally, they have a perspective no other team member does: DevOps are, at many companies, a shared resource across multiple teams - which means they get profound, meaningful visibility into everything that engineering touches.

It bears repeating: involve DevOps. They’ll give you a perspective no one else can. 

“Hello, Is It Me You’re Looking For?”

If you landed on this article because you’re looking for a new CI/CD vendor, please don’t hesitate to get in touch. We’d love to meet with you - and your DevOps/engineering teams - to see if we’re the right fit, and how we could alleviate the cultural impact of switching over. Schedule a demo with us today.