The process of updating software in a large enterprise environment can be grossly under estimated. With the remote delivery tools available in the market today, perception is that patching and software update processes have become almost trivial. In reality, if the job is to be done properly, the actual install is only a small part of the work required.
The correct process should be one of testing the upgrade in your production environment, construction of the delivery package, testing of the automated distribution process, organising the required outages, then processing the package rollout so as not to affect your network infrastructure if you have remote offices.
Reading each of those steps you can be forgiven for thinking the process still seems a little trivial. However each step has the potential to be hours, if not days of work, depending on how critical the application to be updated is to your company’s operations. The first step of testing the patch or upgrade in your environment can be time consuming.
In a Utopian world we would all have a Test Lab setup as an exact replica of the production environment in an over air-conditioned room somewhere in the building. This test lab would be at the exact level of patching as production and therefore allow us to simply install the patch on a test machine, observe the results as we test for any conflicts and put a big green tick in the “Pass” check box.
However, back in reality, the majority of enterprise technicians have to contend with test labs that have had all manner of patches, trial software installs and fault replication tests performed on them. These labs are then left to limp along in a less than optimum state like some computerized Frankenstein until the next technician needs its services. Getting a lab back to an operational state can be a technical challenge in itself and has the potential to absorb large amounts of time. If you can factor in this potential delay then some of the stress associated with deadlines can be avoided. Unfortunately, with the regular streams of software releases seen in today’s fast paced development environment, it is rare to see an upgrade or patch cycle treated like a project with allocated time and resources. Instead they are seen more as a break/fix scenario with emphasis on ‘ASAP’ to mitigate or rectify a current outage or application bug.
Frankenstien image source: mskyDOTtv
Once the test environment hurdle has been cleared, the process of testing a new patch to make sure it plays nicely with the existing applications can begin. This is where the beauty of an SOE (Standard Operating Environment) becomes apparent. Knowing that any PC which has testing carried out on it, is an exact replica of the fleet you are about to distribute too, can be reassuring. However few business units will allow themselves to be dictated too in regards to software they can use.
Generally there will be company-wide core applications, or Tier 1 apps. These will be on every PC, and as the name suggests, are the most important applications. These types of applications are usually very popular and there is a good chance that any patches required have already had any potential compatibility problems highlighted by the manufacturer.
It’s when we get down to the specialist applications that are used for specific functions within the business unit that we start to run into unknown or yet to be discovered conflicts. In addition to potential unknown conflicts there is the challenge of finding someone well versed in using this specialist application to be able to test every function required for daily operation. This person is often referred to as a Power User. If you manage to secure the services of one of these fantastic resources, hold onto them like gold. They can save you hours of testing time by being able to quickly and efficiently put an application through its paces. This will leave you with a great deal of confidence when it comes time to pull the trigger on the software updates in a production environment.
Bug image source: gui.tavares
With the patch or update successfully tested in as close to production environment as possible the work on testing an enterprise wide delivery method can begin. Most companies with sizeable computer fleets will already have a system in place to deliver software and computer images en masse. Therefore it is important that any required updates are tested to install successfully in the many different scenarios that may be in use. This includes remote users, Occasional users, Non-standard and standard users. Ideally any patch or upgrade should be invisible to the user or at least never prompt them for an answer during installation. Apart from requesting a scheduled reboot the user should be oblivious to any change. Of course this is impossible with a complete software version change or Operating System rebuild, but these types of upgrades are a whole different situation that will hopefully fall under a dedicated project. Upon completing the delivery method testing across all current scenarios the technical challenges is all but complete.
Most enterprises will have well established maintenance windows that will need to be adhered too when the patch or update can be pushed out. As soon as an available time slot comes up and the automated installs are scheduled, it’s time to return to your desk and continue with your MP3 tagging “project” until the next patch arrives or those ‘unknown’ bugs crop up in your latest rollout.
