Partilhar via

Continuous integration using TFS on the Cloud

  • Artigo

One of the best definition for Continuous Integration comes from Martin Fowler

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.

 

Continuous Integration and your Development Process

Is your development process Agile? Do you use Extreme Programming, scrum or something else? Is your company deeply rooted in waterfall methodologies? Or do you have a hybrid method that falls between waterfall and Agile? It really doesn’t matter which methodology you use, because you probably pretty much follow pretty much the same process when it comes to writing code.

  1. Check out the needed source files from your source code repository
  2. Make changes to the code
  3. Click on Build on the Visual Studio menu, and hope everything compiles
  4. Go back to step 2. You still get compile errors, didn’t you?
  5. Run unit tests and hope everything will turn Green. Really hope that you are running Unit Tests, if not please refer to my previous blog.
  6. Go back to step 2. Unit tests do fail. In this case, you will see red. Perhaps in more ways than one.
  7. Refactor the code to make it more understandable, and then go back to step 5.
  8. Check the updated code into source code repository.

 

 

When you start using Continuous Integration, you will follow the same process. But after you check in the source code, you’ll take additional steps as shown in figure 1.

  1. An automated system watches the source control system. When it finds changes, it gets the latest version of the code.
  2. The automated system builds the code
  3. The automated system runs the unit tests
  4. The automated system sends build and test results to a feedback system so that team members can know the current status of the build.

 

 Figure # 1: The Continuous Integration Process

 

 

At this point, you may be asking yourself several questions, such as, “Why do tests need to run multiple times?” or “Why can’t I just click Build in Visual Studio?” The answer to this questions is the same: automating the building, testing and running of other processes through Continuous Integration ensures that the code from multiple team members integrates, compiles and functions correctly, and that it can be reproduced the same way every time on different machine than your workstation. Also, consider that you may have an application with many assemblies you’re responsible for. Even if you are a one-person shop, adopting Continuous Integration will improve the quality of your software.

 Automating the build and unit tests are steps in the right direction, but a good Continuous Integration process can do more-and eventually you’ll want it to, so you can maximize its usefulness. Thing like code-analysis tools, running tests in addition to unit testing, building an install package, and simulating an install on customer’s PC are all possible through CI process.

  

Continuous Integration with Team Foundation Service

TFS2012 uses a build controller to manage software building tasks. You can install everything onto a single server or split the build process across multiple servers. Build agents are services that can be installed on the same or separate machines to distribute building tasks. A build agent pool is a set of one or more build agents. Figure 2 shows a possible TFS build layout.

TFS assigns a build to a build controller. The builds are queued on a given controller and then taken out of the queue one by one or according to a priority and sent to a build agent. A build controller checks in its build-agent pool for a suitable agent to perform the build. After the build is done, the build agent stores the build artifacts and performs notifications.

 

 

 

 

 

Figure #2: Possible TFS Layouts

 

 

Team foundation build configuration

Before you can add a build to the build queue, you must first define it. You can have as many build definitions as you need. Let’s define a CI build for existing Team Project.

 

 

 

 

 

You are by no means limited to a CI kind of process in TFS. For example, you can have CI builds, scheduled builds, or others. If you create multiple types of builds, I would advise using some kind of a prefix like CI for Continuous Build, sh for scheduled and so on.

 

 

 

After you give the build a name, you can decide what kind of trigger will be used to start the build. See figure below.

 

 

 

 

You can use five possible build triggers

  1. Manual - This is in fact not a trigger. It tells TFS not to do anything until the build is submitted manually to the queue.
  2. Continuous Integration – this trigger follows the CI principle strictly to build after each and every check in
  3. Rolling Build-rolling builds are suitable if your build takes longer than the average check-in rate. In other words, if the developers on your team check in more quickly than the build process, you should choose this type of trigger. It accumulates the check-ins and triggers the build after the currently running build finishes. You can also set a rough equivalent of a quiet period, you can also prevent the build from executing for a given amount of time, during which check-ins are accumulated.
  4. Gated check-in – a gated check-in is a mechanism that prevents bad code from getting into source code repository. It compiles the code and runs unit tests before check-in. everything must pass, or the check-in isn’t allowed.
  5. Schedule – The scheduled trigger lets you organize your builds; for example, you can do a nightly or weekly build.

On the workspace tab, you define the working folder that the build agent will use and the source control folders it will pull from. Use the default, unless you have a more complicated source control layout.

 

On the build defaults tab, since we are using TFS on the cloud, the default will the Hosted build Controller.

 

 

 

 

On the process, you can stick to the default template, click on the Items to Build navigate to the solution file, and choose it. This is the solution that will use for the Continuous Integration build.

 

The last tab controls the build retention. You define how long build information should be kept for a given build’s output. From now on, your Continuous Integration build definition runs on the Cloud. Every time you check in something, the build will trigger. To watch the build queue, double-click the build definition in Team Explorer to open the Build Explorer, and choose the queued tab.

 

 

Done! You've created your first build in the cloud and, because it's a continuous integration build, any time a team member checks in new code, a build is kicked off. And, this can go a long way in helping your team find and fix build-related issues early.

 

 

Happy Coding!

 

 

 

References

https://www.martinfowler.com/articles/continuousIntegration.html

Continuous Integration in .NET