This article is a summary of a series of articles on how to implement continuous integration of code on the.NET platform using JetBrains TeamCity as a tool. The full article table of contents is at the end.

preface

I assume that you already understand the basic concepts of continuous integration. If not, use the Wikipedia link above as a starting point, or read uncle Martin Fowler’s article and the book of the same name, continuous Integration, a classic on the subject.

In this and subsequent articles, “continuous integration” will be referred to as “CI” in community parlance. They mean exactly the same thing.

Continuous integration solutions on.net platform

CruiseControl.Net

Probably the oldest tool in the field, like many early.NET open source programs, it comes from a port of the Java version of CruiseControl. It doesn’t seem to have been updated since 2014.

We used this program early on for several years. There is no interface and it is all about manually editing configuration files (there are some third-party tools). Due to the late activity decreased, slowly no longer used.

Both CruiseControl/CruiseControl.Net came from the IT company ThoughtWorks, which later launched the commercially successful Go, now known as GoCD, More emphasis on continuous deployment (CD) than just the concept of CI. Written in Ruby, it had a poor early reputation for memory usage and responsiveness, and I was put off by reviews.

Microsoft Team Foundation Server

Microsoft’s own lineage, once a stand-alone product, is now mostly part of the Visual Studio family. Earlier versions were prone to inexplicable installation problems and followed Microsoft’s consistent bundle-style approach (domain control, SQL Server, IIS, SharePoint, etc.), with the product taking a giant, all-encompassing approach. It’s an official product, but I personally don’t recommend it. Try it if you’re a Microsoft die-hard.

JetBrains TeamCity

Of course, this is the protagonist of this article. As a.NET programmer, you’ve probably heard of their Resharper, if not used, and TeamCity is a relatively niche product in their lineup. Continuous integration support for Java and.NET projects, free for small teams of up to 5 people. Since it is a commercial product without open source, the community and plug-in base is not as broad as Jenkins’, but the focus is high, and the details of the product are more detailed than Jenkins. I personally think it’s a good choice for small teams with no special requirements.

Another interesting aspect of TeamCity is that it provides both a code quality Checker (Duplidate Checker) and a unit test coverage tool (dotCover). These tools should be command-line versions of Resharper, but are also integrated into TeamCity to give you reports on code quality as you build projects and unit tests. It’s not as powerful or comprehensive as a professional tool like SonarCube, but it’s a valuable source of information and it’s available out of the box with no extra setup required, so it’s a standout.

Jenkins

This is probably the best known CI software and is the popular choice of many software teams, especially Internet companies. It was originally split from Sun’s Hudson product, but now has more functionality and community activity than Hudson, and the development team is diligent with new releases. There’s a nice community of people contributing features and extensions to it. But the prosperity also brought the plug-in quality problem. It is recommended for companies with high requirements for CI customization and strong development strength.

In addition, there are many cloud-based CI solutions, as well as internal CI tools opened up by large companies such as Facebook and Google. But most of these tools and platforms are not well suited for.net platforms, so we won’t discuss them here.

. NetFramework platform

From my experience, the.NET Framework as a basic platform for continuous integration has some problems. According to the CI philosophy, to minimize environment-related problems, nothing should be installed on a CI server other than the most basic build SDK. Java does this better, you only need to install either the Java SDK or Ant/Maven on the server, and basically nothing else. A lot of Microsoft stuff is tied to Visual Studio. For example, all Web projects have references like:

<Import Project = "$(MSBuildExtensionsPath32) \ Microsoft \ VisualStudio \ v10.0 \ WebApplications \ Microsoft WebApplication. The targets" Condition="false"/>Copy the code

This means that if you only have the.net Framework SDK on your build server and don’t have the full VS installed, you won’t be able to compile many projects. There are ways around these problems, and I’ve tried several. But in the end, the easiest way to compile the solution completely without wasting a lot of time is to install VS completely on the server. More recently VS has taken a step back in toolchains. While FxCop/StyleCop used to have separate packages, Microsoft has decided to integrate them into VS. As a direct result, it’s much harder to build projects without VS.

Of course, you might be better off using.NET Core, but I believe most real-world projects will have to be based on the.NetFramework for Windows for the foreseeable future. Accept that for a moment.

Version of

At the time of this writing, the latest version of TeamCity is 2017.1.4, which is the version used for the examples. I’ve been using this product since TeamCity 7, and the build process has remained pretty much the same, with some tweaks to the details. You don’t have to worry too much about outdated content.

A series of content

The next several articles will cover TeamCity installation, configuration, and a practical example to illustrate specific steps for continuous integration of.NET projects. Please read the links below for your specific needs.

The full directory