How do you document your JAMF Policies?

We download copies of policies, configuration profiles, and EAs, and commit them to a GitHub repo. There are a few tools for doing this, check out @rtrouton's blog and git2jss.

Since I have jumped into an place that has not documented anything, I understand the need to document everything Jamf related. I assume that you are looking to document why a policy was created and what it does?
If you click on the History button for the policy, there is an Add Note button. I have made it mandatory to put the details of the Policy here. I also require the Description field in Extension Attributes and Notes in Scripts. Minimum required information: what this does, why it was created, who created it and for Apps, version number.

I'd agree with committing aspects of your environment to GitHub. We've also started mirroring our production environment in our test sandbox. This provides a bit of redundancy, and it also lets other team members mess around without the threat of breaking anything.

Thanks Emily. I'm not sure I'm finding the right stuff. Is this just for syncing the scripts? I appreciate the help.

I'm self admittedly not the greatest at documentation, so I aim do to it more through organized implementation than anything else. Policies, smart/static groups, config profiles all follow a particular naming convention that makes them easily identifiable when read and grouped accordingly. Scripts should be as descriptive with title as possible, including category, and comments there will always help. Round this all out with regular - usually weekly cursory and quarterly in-depth - reviews and it's all pretty well descriptive.

@ferrispd the idea is you copy down policies, profiles, EAs, and scripts, and have them committed to an internal Github repository. Our attitude about it, loosely, is that the code is the documentation. You can include readme files in the repos that have an overview of where they data comes from, how it's used, etc., so it's all centralized.

Once comfortable with the concept of using GitHub with your Jamf instance, you can integrate git2jss with a CI/CD tool so that changes go through pull requests and reviews, rather than just making changes directly in the webapp. It'd be nice if Jamf had a built-in integration with GitHub, but for now git2jss is a nice alternative.

Like many organizations, we've been using Slack for internal communications. I've build channels like #scripts, #extension-attributes, and #profiles on our local Slack, where I can drop these downloaded files, or paste in as code snippets. Allows for commentary, threaded and contextually-aware discussion of said policy, script, etc. This isn't as flexible as Git, but since I'm the only one writing any of these profiles, scripts, that collaborative type of versioning isn't really necessary in my environment. Using channels in Slack was a natural extension of the communication my team has already been doing.

@tomhastings I can't locate a History button at all in any of my policies. Is that feature a recent introduction? We are using v10.7.1 currently.

@ianmb When you open Jamf > Computer > Policy and click on a policy, you don't see a History button at the bottom right of the screen??

@ianmb If you look at Settings->System Settings->Change Management in your JSS do you have Use Log File enabled?

@sdagley Yes, enabled and it points to C:Program FilesJSSLogs (as we run Jamf Pro on-premise on a Windows 2012 Server).

@ianmb So much for that theory. I'm using on-prem 10.7.1 as well, and I have the History button as shown in the image @swhps posted above.

@swhps OK, many thanks, I see it now; I was only looking through the options on the left hand side (doh!)

I've started adding some notes but there doesn't seem to be the option of editing or deleting notes that I have created in there, is that correct?