As a part of setting up the Ionic 2 project I am currently working on, I decided to also configure end-to-end testing using Protractor. I based it on the excellent Clicker demo project. It worked great for running tests during development, but lacks support for headless test execution on a build server.
When exposing your TeamCity build server to the internet, you'll want to use HTTPS so that users won't have to send their passwords over an unencrypted connection. Thanks to Let's Encrypt, you can now get the SSL certificate for free, but there is still some work involved to get everything configured correctly.
The introduction of diagnostic analyzers in Visual Studio 2015 significantly lowered the bar for development of custom static code analyzers. The supporting infrastructure makes it easy to have the same static analysis run after every commit as part of continuous integration on your build server - you just need to configure your Visual Studio projects correctly.
Based on Visual Studio user experience, one would think running unit tests for Windows Store apps is not all that different from running standard .NET framework unit tests using MSTest testing framework. When you try running them on a build server, it turns out there are a lot of differences.
Whenever I'm developing a non-desktop Windows 8 application I prefer having as much business logic in portable class libraries as possible. The test project can then be a standard .NET class library, allowing mocking frameworks and other helper libraries to be used which are not available elsewhere. Having a dependency on a native platform specific library, such as SQLite, can still complicate things a bit.
The new version of NDepend brought many new features; among them also integration with TeamCity build server. This convinced me to give it another closer look; evaluating how taking advantage of this can contribute to increasing code quality in larger development teams.
After the last reboot my TeamCity build server suddenly stopped working: 404 errors were returned instead of TeamCity dashboard. It turned out some other process was already listening at port 80 when TeamCity was starting up. It must have been something new I installed since the previous reboot.
Although Git-based continuous deployment of my site to Azure seemed like a good idea, it turned out too unreliable. I didn't manage to get to the bottom of the issue. Instead I started exploring the alternatives. I decided to use Web Deploy, because it is reasonably easy to set up and it also supports deleting of removed files from the deployment location.
TeamCity has built-in support for gated commit build pattern in the form of pre-tested commits. Unfortunately, to make them work, you need to use a supported IDE or a command line tool. That's why I decided in favor of an alternative approach: automatic merge feature.
Writing a build script was only the first step in setting up continuous integration. In this follow-up post I describe how to configure TeamCity for Grunt and provide a couple of hints how to make it work even better.
I can recommend the book to anyone having TeamCity as their continuous integration server, as well as to those who are considering it as their first or new solution for continuous integration.
After switching to TeamCity one of the first tasks was setting up proper backup of its configuration. There are multiple ways to backup TeamCity data. The only one that can be performed remotely is exposed over TeamCity's web UI. Fortunately it can also be triggered via REST API for easier automation.
After a hardware upgrade I decided to switch from CruiseControl.NET to TeamCity for my personal continuous integration server to see for myself how they compare. Since I don't have all that many active projects, the free Professional Server License is a great option to try out all of the features without paying for it. At the same time it should give me enough insight to see whether it has enough advantages over free alternative(s) for the investment to make sense in a larger environment.