0 Comments

We use TeamCity on our servers to run unit test, performance tests and deployments. By now we rely heavily on the processes which we configured in TeamCity. In case we lose a server, we would like to have backup of all the configuration of TeamCity on that server.

To create daily backups we use TeamCitys REST API. There is an endpoint for Data Backup. I found a script written by Ivan Leonenko, which encapsulates the API call in a powershell script. If you want to then create a repeated Task Scheduler task, here is a step-by-step blog post on how to do that. Since we do all our backups with SyncBack, I created a repeated runner there which executes the powershell script. After that JungleDisk takes care of copying the backups to Amazon S3, where we would find our backup copy in case the server and its data is lost.

0 Comments

I had another small odyssey when I transferred our TeamCity installation to our new server.

Without an external database

If you are not using an external database the process is pretty easy:

  1. Use the UI to backup the TeamCity data
  2. Install TeamCity on the new server
  3. Copy the backup data to the new TeamCity Data Directory (usually "C:\ProgramData\JetBrains\TeamCity")
  4. Set the projects from hidden to visible in the administration area.

With an external database

If you, like we, use an external SQL database for TeamCity the migration is a totally different ball game.

  1. I backed up the data again with the UI like above.
  2. For restoring I used this documentation.

I ran into a few problems:

  • It was imperative to not startup the site before running the maintainDB command.
  • I needed to allow TCP/IP connections to the SQL instance.
  • I had some problems with my Java installation (ClassNotFoundException jdbc.SQLServerDriver - it seemed the additional 32bit installation caused the problems). These two articles helped me.
  • I also ran into some problems to get the TeamCity projects on the new server running:
    • I had to adjust the MSBuild versions.
    • For npm I had to manually create a folder because of a ENOENT error.
    • For grunt I had to add C:\Users\[username]\AppData\Roaming\npm to global PATH, and execute “npm install -g grunt-cli” there.