Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

Install Build Automation


4 replies to this topic

russellperry

russellperry
  • Full Members
  • 31 posts

Posted 08 June 2006 - 00:24

I'm interested in hearing how other developers automate the install build process.

Specifically:

What tools/scripting languages do you use?
How do you integrate with the application's build automation, if any?
How do you interact with developers on your team who "own" third-party controls?
What is the format of the install build's output? Zip? CD?
Do you use Automation Interfaces, like the MSI or InstallShield Com objects?
Is there any QA/Unit Testing involved in your automation?

There's been a lot of writing recently about application build processes, but not a lot that I can find about install build processes. It seems to me they're two different issues with very different challenges.


Any thoughts?

Edited by russellperry, 09 June 2006 - 00:55.


luke_s

luke_s
  • Full Members
  • 532 posts

Posted 08 June 2006 - 02:58

We build our install using install shield, and then use the Install Shield command line options to build this automatically. Our build system runs on "make".

The install package is built locally, and then copied over to our CD structure.

For thrid party products, we create a static copy of the product, and then just use the build system to copy this over into the cd structure.

A normal files/folder is created (CD) and a zip of the CD is built as well.

Zweitze

Zweitze
  • Full Members
  • 522 posts

Posted 08 June 2006 - 20:14

Look at VisualBuild, http://www.kinook.com - much better than the make/nmake solutions from your compiler. I don't want to go back to dozens of make files, bat files etc. with thousands of lines.

Scripting is usually required, in my case I have scripts to update package codes, product codes, version numbers and upgrade tables. I use both Windows Installer and InstallShield interfaces.

Other suggestions:
1. Integrate Source control in building (eg. create labels).
2. The build process should also clean up everything: it should unregister every COM server it registered. InstallShields' autodetection of COM classes is fooled by old classes that are no longer supported by the newer versions.
3. Use a dedicated computer, that has NO extra tasks. This is a logical consequence of previous suggestion. I know a company that now uses VMWare images for building, when the actual system breaks it is very easy to move the image to a new physical system.

Hope this helps.

russellperry

russellperry
  • Full Members
  • 31 posts

Posted 09 June 2006 - 00:51

QUOTE
Look at VisualBuild, http://www.kinook.com - much better than the make/nmake solutions from your compiler. I don't want to go back to dozens of make files, bat files etc. with thousands of lines.

Scripting is usually required, in my case I have scripts to update package codes, product codes, version numbers and upgrade tables. I use both Windows Installer and InstallShield interfaces.


I used VisualBuild for a couple of years, but I finally found that it was merely serving to insulate my scripts -- which were doing most of the heavy lifting rather than VisualBuild itself -- from each other. VisualBuild is nice for simple to moderate solutions, but eventually I became frustrated with the lack of integration, setting macros between steps, etc. Some of my frustration was admittedly with VBScript and not VisualBuild. So a few months ago I rewrote my whole build script in Ruby, which made my life much easier.

One thing I was able to do with the Ruby script that someone may find of interest: after the compile is done I have an RUnit test that makes assertions against the msi using the Windows Installer automation object -- file versions, GUIDs, Merge Module versions, COM registration settings, etc. An automated email sends the output of any failed tests to all concerned parties.

Since I develop on one machine and run the install project through source control to the build machine before building, and since we have 8 different developers committing a number of third-party controls to the install constantly, the security the unit test provides has been tremendous. It's saved my tail more than once, not to mention countless hours of debugging, because I can catch errors long before I send the final install up to QA. Now every time I fix a bug or add a feature, I add a test case that guarantees that the solution that works on my machine actually made it all the way through the build process.




MrSmersh

MrSmersh
  • Full Members
  • 48 posts

Posted 09 June 2006 - 10:18

We have automated the VisualStudio build and since in the solutions are also the InstallShield projects they are also build...
Is part of the product build....