Testingwithrandomnumbrers.md

Generated Random Number.xml

<?xml version="1.0" encoding="UTF-8"?><extensionAttribute>
<displayName>Generated Random Number</displayName>
<description>This will view the generated random number</description>
<dataType>string</dataType>
<scriptContentsMac>#!/bin/bash&#13;
# Generate a random number. This is used best when you want break up computers into groups for testing.&#13;
# Use with a reporting app to read the number and sort your computers&#13;
# For an example of that, refer to:&#13;
# https://gist.github.com/matthewbodaly/7a6cfabb74d896ca609bca9f62226463&#13;
#&#13;
# v2.0.1 - Matthew Bodaly - Sept 2021 - Fixed spelling&#13;
# Use case: All this script does is generate a random number between 1 and 10. From this point, an extension attribute (if you have Jamf Pro) reads the digit&#13;
# Once you have a random number, you can shard the fleet.&#13;
# For instance, a smart group made of random number 1 would have about 10% of the total fleet.&#13;
## --- EXTENSION ATTRIBUTE&#13;
result=`grep -m1 -ao '[0-9]' /dev/urandom | sed s/0/10/ | head -n1`&#13;
echo "&lt;result&gt;$result&lt;/result&gt;"</scriptContentsMac>
</extensionAttribute>

testingrandomly.md

Testing is super important to figure out if something that would be installed / changed / updated on every endpoint works well. While it’s impossible to know about every software and hardware interaction, testing change deploys or slowly applying them to a fleet is one way to ensure that a deploy goes off flawlessly.

For this method and process, think of a change that would be made to every computer and if something went wrong, there would be a high level of risk associated.

Method

1. Test on your computer. Make sure the change can be observed and successfully works on computers you can directly control.
2. Test with a pair. Make sure the change can be observed and successfully works on computers you or your team can directly control.
3. Test with a small group. Gather feedback and make any changes or tweaks. If this is successful, consider sending out wide communication about the change to the affected folks.
4. Send change in groups to the entire fleet.
5. Gather feedback. Wash, rinse, repeat.

This method is known as sharding or parallel testing. With this method, break the entire group into smaller groups and make the changes in parallel to the group before applying the change to the group as a whole. This could be combined with A / B testing which applies a different change to different groups concurrently before making a change to the entire group.

In the process below, macOS computers are programmatically grouped into 10 groups. This means if you apply a policy to Random Number 1, you’d be applying the change to 10% of all computers.

Process

macOS

This method uses JAMF and extension attributes. Other platforms use other methods or might not support this way of doing things. Changes are made by policies that are scoped to groups of computers. Generally, policies are assigned to either all computers or a specific set of computers (based on conditions). Assigning to a specific group of computers might not have a large amount of risk to it, but using the All Computers group is risky as it's a large number of devices spread across many time zones.

1. Create your policy, assign to a few static computers to do initial testing. Here are some best practices for the policy creation:

• While testing, do not include an inventory component. The random number is based on inventory runs and extension attributes meaning the group contents will be updated over time.
• While testing, do not use a recurring trigger. Schedule a policy to run one time (any type of trigger) and go through logs to verify that the policy was sent successfully.

2. Scope to groups named random number in them.
3. If the policy is successful at deploying to one shard, update the scope to include more of these groups.
4. Once the policy has been successfully deployed to all random number groups, update the policy scope to the All Computer Group, remove the random number group, and add recurring triggers or inventory triggers based on your needs.

How it works

Every inventory run, a random number is generated via an extension attribute. Once the number is generated, smart groups read the number and sort computers into groups. Computers can only be in one group at a time and are updated every time inventory is run. In most cases this is daily.

The extension attribute I'm currently using is roughly based on this script + extension attribute combo https://github.com/matthewbodaly/macOS-Scripts/blob/master/randomnumber.sh. I realized I no longer need to write a file to disk so have the coding only in the extension attribute. It is attached. There's likely a better way to do this.