A year ago, we were managing Macs the way most orgs still do: one shared Mac, VNC’d into, running a local copy of Munki with no real version control or workflow isolation. Git was an afterthought. Deployments were manual. It worked—until it didn’t scale.

We’ve since inverted the model. Git is the gate. CI is the deployer. Each admin works from their own machine. And the Munki repo is fully DevOps-native.

Here’s how we rebuilt everything using Git, Azure DevOps, Service Bus, pipelines, local caching servers, and inventory automation—all open source and cloud-integrated.

From Manual to DevOps

The legacy flow was:

• GitLab running on-prem
• One shared Mac as the deploy point
• One central repo, updated by many hands
• No pipeline. No hooks. No approval gates.
• Everyone stepped on everyone’s toes

Now we have:

• Azure DevOps Git repos and pipelines
• Git hooks that upload/download packages automatically
• Separate working copies per admin
• Local caching servers that sync intelligently
• A full CI/CD system that integrates with inventory and deploys via pull requests

Architecture Overview

We’ve split this into two core flows:

Munki DevOps Infrastructure

• Admins commit to a shared Azure DevOps repo with manifests/ and pkgsinfo/
• Git hooks (post-commit/merge) run azcopy sync to upload or download packages
• A pipeline (munki-push-production.yml) builds catalogs and updates Azure Storage
• Local caching servers (like PLUTO and PROTEUS) are notified via Azure Service Bus
• A daemon listens for commits and runs git pull and syncs assets
• CDN serves files globally or from on-prem caches
• It’s fast, redundant, and observable

Inventory-Orchestrated Enrollment

• A polling script checks Snipe-IT for inventory changes and builds new CSVs
• CSVs are committed to Git → triggers DevOps pipelines → runs enrollment-munki, enrollment-intune, enrollment-sharepoint, and more
• Each system (Munki, Intune, Fleet, TDX, Papercut) gets updated data
• Pull requests are the approval gate
• Everything is traceable, auditable, and CI-driven

Resources

• Presentation Repo: github.com/rodchristiansen/munki-devops

Want to talk shop or ask questions? Connect with me on BlueSky or on the GitHub.

It worked—until it didn't.

We moved from running local scripts on a shared Mac to each admin working from their own local repo, committing changes through Git, syncing packages with az git hooks. We used to push changes first, then capture them in Git after the fact. Now, Git is the gate. Commits and PRs drive the entire process. Pipelines run automatically, and the cloud becomes the source of truth. Our local caching servers listen for updates—pulling down only when there are changes—fully inverting the workflow into something distributed, reliable, and scalable. All of it version-controlled. All of it traceable. All of it running on infrastructure provisioned with Terraform.

Every config, every profile, every software assignment that matters tracked in Git. It’s CI/CD deployed, reproducible by design, and logged automatically for traceability.

What This Blog Is About

This blog is about the journey—the migrations, the patterns that emerged, the decisions that held up, and the ones that didn’t. And about the new tools and ideas I'll be building and using along the way.

If you work in endpoint management with DevOps, you’ll find deep dives into:

• CI/CD pipelines that manage device tools, states, and configuration
• Every cloud resource under Infrastructure as Code with Terraform
• Inventory systems that drive deployment logic
• And Git at the center of it all

As I now manage both macOS and Windows endpoints, I’ll be writing about how I'm creating a cohesive, mirrored management system—where both platforms are driven by open source tools, DevOps, and Git, and where admins speak the same language on both sides.

Focused Systems. Grounded in what actually works and scales. Very opinionated.

Let’s get to it.