Continuous TFS 11 Integration

Good afternoon, colleagues.



The long holidays end, and tomorrow, we will again plunge into the abyss of the daily routine. Today, at the junction of the holidays that have not yet ended and the working week that has not yet begun, I would like to talk a little about continuous integration .

Starting to introduce Agile practices in the development, many, reading: "Personalities and their interactions are more important than processes and tools," come to the delight. After all, you can assemble a team, rally them, set tasks and here it is: “the star of captivating happiness” (working and useful for software users). But, unfortunately, in life everything is much more boring and unpredictable. Starting to introduce a new-fangled Scrum or Kanban, it is often forgotten that all the advantages of these techniques manifest themselves only if they fall on the correct engineering practices. These practices include unit testing in general, and TDD in particular; pair programming; Code Review; continuous integration and more.

Under the cat, I will try to show how to configure continuous integration within TFS 11 and in which scenarios, which way to build projects will be most justified (a lot of pictures and text).



So, anticipating the main content, a couple of words about what is needed to repeat everything described below in the article:

1. Installed TFS 11

2. Visual Studio 11 or 2010.

Download TFS 11 and VS 11 from the Microsoft website.

If you do not have TFS 11, but there is TFS 2010, then with differences in the user interface, but you can configure everything described in the article in it.

Team Foundation Build Service Setup

If you have already configured the Build Service, then immediately go to the second part of the article .

Starting the TFS Administration Console and selecting Build Configuration, you will see the following prompt:



Configuring! The wizard is quite simple, we skip its first screen immediately Next:



In the second step, you need to specify with which collection of projects and on which TFS server the configured Build Service will work. By default, the first collection of the current TFS server is selected:



In the third step, you have to decide how many agents will be served by the builds within this server. If you select 1, then all build requests will be queued; after the completion of compilation of one project, the next query from the queue will be compiled. The main advantage of this approach is to reduce server load, minus - if projects are compiled for a long time, and the queue is long, then you will have to wait. When increasing the number of Build Agents, the queue will be serviced faster, the main thing is that with a huge number of them, the server will not spend more time switching between agents than the compilation itself:



On the final screen, we will be asked to indicate with which credentials you need to run the Build Service. If you plan to only compile projects without deployment to a test and / or production environment, then you can leave the default value. Otherwise, choosing an account for the Build Service must take into account what rights the account must have to perform these tasks.

Actually setting this ends. There are two more screens ahead, with what we have chosen and checking whether it is possible to configure what is selected. Clicking Configure on Readiness Check and waiting for the end of the configuration, we will see:



If you consistently reached this place, then the Build Configuration in the TFS administration console will look like this:



This is where you can finish working with the Team Foundation Server administration console and go to Visual Studio.

Demonstration environment

For clarity, let's take a simple WPF application that should be in the Source Control. We will also add a project with unit tests that will test the functionality from the first project.

The folder structure in TFS for this article is:



Yes, until I forgot, the network folder should act as a folder where the built solutions will take shape. To which, the account under which the Build Service is running must have access.

')

1. Manual request for solution building

Immediately make a reservation, manual launch and continuous integration, these are concepts from different tales. Continuous integration implies automatic, regular construction of projects, without human intervention. But, since manual building requests are the easiest, and setting up for all other launch cases will be very reminiscent of manual requests, then let's start with it.

Scenario:

You have a branch in which you are developing. And there is a branch in which you store the version of the project that is deployed in the operational environment. From time to time, there are errors in the working version. You download the corresponding project, correct the error, check it on the local developer’s computer, place it in the Source Control. Testers and / or deployment specialists need to build this solution. To do this, they will perform a manual request.

Setup:

On the Team Explorer home page, select Builds and in the New Build Definition tab that opens:



In the first step of the wizard to create a new Build Definition, we need to specify the name by which we will further identify this build request. For this example, I added the suffix "_manual" to the name suggested by default:



The second step allows you to configure when the Build Agent should be active and run the build. The default value of Manual suits us well:



The third step allows you to specify the location of the solution folder in the Source Control and the location of the Build Agent on the server. In most cases, these values ​​can be left as default.

The fourth step allows you to specify with which controller we will build, as well as the folder into which the output project should be placed (Staging location). Moreover, the first placement option (do not copy files to the output folder) is justified if you just want to build the project, run all the Unit Test on it, and you do not need the resulting exe and dll. The third option (put the result of the construction in the Source Control) may be convenient for developers, in order not to lose the stable Build. But basically, of course, the second option is used, when the results of the construction will be copied to a network folder. Moreover, for each launch of Build Definition a nested folder is created, and all constructions, by default, are saved according to the following scheme: <project name> _ <build date>. <Build number for build date>.



In the penultimate step, we define general construction settings. Please note that by default, the open sln is immediately selected and the launch of unit tests is worth it:



But, of course, the build mode can be changed. For example, configuration changes in which to compile the project:



Save the Build Definition using the Save button from the toolbar. Team Explorer has a new Build Definition:



In order to run it, just open the context menu on it and select “Queue New Build ...”. In the window that opens, click "Queue". And we see that we are building, well, at the end, the pictogram will tell us about the result of the construction:



Double-click on the build will allow you to view detailed information, including the result of the execution of modular tests:



Everything, with manual start and the main requests I finish. Let's quickly go through the rest of the scenarios.

2. Building a solution for each code location in Source Control

Scenario:

Developers write code, unit tests. Putting it all in the code repository. We want to be sure that this is all going to and pass all tests.

Settings:

Setting up a new Build Definition will differ only in the first step (you must give a different name) and in step 2 of the wizard. We specify the second option as a trigger:



To start building, it is enough to make changes to the code of projects or unit tests and place the changes in the Source Control. At the end of Check In, if we go to the Builds tab in the Team Explorer panel, we will immediately see that our construction is running. Incidentally, I added a new test to the project, which failed:



We can also open the details of this construction and analyze what went wrong.

With this build scenario, there is a significant drawback. If there are a lot of developers, they work on TDD (frequent Check-in), and the complete construction of the project and the test run take 5-10 minutes, then the build queue at 1 Build Agent will be very long and you will have to wait for changes in the Source Control build result.

3. Building on the Check-In but not more often than ...

Scenario:

The script is the same as in option 2, but the TFS server cannot cope with it, and the management does not provide money for a separate Build Server.

Setup:

Similarly manual, at the second step we select the third option of construction:



We are correcting the project so that the test-check introduced in the previous paragraph passes. And we see that two constructions started right away. The one that needs to be run on each Check-In and the one that needs to be run on Ckeck-In, but not more than once per hour (pay attention to the icon indicating that the construction is in the queue):



True, with the next Check-In, if it happens earlier than in 60 minutes, our new building will not be launched.

Using these two types of constructions, we can, for example, build a project for each Check-In without running the tests, and at least once an hour build a test with the launch of tests.

4. You can not put the code in the Source Control, if it is not compiled

Scenario:

You have a new developer in your team who forgets to check before compiling the code in Source Control, does he even compile?

Setup:

Create a new Build Definition, give it a name, and select the 4th option to trigger the start of the build:



We make changes to the code (of course, so that it stops compiling) and when trying to Check In, this notification:



And after launching the compilation, in Team Explorer we will be unequivocally reminded that we need to wait until the end of the build, and after the end of the compilation, a notification pops up:



Conveniently, damn it!

5. Daily builds

Scenario:

How do you not have daily builds yet? Then urgently read the 3 point test Joel Spolsky (http://russian.joelonsoftware.com/Articles/TheJoelTest.html).

Setup:

Well, you probably already know, create a new Build Definition, change the name, and in the second step we ask on which days and at what time to compile:



Every night, the evil Build Agent will come and compile, compile, compile.

Instead of conclusion

Do you still live in a world without continuous integration? If yes, then nothing!

As you can see, the setup takes not so much time, but the result from the fact that your project is compiled regularly, subjected to testing with unit tests, etc., you will feel almost immediately.

And finally, the new version of the VS design I like. Everything is very convenient and clear: