How can I speed up our TeamCity builds?

5.1k views Asked by At

Our repository has grown in size quite a bit in recent months and TeamCity builds have now become seriously slow.

A lot of the bulk comes from installation files and other non-code, non-essential (for build anyhow) things that people have checked into SVN.

We just run the basic free version and have 3 agents. Our VCS checkout mode is 'Automatically on server'. The 2 solution files are both C# and we're using an MSBuild script.

I've fond the checkout rules section in the build configuration, but have read that it won't work because it fetches all the code and THEN applies the rules, which defeats the object if you ask me.

A build now takes about 1hr, but if I could just get TeamCity to fetch the code it needs and nothing else then I reckon I could get it down to 10 minutes or less.

I have found a few articles that exclude files & folders using MSBuild, but I can't find anything in our build scripts about fetching from SVN and I think TeamCity does it.

Can anyone suggest any changes we can make, or good articles on putting a build together from scratch using TeamCity and MSBuild that would allow me to pick and choose what to fetch from SVN?

Thanks.

1

There are 1 answers

2
James Woolfenden On BEST ANSWER
  1. Build only whats changing.
  2. CI builds don't need to do all what a release build does. All the CI needs to is compile and do some verification.
  3. Solutions, sometime devs put loads into any single sln. If youve got loads of services in one sln and it builds everytime just one changes? So split them up - one sln per output (I mean exe or service or whatever not a single DLL)
  4. Parallelise the build. Have different build targets for each output (in TeamCity)
  5. Build to artifacts, deploy artifacts. This means that you should never have to wait for a build to finish to deploy.

A ten minute sync is still a really long time for SVN, that's really got to come down, how long does it take at the command line? Move the non build related items to another repo?

With a large code base and svn consider building core components out to a checked in binaries/references section in Svn. This allows you to share built objects to other teams rather than wasting time building their code.

Hope that helps?