ps
→
GitO
ps
Who are we & where are we today ?
Fully operational with Terraform
Every Jamf Pro change flows through a GitHub PR with no exceptions.
Over 1,500 resources under active management.
3 stage environment route to Live setup
All changes require a +1 approval from another engineer
Every change is versioned and can be rolled back
Gui access is read only, write access is restricted to break glass operations
Full mac@LBG team trained
Every Mac team member performs their day job with Terraform as the control plane.
Training artifacts released as open source
Currently up skilling our packaging and endpoint security teams.
Learning outcomes & what success looked like
Collaborate
On changes together; externalise domain knowledge from people's heads into self-documenting code. Reduce single points of failure and catch mistakes before they reach production.
Fast recovery
When something goes wrong the team can revert to a known good configuration. Because mistakes are recoverable, engineers make changes they would previously have avoided or escalated.
Team confidence
To implement changes using GitOps + Terraform and perform their role effectively. Any team member can pick up any change, make it → get it reviewed → ship it.
Read a plan before you approve it
Every engineer can read a terraform plan and predict exactly what will change before approving it. Every safe apply depends on this skill.
Knowing when not to use Terraform
Recognising when breakglass GUI access is the right call, and when to stop and ask for review.
Prove what changed, when and why
On demand, when asked by stakeholders or external audit.
Every change to production goes through a pull request
Zero manual console changes. If someone asks "how did Jamf Pro get into its current state," the answer is always "check the commit history," never "ask around."
Design conversations happen in PR threads, not in chat
Juniors review senior engineers' changes
"How did it get like this?" is answered with a commit link, not a meeting
New transferable skills
A safety net that makes mistakes recoverable
Reduced cognitive load (not having to make changes in different instances)
No single point of failure
Same engineering practices as cloud teams and same language
Cross team awareness of changes
Failures become learning opportunities and not blame
Collaboration without stepping on one another's toes
TF modules allow for self service consumption by sister engineering teams
Compliance and audit without a mad scramble
Governance without slowing delivery
Deployment guardrails that scale beyond one team
An engineer counted as trained when they could take a real change from branch to production unaided.
TODO: confirm the bar the team actually usedEveryone becoming a Terraform expert · zero incidents · the end of Jamf GUI knowledge
TODO: confirm real non-goalsHow we ran it
One engineer, moved into the DevOps CoE
Not a course and not a shadowing arrangement. A posting, long enough to pair macOS and Jamf Pro domain depth with GitOps practice in the same person.
Training materials, written together
The CoE brought the Terraform and Git content; the seconded engineer put it in Mac language and cut what did not apply.
Sessions designed for their medium
In-person and remote sessions planned separately rather than one deck delivered twice.
Hackathons and homework
In-person labs built on tasks the team already recognised, with practice set between sessions so nothing decayed in the gaps.
Migration waves, run by the same engineer
Training carried on past the fundamentals. Running the waves kept the reasoning behind each migration decision inside the Mac team and taught advanced Terraform on the real estate.
Full handover
The Mac team owned the control plane, the materials and the reasoning.
What worked
Paired programming
Real-time knowledge transfer. Engineers learn faster from a peer than from documentation alone. Effective pairs that transfer knowledge well share a disciplined (one topic at a time, staged clarification, deliberately pushing context rather than only answering questions asked) approach.
Scenario-based hack labs
Interactive, visual, hands-on learning beats abstract exercises, always. This is especially true when learning git for the first time. Engineers learn the 'why' immediately and hands on helps build a mental model quicker. Learning scenarios should be tied to real life team operations. Provide sequenced learning before open-ended practice.
Ability-grouped learning cohorts
Grouping engineers at similar skill levels keeps pace right, no one gets bored or is left behind.
Safe lab environments
Ensure that you have dedicated non-prod sandboxes for engineers to experiment freely and without fear of breaking production. Do not YOLO in prod!
Secondments to DevOps teams
Team shadowing (even on other tf providers) gives real grounding and broad exposure.
Good documentation
Make use of the terraform registry for known good working examples for each resource. Read our and others open-sourced training and reference implementations for your own learning or to build your own syllabus
Patience. It takes time…..
The sheer size of conceptual surface area that needs to be covered is large.
What didn't work
144 hours of learning, spread across six months
Mixed-ability cohorts
Pace wrong at both ends. Prior coding experience predicted success, not Jamf Pro familiarity or age.
Theory before the hands-on
No mental model formed. In one ear and out the other.
Step-by-step tutorials
Workbooks devolved into copy-paste. Completed, not retained.
Shaped like a reference manual
214,645 words of good content, written to be complete rather than to be learned from.
Gaps we could not close
Our internal developer platform was not ready and online when engineers needed it.
Interest wandered
Four weeks of content over six months. The hours were about right; the calendar was not.
Effort stayed invisible
Nothing showed who had genuinely put the hours in until after handover.
What replaced it
3,778 words: two modules and four labs, one of them deliberately broken. 57x smaller.
TODO: verify quote
Creating the conditions for success
Psychological safety
Make it explicit. Say it out loud, early, and more than once.
Don't assume it already exists because the team seems friendly.
It has to still hold the week somebody breaks something that matters.
Stakeholder buy-in first
Get non-technical stakeholders and senior leadership bought in on the priority before you start. Ours were slow to 'get it', which cost early momentum.
Complete pre-reqs before workshops
Engineers who skipped pre-requisite learning held back their whole cohort. Gate attendance on it, no exceptions.
Tight loop: learn → practice
Long gaps caused rapid knowledge loss. Keep days, not weeks, between learning something and practising it for real.
In-person training and pairing
Remote worked for self-paced pre-reqs, but pairing and labs were dramatically better face to face.
Partner with your platform-tooling owners
You'll need whoever owns Terraform and GitHub for access, guardrails and troubleshooting throughout.
Expect the dip
The team gets slower before it gets faster. Set that expectation up front, so early friction reads as part of the plan. TODO: how long
Learning priorities by role
Junior engineers
Breadth over depth- Environment working: editor, extensions, Terraform on PATH
- Git basics and branching fundamentals
- Terraform basics: read a plan and predict what it changes
- Can they write a working PR and apply a change safely?
Engineers
Applying it daily- Own modules and everyday resource changes end-to-end
- Review junior PRs; raise their own with confidence
- Read the Jamf Pro API docs when the provider docs are ambiguous
Senior engineers
The escalation point- Advanced Terraform: for_each, dynamic blocks, modules
- Release management: tagging, promotion, rollback
- Strong Jamf Pro API understanding
- Unsupported resource? API gap or provider gap, and is it worth raising
- Pairs with and mentors juniors; reviews and unblocks
No DevOps function
Design, build and maintain the platform and manage the Jamf Terraform workflows
- The platform is yours too: the toolchain, the runners and the state backend
- Nobody provisions a repo for you, so the whole environment is yours to stand up and keep alive
- Fewer people, so one person often spans all three roles at once
Specialist teams either side
Consume the platform, inside its guardrails and manage the Jamf Terraform workflows
- You still own the branching strategy, the triggers into your environments, merges and releases
- Repos come from platform templates, every PR needs a second approver, and you cannot disable Checkov or the linters
- You still need to know how the platform is designed. But your workflow will have to conform with wider company standards
The learning pathway that worked for us
Release please
tf registry
Each milestone is practised for real before moving right. No skipping ahead.
The learning timeline for a typical engineer
What engineers need to learn
Environment
- VS Code / JetBrains / Neovim + terminal
- Git ext: inline diff, blame, staging
- Editor for commits; .editorconfig
- terraform-ls: complete, hover, defs
- Format-on-save → terraform fmt
- YAML ext with schema validation
- Confirm TF binary is on PATH
- pre-commit: fmt · tflint · secrets scan
- tfsec / trivy security scanning
- Go: gopls, golangci-lint (if providers)
- SSH keys / credential helper
- .gitignore template pre first commit
Git
- Version control & the distributed model
- Git vs GitHub / GitLab; why it matters
- git config & init; working → staging → remote
- add · commit · status · log · diff
- .gitignore for artefacts, secrets, env files
- Branch, switch, merge (ff vs no-ff)
- clone · push · pull · fetch; SSH keys
- Pull requests, code review, issue tracking
- Resolve merge conflicts confidently
- Rebase vs merge; tagging & stashing
- Revert / reset, history rewrite, recovery
- GitHub Flow team branching strategy
- Git 3.0: SHA-256 & reftable (late 2026)
Terraform
- IaC principles & declarative config
- Install Terraform + provider CLI / creds
- init → fmt → validate → plan → apply → destroy
- Providers, resources, data, variables, outputs
- Dependency graph, version pinning, lock file
- Variables (types, validation), locals, functions
- count & for_each for dynamic resources
- Reusable modules with inputs & outputs
- Local vs remote backends; state locking
- Drift, terraform import, state moves
- Workspaces, projects, VCS & CLI runs
- Variable sets, dynamic creds, RBAC
- Policy-as-code (Sentinel), drift detection
- Terraform Associate 004 (live Jan 2026)
- Authoring & Operations Professional
GitOps
- Git as the single source of truth
- Desired vs live state & reconciliation
- Principles: declarative, versioned, pulled, reconciled
- Change flow: branch → PR → plan → merge → apply
- Every change via PR — no manual / GUI edits
- CI/CD pipeline: fmt → validate → plan → apply
- Drift detection & alerts on manual change
- Keep secrets out of code (Vault / SOPS / KMS)
- Branch protection & required status checks
- Multi-team PR review & CODEOWNERS
- Audit trail: commit → author → ticket
- Jira / ServiceNow tickets + Slack / Teams alerts
- Version tagging & semantic releases
- Environment promotion: dev → stage → prod
- Rollback by revert & re-apply
- Dependency & module version pinning
- Policy-as-code guardrails (OPA / Sentinel)
- Cost estimation on PRs (Infracost)
- Self-service via workspaces & RBAC guardrails
- Private module registry & versioned publishing
What lands well in the room together, what lands well remotely
In the room
- First exposure to a conceptYou can see someone is lost before they say so. On a call they have to interrupt everyone to admit it, so they don't.
- Debugging someone else's broken config for a new conceptSomeone is looking at your screen the second you go wrong, not ten minutes later once you have built more on top of it.
- Pairing people up for the first timeTwo people who don't know each other won't share a keyboard honestly. That trust builds in the talk around the work, which is hard to build initially when remote.
- Game days, hacks and scenario labsThe atmosphere does the work. Ideas bounce, everyone hears everyone, and a team comradery forms while they solve something.
- The week someone breaks somethingOwning up is much harder to a screen. In the room everyone watches the reaction be help rather than blame, and they speak up sooner next time.
Remote
- Pre-requisite training modulesInstalling a toolchain has one right answer, so there's nothing to gain from an audience. But without a deadline it doesn't get done, and learners turning up unprepared slows the whole room down.
- Recorded expert think-aloudA recording can be paused, rewound and watched again at 11pm, which a room cannot. What it cannot do is answer a question back.
- Co-editing, not screen sharingIf both people can type, remote pairing holds up. If only one can, the other is watching someone work and learning very little.
- Async PR reviewThis is how review works in the job anyway, and PRs by their nature need time for reflection and analysis.
- Follow-up clinicsVideo drains people far faster than a room does. Keep it under an hour with a break in the middle — past that they're still on the call but not learning.
Match the content to the moment
Guided, hand-held, and it has to work every time. If step four fails they conclude they can't do this. The smallest thing that gets someone to a working PR.
Clone to merged PR, end to end
The steps and nothing else. Assumes they already understand it, so no theory, no explanation, no reassurance.
Promote a change dev → stage → prod
Scannable under pressure. A decision tree, not paragraphs — nobody reads prose at 3am. A different document from the runbook, even for the same system.
State is locked — what to do
Who to call, what not to touch
Read when they're calm, never when something is on fire. The reasoning behind the setup, and the decisions that were already taken for them.
What state is, and why drift matters
Deliberate failure somewhere that breaking it costs nothing. The one thing no document can do for you, and the one we got right.
Game day: a smart group vanished
Louise's journey
Don't forget to train your sister engineering teams aswell
The typical learning cycle
Pre-work
Pre-reqs: videos, reading
Foundations
Core concepts + Terraform basics
Git & flow
Git, branching, pull requests
First real
First real-world task
Advanced
Advanced Terraform + DevOps
Independence
Solo delivery, mentoring others
~14 weeks (3.5 months) for a junior with no prior GitOps/TF experience — in-person cohort, real tasks from week 3.
Onboarding new starters without TF experience
Artifacts package
A new-hire pack: runbook index, architecture diagram, Git conventions, PR template, 'how we work' guide. Ship it on day one — don't make them ask.
Skill-gap assessment
A 20-min async skills check before they start — Terraform basics quiz + Git scenario. Results dictate cohort placement. No assumptions.
Assigned buddy
Every new hire gets a named senior buddy for 8 weeks — a peer, not a manager, who pairs, reviews PRs, and takes the first questions.
Hiring for the new world
Skills to hunt for
- Terraform (any provider) — concept transfer is fast
- Git + GitHub / GitLab — daily CLI use, not just GUI
- Any scripting — Bash, Python, Ruby — comfort in a terminal
- CI/CD pipeline experience (GitHub Actions, Jenkins…)
- API / REST familiarity — a great signal for IaC aptitude
- Open-source contribution — shows self-directed learning
Market signals
- TF skills are still emerging in the Mac/endpoint space — the pool is small
- Postings now list Terraform as required for senior Mac/MDM roles
- Jamf + Terraform experience commands a premium — the gap will widen
- Consider internal promotion — train your best Mac admins rather than competing for scarce talent
- Screen for aptitude over credentials — curiosity + scripting beats a CV match
Learning materials
Terraform Registry — deploymenttheory/jamfpro
Every resource, argument and example for the provider.
Terraform Demo Repo
Multi-environment setup with GitLab-flow and Terraform Cloud. Best-practice structure out of the box.
Terraform Training Repo
Built for workplace engineers with zero prior knowledge of git, gitOps and terraform.
Community & officialJamf Developer Docs — Terraform Providers
Jamf Blog — Getting Started with IaC Workflows
MacAdmins Slack — #terraform-provider-jamfpro
Neil Martin — terraform-jamfpro-starter
Colour system
Brand
CMYK 91 0 33 29
CMYK 100 0 27 58
CMYK 98 57 0 5
CMYK 0 0 0 100
CMYK 0 0 0 0
Accents & tints
CMYK 72 0 26 12
CMYK 81 49 0 4
CMYK 56 31 0 0
CMYK 0 58 69 25