Best Practices? Multiple dependant projects with multiple targets

I'm in need of some best practices advice on my fairly large project. I basically have the following setup:

The Project!
-- External libraries for the project
-- Internal libraries for the project
-- The meat of the project
-- Additional tools

So first question: Should each sub part be its own project, or a configuration of the actual project? Can dependencies go between projects in Team City (I assume so, but I haven't tried it yet).

In addition, I have unit tests that are run with every build (including developer builds) and integration tests that I want run only on the build server, and only after a successful build. For now, this is all held in an Ant file that does everything (including deploying to a shared deploy directory), but what I would like it to take advantage of Team City's offerings to perform what I need it to perform (integration tests, code coverage, etc). What is the best way to set this up?

So, the most complicated of these is the "Meat" which does the following:
- Clean
- Rebuild (as part of this, it automatically runs unit tests).
- Run Acceptance tests.
- Deploy to shared location.

It seams like these aren't configurations, but multiple build steps to get a complete build, and they should be performed for multiple configurations (e.g. Debug and Release) Is this possible to create completely in Team City, or is best practice to use Ant / MSBuild.

Lastly, I have a few branches of this product, that are built the same way, but deployed to different locations. What's best practice for this for Team City?

1 comment
Comment actions Permalink

Sorry for the long delay. The question is still relevant? If yes please leave a comment or create a separate thread.

Kind regards,
Marina
0

Please sign in to leave a comment.