svn + nant + teamcity -- multiple web projects in one SLN

Hi and thank you in advance for the help.

I am helping a company get started with TeamCity.

They have a repository, with a solution inside of it.

The solution contains multiple web projects, all in subdirectories of the solution.

When people check in code to web-project (A), we want to trigger only web-project (A) to be built and deployed, without rebuilding/redeploying everything else in the solution.
Now I was thinking that maybe I should create a TeamCity project for each web-project, set the VCS root of each project to a sub-directories in the repository.

Has anyone else done this? It seems like a common case.

8 comments

What runner do you use?
I home it is MSBuild, Sln2005 or Sln2008 for all of those runners it is possible to set target Build instead of Rebuild (that is the default). Setting 'Build' as target makes runner to work the same way as VS does. It will build only the projects that have files changes and all the project that depends on those ones.
If that does not works for you? (But why?) I think it is the right idea to create build configuration per project. But for that case please note to set up build artifacts for dependent projects.

Thanks! Please feel free contacting us

0

Thank you, that was actually really helpful information.

This was my solution that worked for me:

My structure is like this:

\
\branches\
-


\Dev
-


\MainSolution.sln
-


\website1
-


\website1.csproj
-


\website2
-


\website2.csproj
\trunk
-


\MainSolition.sln
-


\website1
-


\website1.csproj
-


\website2
-


\website2.csproj

I have 6 different build configurations...

coreTrunk: (sln2005) trigger on commit, restricted to +:/trunk/, -:/trunk/website1/*, -:/trunk/website2/*. (restricted to any changes in the trunk folder EXCEPT the website folders)
website 1 trunk: (nant) trigger on commit OR after coreTrunk, restricted to +:/trunk/website1/**, run a nant script that builds website1.csproj, and deploys to website1 production.
website 2 trunk: (nant) trigger on commit OR after coreTrunk, +:/trunk/website2/**, run a nant script that builds website2.csproj, and deploys to website2 production.

coreDev: (sln2005) trigger on commit, restricted to +:/branches/Dev/, -:/branches/Dev/website1/*, -:/branches/Dev/website2/*. (restricted to any changes in the branches/Dev folder EXCEPT the website folders)
website 1 dev: (nant) trigger on commit OR after coreDev, restricted to +:/branches/Dev/website1/**, run a nant script that builds website1.csproj, and deploys to website1 staging.
website 2 dev: (nant) trigger on commit OR after coreDev, +:/branches/Dev/website2/**, run a nant script that builds website2.csproj, and deploys to website2 staging.

Since I use visualSVN server, I can provision windows users access to sub-directories in the repository (eg: Joe has access to the full repository, but Ang has r/w access only to the website2 folder)


does this sound like a proper usage of teamcity to you?

Edited by: peter weissbrod on Apr 26, 2008 1:10 AM

0

Actually, in practice it seems like the build triggering is NOT working correctly.

It seems like no matter what trigger rules i define, all of the build configurations are running.

For example, website1Trunk is restricted to +:/trunk/website1/** but when I commit an update to something in /trunk (below website1), website1Trunk configuration is triggered! This is wrong

coreTrunk is restricted to +:/trunk/** and -:/trunk/website1/** but when I commit an update to something in /trunk/website1/, coreTrunk is being triggered! This is also wrong

It seems like either I am defining the build triggers incorrectly, or perhaps I am implementing this the wrong way... tell me what you think.

Edited by: peter weissbrod on Apr 26, 2008 1:30 AM

Edited by: peter weissbrod on Apr 26, 2008 1:36 AM

0

If anyone can help me with this problem I promise to write up a glowing and detailed review of your product on my blog @ http://www.acceptedeclectic.com

I am very excited about TeamCity and its potential, but I need to overcome what seems to be simple obstacles.

0

Peter,

For example, website1Trunk is restricted to +:/trunk/website1/** but when I commit an update to something in /trunk (below website1), website1Trunk configuration is triggered! This is wrong

coreTrunk is restricted to +:/trunk/** and -:/trunk/website1/** but when I commit an update to something in /trunk/website1/, coreTrunk is being triggered! This is also wrong



Could you please let us know your settings (screenshots will be OK) for the configuration in question:
- checkout rules and triggering rules (can be looked up in one place on the Settings tab of a build configuration page)
- the changes of a build that you believe should not have triggered the build
- the "Triggered by" field on the build results

--
Best regards,

Yegor Yarko
Project Manager
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

0

I thank you for the help.
Forgive me with this simple question, but I am struggling to find the "Triggered by" field on the build results.

I spent some time looking in the overview, the history, the change log, and the help files, and I was unable to find a "triggered by" field. This would be very valuable information to me.

On another note, even though I am still seeing problems with triggering, I managed to repair one of the incorrect build configurations by restarting the teamcity service.

0

I continued searching and found the following issue in JIRA:
Triggered by field is not visible after server restart


I am wondering if this is the same problem I am seeing. My current version is 3.1.1 (build 6828) which means this should be resolved.

Once I can figure out precisely what file(s) are triggering builds, the problem should be simple to solve. I'll keep digging.

0

Everything works!

My triggers were properly defined. It just seems that the teamcity server needs to be restarted for the changes in trigger configuration to take effect.


My next task: make all of this work with sql server 2005 as the teamcity build database :)

0

Please sign in to leave a comment.