Deployment issues and upgrading to new server

We are running Team City 8.0.2, and currently having timeout issues deploying via Octopus Deploy Basically, our Octopus times out attempting to find the deployment packages on the TeamCity nuget server. We have nine active projects with varying numbers of checkins. Each project is on a scheduled build of once an hour, if needed, and all but the last successful build are deleted every night. Most projects have 18 nuget packages, but we will be transitioning all deployment packages (~50) to Octopus Deploy in the near future. Both Team City and Octopus Deploy are on their own virtual servers.
Our plan to alleviate the problem is to upgrade Team City to 8.1.4 and Octopus Deploy to 2.5 on NEW servers. We would like to configure and test the new layout with minimal interruption to our existing development cycles. We also want to replace the Team City nuget server with Otopus' nuget server (with Lucene) to reduce the load on the Team City server and improve package lookup speed.
1. Can we install an upgrade of TeamCity on an alternate server and evalute performance without interupting our current installation?
2. Can we alter the nuget repository from Team City to Octopus Deploy's built in repository easily?
3. Would it be better to run our own Nuget repository on another virtual server to reduce the load on the other two servers even further?

1 comment
Comment actions Permalink

I copy response from email for interested users:

"I highly recommend to install TeamCity 8.1.4 on your production server. We've made number of improvements in NuGet feed in that version. Particularly performance should be significantly improved after upgrade. I'm expecting the problem with timeout to be resolved after that without moving your packages to Octopus Deploy repo.

As for your questions
1. Yes and no. What you actually can do is to create a copy of TeamCity server with all data. Here is an instruction -
But in your particular case that new server's performance is not an indicator of success because you need to also emulate the load made by build agents farm on the server. That load makes an impact on NuGet feed performance.

2. We do not provide any tools for such migration.

3. TeamCity server itself should handle your scale without any issues, if not - we'll make all the required performance improvements. But still we need some data from you to do it."


Please sign in to leave a comment.