Cjoseph explained some of the step, however I am going to add some more comments. First off, there are two ways to automate the upgrade process; Live Upgrade or preloading the controllers and APs and then rebooting them.
In order for live upgrade, also known as in-place upgrade to work, a Mobility Master is needed (which you have), controller clustering needs to be configured (which you did not state that you had or not), and the AP deployment must be dense enough. During the upgrade process, each AP will be brought down to reboot with the new OS, and any clients in the area where that AP operates will need to be able to connect to another AP nearby in order for the live upgrade to function as expected.
When live upgrade is initated, AirMatch and the Cluster Upgrade Manager will work together to perform the task. AirMatch will group the APs into partitions (just groups). After the partitions are assigned, each of the MCs will copy the new OS image to one of their partitions. This is not done all at once to ensure network/MC performance is maintained. After all fo the MCs have downloaded the image, one cluster member is rebooted with the new image. When this happens, the APs and users that were connect to that MC will transition to their standby AP anchor controller (S-AAC) and standby user anchor controller (S-UAC). After the first MC is rebooted and running the new OS, the Cluster Upgrade Manager will preload the new OS on some of the APs and reboot them (the partitioning that was done earlier is used by the manager to make sure that RF dead zones do not occur). When the APs boot with the new OS, they will connect to the MC running the new OS. This process is continued one controller at a time and a grouping of APs at a time, slowly migrating the controllers, APs and users to the MCs running the new OS. Ultimately, all of the MCs (except one will be upgraded) and all of the APs will be upgraded. Then that final MC will be rebooted. NOTE that this process can and will likely take hours.
The other way of automating and speeding up the upgrade process is to include the AP image preload (this process is totally unrelated to live update, this is a different method that has existed since 6.x). First, you need to configure a file server (TFTP, FTP, or SCP) and download the new OS to that server. Then manually upgrade the MM with the new OS and reboot it. Next, specify an upgrade profile; this is just setting the client settings (such as if you are using FTP) on the MM, so that any time you need to copy the OS, you don't have to re-enter the credentials (these settings work for any tasks that access the server). This can be configured from Configure-System-Profiles-Controller Profile-Mgmt Config-Upgrade or from the upgrade-profile CLI command. At this point you will use the "upgrade managed-device" CLI command to copy the new OS to the MCs but DO NOT reboot the MCs. The process works well, but the command can be tricky if you are not careful. Here is an example of the command. This example is not using the upgrade-profile preset FTP settings.
#upgrade managed-devices copy fileserver ftp 192.168.240.31 david /ftp-files/ force-version 8.4.0.2_70086 all partition 1 schedule 2019 08 31 22 24 00
After the MCs are upgraded (BUT NOT REBOOTED), you can then preload the APs, they get their OS from the MCs which is why the MCs must be preloaded. Here is an example of the pre-load command for the APs connected to MC 7005-9. Note that you can preload a group of APs, HOWEVER, you get one preload task per MC per boot. You can't preload one group of APs and then another group of APs. One preload.
#ap image-preload activate all-aps partition 0 max-downloads 5
You can see the AP preload status using the following command
#show ap image-preload status all
I hope this helps. This is not all of the details but most of the tasks. I've done this extensively when writing about it (15 upgrades in one day) in order to document it.
Good luck,