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 begins a blog series about how he started a culture of DevOps at JAMF Software, how he built up the team, and what tools they use.

When I was first hired in 2012, DevOps wasn’t even a thing yet, or at least not at JAMF. I came onboard to assist the engineering team with infrastructure deployment and maintenance, and had just one build server, a handful of developers, and a couple QA folks.

The first few changes worked, for the most part, but we still struggled with inefficiencies. At JAMF Software, we’re all about device management and helping IT do more with less. We make products like Casper Suite, which allows IT personnel to manage thousands of devices from a single web server – so we’re big on efficiency and scalability.

I started looking around for ways to make our team more agile and responsive. Our biggest challenge? We were painfully slow. We could code fast, but we had to “hurry up and wait” for testing and building.

We had other challenges, too – in the ebook I go into more detail about how DevOps helped us overcome them. For now, let’s just say that we knew we could be serving customers even better, and we needed a stronger set of processes and technologies to get us there.

How does DevOps fit in?

That’s the exact question I started with at JAMF. I’d heard a bit about DevOps from friends and colleagues, but wasn’t sure where or how to start.

After a bit of research, I was sold.

Right away, I liked that DevOps centered on improving the relationship and collaboration between developer and IT operations teams. We definitely needed that, to speed up and be able to deliver faster, high quality updates continuously to our customers. The end game of every DevOps practice is continuous delivery: building, testing, and releasing far more frequently, and ensuring that you can release reliably at any time.

My favorite part: it means that operations and support teams (like my Tech Comms team) use many of the same processes and tools as our developers do – so we all speak a similar language, follow similar workflows (like agile development processes), and work very closely together. It’s far more efficient.

A new culture

As a result of transforming our processes, everyone became an owner. Everyone was responsible for the end goal. Engineers now have a commitment to higher quality code, and infrastructure and operations felt responsible for incidents and ensuring that they close the loop. There are no more silos of information and work, and teams readily share successes and failures with one another. Finally, teams are more autonomous. Long decision making processes no longer hampered length of time to make mission critical decisions.

DevOps is good for your customers, too. Really good.

At JAMF, we’re always asking, “How does this help the customer?” We even send our engineering team on customer site visits, for professional development – and in the process, it shows the customer the “face behind the code” and strengthens our relationships.

By adopting DevOps practices at JAMF, our customers have enjoyed:

  • Truly continuous software delivery.
  • They get new stuff all the time, not once every quarter – and they get fixes and patches in minutes or days, not weeks or months.
  • Far faster resolution of problems they do encounter.

Before DevOps, we didn’t have a great system for easily rolling back new code changes – or for swarming the right resources around an incident to resolve it faster. We’ve also enjoyed spending far more time developing, and far less time fixing things, which not only keeps our customers happier, but our team members, too.

Adopting DevOps wasn’t rocket science, but it wasn’t just “flipping a switch” either. It required a commitment to making some big changes in how we work, and overcoming the natural resistance to change that’s inevitable. In my next two blog posts, I’ll touch on what I believe are the most critical components of going from zero to DevOps at JAMF: building the right culture, and choosing the right tools.

Want the full story? I cover all the details of the journey to DevOps at JAMF Software in the ebook. Download it for free 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!

DevOps case study: why we have DevOps at JAMF Software