Jul 14, 2009
Hello all. Its been a while and we’ve been busily working on various features for deployment and provisioning. One area that has seen a fair bit of attention lately is the workflow for updating Creative Suite products. Ravi Prakash Singh is the lead development engineer on the new updater team. Below he talks about some of the design goals and solutions used for the next version of the updater workflow. – Eric
Adobe’s updater technology through CS4 is known as the Adobe Update Manager (AUM.) AUM has a long history of various problems. Our user community has been vocal about the number and types of problems experienced through AUM. In the next instance of the Creative Suite, we intend to provide a different update experience that should address a number of the most egregious problems discussed thus far. In particular:
* Failure of an update to successfully apply to a user’s system
* Failure to adequately roll back a partial or failed update, thus leaving the user’s system in an unusable state
* The update process interferes with users trying to get their own work done
When we started out the design for the new Adobe Updater we set a few simple goals:
* Make the Adobe Updater install the updates successfully and if the updater fails, ensure whatever was installed as part of updater is rolled back and the machine is back to its orginal state.
* Make the Adobe Updater non-intrusive. The Adobe Updater should not interfere with the user’s tasks by poping dialogs in middle of your extremely critical workflows. It will not be an in your face application.
* Make sure the Adobe Updater when running does not hog your CPU cycles.
* Using the Adobe Updater should be a pleasant experience.
* Checking for updates is silent and the notification for available updates is clean and unobtrusive.
* Provide ways for system administrators to turn-off updates completly. Secondarily, we also want to enable easier management of updates by system administrators.
In order to achieve the desired reliability, sensitivity to system CPU cycles and roll back ability, the updates themselves will use the exact same deployment engine as the original installer. In past versions, the updater was managed by one team while the patches and installation were managed by another team. We’ve brought these teams together into a single organization for better cooperation between them. The technology that lays the bits down on the users’ systems at install time will now be the same technology that updates the products post-install. This solution simplifies the implementation and makes it more robust by having consistent use of installed component databases and deployment strategy.
In order to ensure the updater is non-intrusive, we intend to have the client machine know about each update within 24 hours of that update being advertised by Adobe servers; however, users are notified either when they quit their app (not at app launch or in the middle of application use) or by an unobtrusive notification elsewhere on the system (e.g. a badge on the right side of the menu bar on a Mac.) There are two main parts to this approach:
1) Let the client machine know about updates as soon as it is hosted and made available by Adobe. To achieve this goal the updater will not be linked to Adobe product launch. Instead it will run as a scheduled activity independent of any product. During installation of an Adobe product, the Adobe Updater will be added as a task to the Task scheduler on Windows and as a Launch Demon on Macintosh. This step will help the updater perform a scheduled check for updates in silent mode. Such silent checks should occur at 2:00 am.
Minimal resources are used to check for updates. If you are not online at 2:00 am no connection will be initiated. The updater will wait until the following day at 2am to check again.
2) Once the update is discovered and downloaded, notification for the update is non-intrusive. In particular, there is no popup dialog that tells you an update is available and requires your attention. The notification itself will depend on the platform; but, will be somewhat similar to other status notifications on that platform. For example, on Mac the notification will likely be a badge on the right side of the menu bar indicating the status of an update. This is much like the status of other Mac services such as Time Machine or instant messaging clients.
If the user takes action on the notification then a dialog will appear that lists what applications have updates available and provide easy access to user preferences. As in CS4, all updates are cumulative. This means you should not see one update after another in serial for any given product.
There are a few more items to touch upon here:
Updates UI – When launching the updater, it will be possible to explore each product with an update to see which updates are pending, a description of the update and what other products are affected by those updates.
Notification UI – When you express interest in an update notification, a dialog will display showing which Creative Suite products have pending updates. It will be possible to explore each product with an update to see which updates are pending, a description of the update and what other products are affected by those updates. It is also possible to access user preferences from this dialog.
Preferences – To let users control Updater behavior, there will be preferences options for
a) Turn on / off menu notification
b) Disable/enable Auto updates for CSXS Services.
c) Auto download/install updates.
Enterprise Support – Support for volume deployments include the ability to turn off the entire update system at install time as well as the above mentioned user preferences. In addition, we have tentative plans for post-ship delivery of instructions on how to host Adobe’s patches directly on your own servers. This enables end users to use our Adobe Updater but recognize, download and apply patches directly from volume customers’ own servers.
Scheduled Check for Updates – Update checks would run as a scheduled activity; on Windows as a task (in the Task scheduler) and on Mac as a Launch Agent (via plist in ~/Library/LaunchAgents). This check would be performed on daily basis at 2:00 am. If the system is asleep at 2:00 am, then the next check for an update would occur when the system awakens. If system was shutdown at 2:00 am then update check would be performed at restart/user logon (via Run key on Windows and plist in /Library/LaunchAgents on Mac). If still there is a missed update check in past 24 hours, product launch would ensure that an update check is scheduled to occur after 2 hours.
Non-Admin Users – User’s without an admin account can now install the update from normal user account with the typical admin password prompt. This will be possible for all platforms except Win Vista where UAC has been disabled.
Hope the insight in to the new Adobe Updater is useful and provides some information on what we are planning for the next revision. Your comments and feedback are most welcome and we look forward to an healthy discussion and do any course correction if needed.
Updated: Based on the comments below, there have been three updates above. Two sections were added to clarify behavior (Scheduled Check for Updates and Non-Admin Users.) Further detail has been added to the preferences section as well. —Eric