-
Notifications
You must be signed in to change notification settings - Fork 4
Caveats
While this workflow does a decent job with jamf and automating your package creation, jamf pro server object creation/modification, and automatically starts to update third party apps on your fleet, there are caveats in this that need to be pointed out.
Jamf lacks the ability to do any sort of version comparison when it comes to greater than or less than. It can only compare versions by if it is version 1.1.1 or it is not version 1.1.1 which isn't very helpful when it comes to apps that self update and users that update apps with out IT intervention.
To mitigate this I have my AutoPKG computer, execute all jobs every 12 hours. Most self updating prompts in macOS apps do not prompt more often than every 12 hours. You could increase this frequency as well to adjust for this. I thought about using something like LooseVersions() in my Python code but I have not gone down that road just yet. I will probably look at deploying something like Munki versus adding all the extra engineering to jamf, but that will be phase 2 type stuff. This repo is my phase 1 of automation.
So, you run the risk of possibly downgrading a user with an older version if your AutoPKG process is not as fast as your end user, or your inventory collection schedule.
If your users never quit their apps this will not actively patch. I designed it this way because I cannot possibly test every state of every OS and every App if an update gets applied while it is running. So, by design I am avoiding this entire situation, sans when security tells me I must force update an application. The prompts are there for this reason, but my opinion is end user training is the best method to get users to quit applications when not in use.
While the end to end automation is nice, there are no unit tests, or CI/CD tools involved to really vet and pass a new package and workflow coming into your environment. The JSS Importer can, however, be easily altered to point to a different environment. A better practice would be to point JSS Importer to your test environment, let it run the full automation, do your testing, then just point it over to your production.
An even better practice would be to integrate this into some sort of CI/CD track, which is completely out of scope of this repo, but it is something you should consider.