Hopefully I have the proper area to post this in and hopefully someone can give me some pointers.
I am wanting to know how other companies handle packaging of software.
In the company I work for we do not do this very well. Our current process is that development gives us (QA) the raw code (unpackaged) and QA loads and tests. Once it is approved then it goes to our packaging department, which is also under the QA department.
I know there has to be a better process, but what is it? Should development package all of the software and then pass to QA? I feel that our first test should be installation.
Along with this I would like to know if there are people that specialize in packaging of software?
What is the most common product used to package software? Currently we use Prism from Newboundary.
I can tell you how we do it here, but if this is the "best" approach or not... you be the judge. [img]images/icons/wink.gif[/img]
I make the developers create an installation package. I want to experience the same thing the customer is going to experience, so if no installation package is needed, I manually copy and paste files into their location just like the customer would. Otherwise I (along with our program managers) require an installation program.
Whether or not QA should be responsible for creating the package? I've seen it work both ways. With smaller applications that don't do to much to the operating system (ie: they just copy files), I would say QA could easily create this installer.
But if you need to run multiple programs during installation (.NET framework, MDAC components) or you need to properly register OCXs with Windows... those tasks are a bit more developer oriented in my eyes.
I've made installers myself, it's not hard. But I prefer to have the development staff do it. I'd rather be testing. And since there's 8 of them and 1 of me... it's an easy argument to present to my mangers.
We have developers create (ant) scripts that create the package, then build master (reports to QA department) create package (running the scripts), then we test package. I believe this is the best practice for large projects (having more than 10 developers and more that two technologies involved), because a lot of issues tend to appear during packaging, especially issue of clear environment that is never the case for developers. For smaller projects such an quality procedures may be an overhead.
We recently dropped usage of installshield as it is functionally limited (unfortunately don't know what they use now), but it's OK for simple packages.