If you hadn’t noticed it yet, the role of the modern IT administrator is evolving.
New tools and methods are consistently being created that fundamentally change the way we all work and approach work day-to-day. It’s becoming clearer every day that clicking around in SaaS consoles to configure enterprise-grade software is becoming a legacy approach (commonly referred to as ClickOps). Teams concerned with future-proofing their environment are increasingly looking to GitOps-friendly approaches for managing these systems.
For good reason, too.
ClickOps is becoming the past
Configuring your environment using a ClickOps methodology has some benefits, but there are also risks. Anyone on the team with the proper permissions could make an error in a configuration and break core functionality. This fact presents clear and obvious problems, especially as the organization scales.
The last thing any admin wants is to be the team member that takes down some aspect of a system for any stretch of time. In those moments, every second is critical. Clicking through a web frontend to troubleshoot which dependency was broken or which group was removed, can be a complicated task.
This is where Infrastructure as Code (IaC) and GitOps approaches really earn their place.
Infrastructure as Code is the future
As more organizations learn about things like IaC, they are seeing the benefits. The ability to implement changes via code rather than relying on administrators doing ClickOps has been a serious game changer.
In a GitOps approach:
- A desired state is defined, and the file is committed to a Git branch.
- From there, a pull request is submitted to initiate the following workflows:
- This is followed by a sequence of merges to a branch where an automated action implements the change in Jamf Pro.
These techniques can also be used to move a change through test and user acceptance stages before anything happens in production where it will impact an entire fleet. Defining configuration as code allows code review, approval and pull request workflows in much the same way as professional software development.
This means your environment becomes testable, repeatable and scalable. Also, it provides a path to roll back to a previous version if a change causes unexpected issues – drastically decreasing the time between discovery and resolution.
Said another way, you can rapidly iterate and revert without having to comb through a user interface alongside documentation to understand where the failure occurred. For more on how we’ve built out Infrastructure as Code approaches internally at Jamf, as well as some real-world use cases from Vanguard, please check out our session from JNUC 2025 in Denver, called “Infrastructure as Code with Jamf.”
Why Terraform?
Terraform is a very powerful tool in the IaC world because it’s nimble and can be crafted to map to any API that you’d like it to talk to.
Currently, there is a community-backed Jamf Pro provider originally created by Deployment Theory and contributed to by Jamf. Additionally, we have even built our own providers for our security platforms as well as building a new provider for the Jamf Platform API.
We have documented these pieces and will continue to update this in the future on our developer site.
Key takeaways
Although ClickOps methodologies still exist, organizations are exploring software development practices as alternative approaches. These organizations are starting to see that the benefits are quickly becoming a necessity, such as:
Our environments are growing and, with that, comes more complexity. Put simply: maintaining an environment is complicated. While GitOps and Infrastructure as Code are new skills for most administrators, once you’ve learned the methods and realized the benefits, you won’t want to go back to ClickOps.
Part 2 of this series is coming soon. It will be focused on getting you up and running with a simple Terraform project to show you the ins and outs of Infrastructure as Code with Terraform and Jamf.
