How we choose DevOps tools at JAMF Software

This is a guest post from DevOps Manager Michael Kren and is part of a blog series about how he started a culture of DevOps at JAMF Software – how he built his team and the tools he used. His entire DevOps journey is collected in an ebook, which is available for download. Read on and check out the ebook!

This is a guest post from Michael Kren. Michael is a DevOps Manager at JAMF Software, which makes software that helps IT teams manage their Apple devices. This ends a blog series about how he started a culture of DevOps at JAMF Software, how he built up the team, and what tools that they use.

Now for some of the fun stuff — the tools we’ve adopted to make our jobs easier.

Before we began our DevOps journey, we were committing everything to a single trunk branch using a huge script that literally built everything, all at once. We used SVN and Jenkins to do it, and at one point we had at least 50 Jenkins slaves.

We knew there had to be a better way, and we were committed to finding it. But I wasn’t looking to change tools just because there were shiny new tools out there to try, or because someone else liked them better than what we were using.

When evaluating a tool, I recommend considering these two questions:

Our top DevOps tools for continuous delivery

The first change we made was to adopt Git. It helped our customers by increasing code quality in our main-line (develop) branch, since only “done” issues get merged. It also allowed for features to be worked on longer than a single release cycle, which helped the engineering team scale more effectively. It made great business sense.

With each additional tool, we were looking for easy-to-implement but high value tools that enabled true continuous delivery and DevOps automation. Along the way, we:

Why DevOps automation in the first place?

On our DevOps team at JAMF our entire goal is automating ourselves out of our jobs. To do so, we spend lots of time talking to the developers and QA folks we support and asking them about their pains and challenges.

My favorite questions to ask:

There isn’t an engineer in the world that won’t happily bend your ear over these questions, and their feedback helps us narrow in on where we can make the biggest improvements for both our team members and our customers. Sometimes, the answer is process. Sometimes, it’s tools. But it’s never just nothing.

For us, adopting DevOps has made our smart people even smarter – but it took patience, persistence, a little bit of pushing, and a cultural commitment to collaboration and change. The best part is, a few years in, we’ve only just begun.

Want the full story? I cover all the details of the journey to DevOps at JAMF in the free ebook. Download it by clicking on the big green button below!

Read the ebook


Did you find this post useful? Share it on your social network of choice so others can learn more about how to start thinking about DevOps at their company!

Exit mobile version