Capistrano VS munki

If you don't want to go down the NFS share route then Capistrano is a useful tool if you're willing to write a little bit of ruby. It comes with some built in goodies like rollbacks. It's an oldie (pre-dockerize everything), but still useful.

https://github.com/capistrano/capistrano

You can start by deploying from your machine to simultaneously get it deploying across all your servers, then I'd consider having a CI/CD pipeline take over and run Capistrano for you.

- Integrate automation deployment: [capistrano](https://github.com/capistrano/capistrano)

Integrate automation deployment: capistrano

The deployment process generally includes making the new version available, directing traffic from the old to the new version, and stopping the old versions. Capistrano has been doing this since 2006. However, what makes Kubernetes deployments better is the minimum number of pods required, and its rollout strategy minimizes or eliminates downtime. For example, a rolling update strategy can ensure new pods gradually replace old pods with configs like maxSurge and maxUnavailable. Because this is done in a declarative way, as a user or operator, you only need to ask Kubernetes to apply a given deployment and Kubernetes does the rest. Next up is the Kubernetes config map.

[1] https://github.com/capistrano/capistrano

Capistrano

What I had considered was writing a deployment script where upon successful build in a separate folder, it'd swap out the deployed folder, similar to how Capistrano works. It has a "current" folder and it'll build in a temporary folder and then replace the symlink to a newer build.

capistrano with plugins for deployment

deployer is a deployment tool written in PHP. It comes with "Zero Downtime Deployments" out of the box and can be extended by writing simple PHP code. (capistrano would be the equivalent in the Ruby world).

Capistrano, if you like Ruby.

In the non-MDM tool space, look into Munki https://www.munki.org/munki/

this experience is an indication that the opco didn't hire the right expertise. If the numbers you quoted ie 30k desktops, 50k total were not macs, it's clear that the org didn't have the kind of mac experience needed to manage a a new org with all macs.

It's entirely possible for administration of macs.

Start networking/asking around with places like Disney or Pixar, etc which have a large amount of graphic artists using macs. For example, from Disney https://github.com/munki/munki gets you to a certain point.

Other tools like Kandji (lightweight) and the 900 lb gorilla in the industry Jamf gets you the other management / administration bits needed

If this opco that you referred to never got a Jamf rep to work with them and to try out their (yes, very expensive) products, then this is mostly inexperience with the mac ecosystem.

There's a decent open source option: https://github.com/munki/munki

I got to use it at work at Meta (as end user), and it seemed to work quite well. They delivered Android SDKs/IDEs and a bunch of other things that I'd personally install through Brew with Munki.

Munki is not an MDM and I recently learned there's this project called Installomator that might help.

Or Munki

This is a feature of munki called default manifest resolution. Though I prefer to avoid this and explicitly set the client identifier for all devices.

another option is munki https://github.com/munki/munki, for the software update part,