UmbrellaX Services

ADVANTAGES OF THE UMBRELLAX APPROACH
The UmbrellaX tools provide just the right mix of automation and accessibility, so that the UmbrellaX Consultant can work with the software vendor’s development team, gather the required information and create a build environment that will run quickly and efficiently. 
 
 WHAT IS THE PROBLEM?
Building an installation package involves many skills – deciding what software to use to build the package, ensuring that you cover all possible target environments, integrating all the correct components (and replacing them when bugs are found!), being able to add in required 3rd-party packages where required, and being able to monitor the deployment process
• What installation builder are you going to use?
There is a bewildering array of products.
They have long lists of ‘advantages’ and ‘benefits’ – some of them contradictory, like ‘Full scripting support’ and ‘No scripting required’!  The simpler offerings often don’t have the features your software build requires, while the more powerful products need high levels of skill and specific experience, which you may not have in-house.
(Look at http://en.wikipedia.org/wiki/List_of_installation_software for a list!)
Several of the packages also require that you maintain a license for using them – thus tying you to long term costs, and limiting your ability to switch to other suppliers, or to mix-and match to suit your requirements.
• The build package is very large and complex
You have to cater for multiple target environments, with each supporting all the options or variations that your software needs to cover. Most software builders process in the background and are not transparent, so you cannot see what is happening during the build process.
• You have to do the whole process multiple times
For each time your QA process finds a bug in the package, the build process has to be started again. Keeping track of what components must be included each time can be very difficult. And then you have to QA the resulting build again – which may uncover new problems, meaning another cycle!
• . . . and then you need ‘just one more change’
When your package is out in the field, there are always the ‘hot fixes’ that you need urgently, and that have to be delivered before your next major release – like an integration of a new piece of equipment that one client needs or a special feature that has only been QC’d for one customer but will be issued to everyone later. So you want to issue a patch, but you need to make sure that all the affected files are included!