CODEWITHSUNDEEP
msbuildbuildcontinuous-integrationteamcity
lysergic-acid
lysergic-acid

Reputation: 20050

Setting up a build process with TeamCity

I am starting to implement CI in my team, and i picked up TeamCity, since it is free for small time teams, and it also seems pretty popular nowadays and features many good options.

I have yet to determine what is the "typical" or best use case for this server.

It seems to me that the vast majority of build tasks are better performed using some other tool (let it be in some build script like MSBuild/NANT) and TC is used only for issuing unit tests/build trigger.

I find it hard to set up a full build process (copying files around/invoking more complex and logic based code, etc).

What is a good scenario for setting up TC into the build process?

Our product is a C# based software with various "plugins".

We're building 3 large .sln files, currently using the MSBuild runner (simply specifying the .sln file as argument to this runner).

This only takes care of building the actual binaries, but is not enough for things that need to combine various projects' outputs together, for example for creating an installer.

Upvotes: 0

Views: 1057

Answers (3)

delloPiro
delloPiro

Reputation: 309

Technically, you can do everything TeamCity does through a script or tool. The beauty of TeamCity is the simplicity it provides out of the box to organize your tasks. At the heart of TeamCity is commandline and out of the box integrations with industry-wide tools. They ease the configuration burden so that by specifying a few variable or parameters, you can automate key tasks that a cumbersome script would have done. The UI smartly takes in commandline parameters in an intuitive way. My favorite use case for TeamCity is its historic significance which stems from the power of its UI. Imagine if you have to figure out the last time a script you run failed or why it failed? you'll have to keep historical logs, artifacts etc that will take time to sort through to answer simple questions. Now imagine you have to report on the historic trend of your automated tasks (builds), you'll need a custom implementation that sifts through all the data you collect just to report or answer simple questions like "is this build taking longer? are the number of our unit tests increasing ?" etc. All these data points are gathered out of the box and reported for you with teamcity. If you can't tell, I think it is a beautiful tool.

Upvotes: 0

savinderpuri
savinderpuri

Reputation: 303

We use TeamCity as follows: 1. Run Continuous Integration builds (fired as soon as someone commits code) 2. Nightly builds 3. Nightly deployments (using batch/shell scripts) 4. Sanity tests (fired on the nightly deployments)

Upvotes: 0

Mike Two
Mike Two

Reputation: 46203

The best answer I can give is to describe our team city process. I can't tell you what will work best for you. I also can't tell you what is typical because in my firm alone we have about 8 ways of using teamcity.

On our .NET projects (that seems to be your focus since you mention MSBuild/NAnt) we have builds with multiple build steps. One uses teamcity's solution runner to compile, the next uses its nunit test runner and the last uses msbuild to copy files around.

We have another .NET build that follows a similar pattern, but adds a few steps calling custom tools written in python.

We have a few java builds that only execute the NAnt runner.

Do what works best for you and your current environment. Live with that for a while and then see what you want to change.

If you already have a good msbuild or nant script just point teamcity on that and use it for triggering.

I like using teamcity's solution runner because it just works. Same with their test runner. But MSBuild/NAnt is really good for file pattern work.

Hope that helps.

Upvotes: 1

Related Questions