How to access TeamCity REST API from C#?

If you work with JetBrains TeamCity as your Continuous Integration server, you probably know that it has rich REST API that allows querying builds, their configuration, builds queue and also perform CRUD operation on them. It might be extremely useful for building custom monitor, triggering builds, cleaning builds queue and many other activities.

In this post I would like to present FluentTc: an easy to use library for all the above operations. When I started working on this library, I had in mind, that it should has fluent, easy to discover API. That's what I like in libraries I consume, so I developed a library that looks like I like it and I hope that you r will find it also usable and easy to use.

In order to get started to use it, you need to install the recent package from Manage Nuget packages -> Search FluentTc

or typing the below in your Package Manager Console of

install-package FluentTc 

So now, having the reference, let's get to the code.

In order to get all the build of specific Build Configuration, you can simply use:


If you are familiar with TeamCity REST API you might know that when retrieving list of entities, it returns only some basic properties of those entities, Id, Name and some Href. It also provides an option to retrieve additional properties. And this is how it can be done using FluentTc:



The above methods return default amount of builds as retrieved from TeamCity REST API. If there is large amount of builds, you'd probably prefer retrieving them with paging, i.e. a few builds each time. This is how it can be achieved with FluentTc:



Of course you can apply different query filters when retrieving your builds. For example, in order to retrieve not personal, pinned, successful builds, that ran during the recent day under specific build configuration, use this:


Credits:
FluentTc was inspired by Paul Stack's TeamCitySharp library.

For questions/suggestions feel free to comment below.

How to add some fun to software development?

A few days ago I gave a talk titled "10 ways to add fun to development process" at the ALM User Group in Microsoft Raanana. I would like to thank Elad Avneri, the group organizer, for inviting me to the group. During the talk I mentioned some tools and extensions and in this post I will summarize them.

For those of you, who missed the session, here a brief overview of it:

The development process is tedious and complex, we are trying to solve problems in different domains in limited time frames. So a little bit fun and sense of humor can relax the atmosphere in the team and make the work more productive.

Here are some tools that may help you to add some fun to your development process:

• Add profile photo using TeamCity Avatar plugin
• Add gamification using TeamCity Achievements plugin or https://getbadges.io/
• Add emoji to your Visual Studio using EmojiVS and ReSharper.ReMoji
• Add @userMention to your commit comments using TeamCityZen plugin for TeamCity
• Add selfie to your github comments using Github Selfies

How to improve your code quality over time?

Developers strive to write their code as good as they can. Then they try to refactor it in order to make it clearer and more maintainable. How we can make sure than it improves over time?

First of all we need to measure its "quality" in order to know what is its current level. Of course quality is not a well defined word. We need some quantitative metrics to measure quality. There are many metrics that could be defined, one of them is Code Coverage. Code Coverage tells us how many percent of the code is covered by tests, i.e. tests pass during their execution on that code. High Code Coverage indicates that the majority of the code is tested and works properly (at least as defined by tests). It does not mean that our software does not have bugs. But it gives a high level of confidence in what the software does. On the other hand low Code Coverage indicates that we don't know anything about the code, whether it works or not.

Let's see how we can measure Code Coverage using TeamCity's build in dotCover. On the the Build Steps page, click Edit on your test step, whether it is NUnit or MSTest: 

On the .NET Coverage section, select "JetBrains dotCover' in .NET Coverage tool. dotCover is a build in coverage tool within TeamCity. In the Filters section specify assemblies that you don't want to cover, for example your tests assembly.

Run the build and navigate to Code Coverage tab under build:

It will show the the total Code Coverage per class, method and statements with the option to drill down. The most important number is the percentage of Statements Code Coverage. In the below project it is 34.8%. Which means that approximately third of the code is covered by tests.

Now given the current level of our Code Coverage we would like to make sure it only increases. We are going to define that if code coverage decreases, the build should fail. It means code coverage is one of our failure conditions. In order to do that we navigate to Build Conditions page and click on "Add failure condition" under "Additional Failure Conditions" section. On the dialog that appears we define as follows and click Save.

Then you can define some more failure conditions on every metrics:

Having defined those settings we can assure that our code coverage will increase over time. But is it enough? Of course not, our team will not produce better code just because we set these automatic failure conditions. It need to be trained how to identify code smells, how to write clean code, how to write proper unit tests. It is a long process and requires good coaching.

Let's summarize what we had until now on how to improve your code quality:

1. Define metrics that important to you and measure their current state.

2. Make the measurement part of your continuous integration and define failure conditions on its decrease.

3. Train your team on how to write better code, write good unit tests.

I'd like to read your feedback on how it is done in your company. 

P.S. The screenshots above are taken from an OSS project I am contributing to called BizArk. Its continuous integration is generously hosted on Codebetter's TemCity server. TeamCity is provided for free for open source projects by JetBrains.

TeamCityZen - TeamCity communication and socializing extension

Every organization that uses Continuous Integration can admit, that the continuous integration server became much more than just build-machine. It functions as company's central monitor for the healthiness and readiness of the software being developed. It answers many questions raised by developers, analysts, product managers, development managers, operations etc. But more than this, it became the center of communication for those team members. You can often hear conversations like those:

- I am waiting for you to finish this feature, can you let me know when you're done?
- I will commit the interface of service, so you could consume it. I'll send you an email when I do.

Those conversation led me to writing a TeamCity extension named TeamCityZen, since we are sort of citizens of the city named TeamCity. The extension enables mentioning somebody's username in commit comments. User who was mentioned in the comments will be notified by email. Support any kind of Source Control: Git, TFS, Subversion, etc.

Screenshot from TFS:

Feel free to download, use and extend.

More details: https://github.com/borismod/TeamCityZen

TeamCity hidden shortcuts

My colleague says, that he hates JetBrains as a company. He cannot find anything wrong or ineffective in their products. He is surprised that they just work. Work as expected and even better. They foresee our needs and our requirements and have already implemented them.

In this post I would like to share you the keyboard shortcuts I found in TeamCity:

p is a shortcut for searching among project names. Strike "p" and then start typing a project name Available in TeamCity 7.0

j is a shortcut for searching projects and build configurations in the same root project. Strike "j" and then start typing a project name or a build configuration name. Available from TeamCity 8.0

And the most powerful:
q is a shortcut for searching both projects and build configurations. Strike "j" and then start typing a project name or a build configuration name. Available from TeamCity 8.0

P.S. Thanks to JetBrains and Pluralsignt for supporting CleanCodeAlliance group.

UPDATE: I've got a reply from JetBrains employee on twitter that there are even more keyboard shortcuts in TeamCity's Changes page in version 8.1:

up/down to navigate, right/left to expand changes.  And 'f', 'b', 't' to open specific tabs of the selected change

Thanks to Kirill Maximov @maxkir

According to Kirill there is no official documentation about the shortcuts. So I will maintain this post as a sporadic one.

Automatic Deployment :: The final solution

In my previous post I lited tools used for automatic deployment. Although all of them have significant advantages, they did not fit for our needs. Or if they did, they seem to be too complex for such simple deployment process. So let's start with what we needed. We needed a script/tool that:

1. Downloads binaries 

2. Updates configuration files

3. Stops a windows service

4. Copies rellevant files 

5. Starts a windows service

6. Checks that the service is started and responding properly

7. Iterates the above steps for several servers in several data centers

One of the most important decisions we've made before and during the tools selection, was the following. Use the same deployment tool/script for deployment to test/staging environment as for production deployment. This rule seems to be pretty obvious and maybe irrelevant, but it saves a lot of times and script fixing during produciton debug. When the product is deployed to test machines on a frwquently basis it tested each time. If there is some new configuration parameter that needs to be updated. If we forget to update the deployment script it fails in deploy to test machine. Then we fix it in deploy to test machine and produciton deployment works smoothly.

So let's go back to tool seleciton: we use TeamCity as our continious integration system for builds automated tests etc. And it seemed so natural to use TeamCity for automatic deployment as well. We wrote, or actually, reused Powershell script previously written in order to extend Puppet. These scripts do the steps described above. 

So the winners are TeamCity and Powershell