Software Deployment

Well, lets' assume you get everything you ask for and have an open checkbook.

First of all, a testing lab. I want application owners/SMEs to sign off on any software I touch before I deliver it. It takes out a lot of headaches when "you didn't do it right" happens in a lab and not production. Test against the most restrictive rights you have in your environment - I've never seen an install fail because it had too many rights.

For packaging, use virtual machines. The ability to take snapshots and do quick reversions will save a ton of time. VMS are a slower than physical PCs, so I'd suggest having one or two of them as well. You'll be reimaging them constantly, though. If I were to set up a box to do packagin on, I'd get a multiprocessor box with a 2nd hard drive - dedicate the second processor to VMS as well as the second drive. And don't skimp on the drive or you'll be watching grass grow. Get one with high spindle speed and low seek time

If you have remote offices, you'll need distribution points at each site, unless your network team likes getting the WAN links saturated when you do an app push.

You might as well get AdminStudio - looking through posts here, WISE is pretty much done. Make sure you get support on the product - that helps a lot. Also, if you've been tinkering with packaging but haven't done it a lot, I can't stress strongly enough to get training on it. There's a huge difference between dabbling and doing it professionally. Good training can help you do packaging faster and avoid a lot of common mistakes.

Storage on your SAN is a big thing as well - you'll be making a software library a well as storing work in progress. Determine what you're storing - generally it's current version, 1 prior version, and upcoming version. So add up what you'll think you'll need, then double it (some would say quadruple it). You'll need a lot of space.

So that's a starting point. I'm sure the more senior members will have things to add.

What Dave said seems pretty complete to me. Some points I'd like to add:

- make sure you start your packaging from a cleanly staged XP with the company's default image
- another reason for keeping some physical machines handy can be to allow for packaging and testing of hardware components
- plan your packaging efforts to start with more basic components and applications (Office/Java/Oracle) so these can then be used as prerequisites for other applications.
- make sure to work out a signoff procedure for each package, both before and after the packaging. This way the requirements get frozen before you start, and the deliverables get signed off on afterwards. A fixed 'grace period' after package delivery for dealing with possible issues is also key. Dave already mentioned this but I cannot stress enough how important this is.

PJ

Some process stuff as well: determine what and why you're packaging. If you're going to package everything (one employer did that), be prepared to really prioritize what you're doing. You'll have one app that one person absolutely needs, it will take a month to do, and that package will hold up doing a project for a different workgroup. If it's to gain efficiency and you can determine what gets packaged and what stays manual, make criteria for determining what gets packaged and what does not.

Also, when you get install instructions from SMEs and application owners, make them tell you exactly what to do. Do not accept "runsetup.exeandacceptalldefaults". Make the owners tell you to click Next, Yes, and install. If you come to a box where they don't include the instruction, refer the question back. Yes, it's anal. But then you are following their instructions and if there are questions about something not being done right, you have documentation to refer back to. this also helps push your app owners into knowing something about their software. Also, make them give you installation media. Don't accept "download it from the internet" as the source if that's how to get it; make the SME download it and provide it to you. Then you know for a fact that you are working on the right product.

Remember, your job is to deliver their product to their specifications. You may use it, but you aren't the one to determine if it's been packaged and configured correctly. You can only determine if you followed the instructions provided on the media provided. This is counterintuitive, but it will save you a lot of finger-pointing when something goes "bonk".

You must mean the obligatory mention of Mr Phil Wilson, right?

Of course. I wouldn't want to steal your thunder...

Slight clarification, if I may add. If you have legacy apps that you may need to create MSI's from, DO NOT use your company's default image as the capture machine. I have 2 VM's that I have built as workstations in a workgroup. Absolutely nothing is on these machines with the exception of the packaging software (Wise on one and AdminStudio/InstallShield on the other), firewall is off, no anti-virus, completely unpached, basic drivers to make the machine function, and absolutely no other software. Always let the capture machine rest for about 15 minutes or more to allow the OS to calm down before starting a capture. Follow this to reduce the amount of "noise" that is captured.

Flexera and Symantec agreed to kill Wise and InstallShield is taking over (good job Symantec, another great app killed at your hands). I believe that there is going to be a patch from Flexera for Wise in the future, but I have no details and haven't really bothered to look deeper. Keep Wise handy to compare packages to InstallShield. You will find the interface for InstallShield isn't as intuitive as Wise's and they also like to hide stuff and/or make assumptions for you.

At this point, I'll leave it to VBscab to offer his usual instruction...