This step-by-step guide is based on TeamCity Professional 2018.2.4 (build 61678). 1. On your TeamCity server, open the web UI and click: Administration Install Build Agents Windows Installer 2. Run the installer 3. Choose a folder on the disk to extract to I chose C:\BuildAgent3. 4. Do NOT check the Windows Service checkbox I know this sounds counter intuitive - but it will save you from losing your default Build Agent that is already running. 5. Set your Build Agent's properties Set the serverUrl to the publicly accessible URL of your TeamCity instance. Give a distinctive name to your new Build Agent - I like to just number them. Optional: change the ownPort to something predictable. This value is used only internally. 6. Finish the installation process 7. Open .\launcher\conf\wrapper.conf, scroll to bottom In my case, this is C:\BuildAgent3\launcher\conf\wrapper.conf. 8. Change the highlighted values to something unique You need to change the following three values: windows.ntservice.name windows.ntservice.displayname windows.ntservice.description 9. Install the Windows Service for your Build Agent Open a console and navigate to the \bin directory of your Build Agent's installation folder. Then run service.install.bat and afterwards service.start.bat: 10. Verify that your new Build Agent is running Open services.msc and scroll down to TeamCity: 11. Check TeamCity for the new Build Agent It takes a few minutes before the TeamCity service and the Build Agent properly connect - but they do it automatically and the result looks like this: 12. Build stuff! Thanks for visiting - happy coding!

For quite a long time, our team chose not to mess with our working TeamCity configurations, which compile, build, test, and deploy our code several times a day. Two weeks ago, we finally upgraded our last and at the same time biggest project discoverize to work with Visual Studio 2017. This allowed us to take a fresh look at the *cough* new C# language features that we have been ignoring for the last few years. But using any of them also meant having to upgrade our continuous integration infrastructure to support them. Here's what we've done. Update all TeamCity configurations If you use the MSBuild runner, now choose the Microsoft Build Tools 2017 as the MSBuild version and set the MSBuild ToolsVersion to 15.0: This will lead to the error that no Build Agents can be found for the given configuration because a requirement is not met: MSBuildTools15.0_x64_Path cannot be found. Install new Build Tools Thanks to this Stackoverflow answer I quickly learned that I had to install the Build Tools for Visual Studio 2017. You can get the web installer from here. More information about the options in the tool can be found on this page. The first screen shows the possible workloads (as of August 2017) with Web development build tools selected… … and the second screen shows the individual components selected (I actually unchecked all optional .NET Framework targeting packs): Restart the TeamCity Agent Service For TeamCity to realize that you've installed new tools on you build machine, you need to restart the Agent Service. You can find it e.g. after running services.msc from the Start menu –> Run command. Missing AllRules.ruleset file Now, the compilation of our C# 6 project finally succeeded. There was still one problem: the build log contained warnings about a AllRules.ruleset file missing. I just went ahead and copied the file from my local machine (including the full folder hierarchy) because I could not find any information on where to find this file other than on my own machine (with Visual Studio installed). After that last step, the build log is finally black again.   Happy configuring!

We've experienced in the past that deploying new features before the weekend is not a good idea because potential bugs are not discovered in a timely manner and our reaction times to critical problems are also longer over the weekend than during the week. So for a couple of years now, we've stuck to our no-deployments-on-weekends policy, and every once in a while an exceptional deployment with either some "very important" new feature or "only small changes, nothing big" reminded us that it was really a good idea to deploy only on weekdays. There was one downside to this: we always missed out on getting fresh bits on our servers on Monday morning because someone had to trigger the deployment by doing a push to a dedicated Git repository before our TeamCity deployment configuration started to run at 2:20 am. Most of us usually don't work on Sundays so there usually was no-one to do that. Using a CRON expression in your trigger It turns out, TeamCity supports date/time triggers defined by a CRON expression: Since I don't use cron on a daily basis and don't speak cron fluently, I was glad to stumble upon Cron Maker which was a great help with getting the syntax right: Having a tool like this in my tool chain makes me confident and I won't avoid using CRON or its powerful expressions in the future! Happy cron'ing!