views:

217

answers:

4

In using our TeamCity Continuous Integration server we have uncovered some issues that we are unsure as to the best way to handle. Namely how to reference external applications that our application requires on the CI server.

This was initially uncovered with a dependency on Crystal Reports, so we went and installed Crystal Reports on the Server fixing the immediate problem. However as we move more applications over to the CI server we are finding more dependencies.

What is the best strategy here? Is it to continue installing the required applications on the Server?

Thanks

A: 

If you use Maven to build, you can define your dependencies in the pom.xml file. They will then be automatically downloaded if necessary.

Einar
A: 

I am not sure if I followed correctly...

I am assuming your application is dependent on this external app, while building? In that case it should be on the machine doing CI...

Maverique
+3  A: 

Where possible make the external dependencies part of your build system. For instance check the installer in to your version control system and have a step that checks it out and runs it in silent mode (many installers support a mode with no user action sometimes using the commandline /s).

This way if you need to set up another build machine for a branch or just for new hardware everything is repeatable.

morechilli
A: 

If your builds require the actual application to complete the build, then you should probably continue to install the application on your build server.

If you just need references to dlls or assemblies from the application, then what we've done at my company is to create installable 'SDKs' of the references required for a particular applicatoin and install them on our development and build machines in well-known library directories that our solutions reference.

On the build machine, our pre-build steps install the correct version of the dependencies and then clean them up when we are finished.

Recently, we've moved to using virtual machines for our build machines that our build process activates. These VMs get the SDKs installed on them as a pre-build, and then are restored to their snap-shot state after the build. We had some dependencies that were almost impossible to uninstall, so this made for a clean starting point each time.

Steve Mitcham