Continuous Integration in .NET

Craig Berntson, Marcin Kawalerowicz

• Éditeur: Manning
• Année: 2011
• ISBN:
  9781638352136
• Sujet: Informatique
• Sous-sujet: Programmation Microsoft

Continuous integration is a software engineering process designed to minimize "integration hell." It's a coordinated development approach that blends the best practices in software delivery. For.NET developers, especially, adopting these new approaches and the tools that support them can require rethinking the development process altogether. Continuous Integration in.NET is a tutorial for developers and team leads that teaches readers how to re-imagine their development strategy by creating a consistent continuous integration process. This book shows how to build on the tools they already know -.NET Framework and Visual Studio - and to use powerful software like MSBuild, Subversion, TFS 2010, Team City, CruiseControl.NET, NUnit, and Selenium. Purchase of the print book comes with an offer of a free PDF, ePub, and Kindle eBook from Manning. Also available is all code from the book.

Part 1. Make it happen

A technically savvy programmer and project manager once asked how we’d describe continuous integration (CI) to someone who had never heard of it. We said there are two types of answers, and which one to give depends on how much time the listener has. The longer answer starts with part 1 of the book. The shorter one is not really an answer—it’s another question that can give you an idea about what CI is. Do you remember the last time you released software? That’s the time in the project when you gather all the bits and pieces required to deliver the software to the customer. Was it painful? Yes? Well, that’s where CI can come to the rescue.

In the first part of this book (chapters 1 through 6), we’ll lay the groundwork for a well-designed CI process in .NET. You’ll learn the basics required for any CI system. We’ll start by looking at CI in general. We’ll define the term and talk a little about how to do CI in .NET. After that, we’ll introduce the source control system as part of the CI tool chain that can’t be omitted. We’ll help you choose the right one and introduce it into your day-to-day work.

As a second ingredient that’s required for CI, we’ll describe build automation. We’ll show why you need a single command-build process and how modern XML-based build systems are perfect for the .NET CI process. You’ll also find out how to choose the right CI server to bind all the ingredients into one.

We’ll then look at unit testing—what it is and how to use it in CI. You’ll learn to write unit tests and automate their execution. We’ll discuss CI servers and their ability to give immediate feedback about the state of the build process. It’s a core concept of the CI process that every degradation in code quality should be immediately visible, so the team can react as swiftly as possible to make obstacles disappear. This is the purpose of controlling and reporting mechanisms in modern CI servers. We’ll look at how you can extend these reporting capabilities with your software.

After reading this part of the book, you’ll be able to set up your own CI process using free or inexpensive software. You’ll understand what the CI process is and how to use it to your team’s benefit. And you’ll be ready to extend CI to better suit your needs.

Chapter 1. Understanding continuous integration

This chapter covers

• Continuous integration theory
• A Hello World CI example
• A preliminary list of CI tools

As developers, we’re interested in creating the best possible applications for our customers with the least amount of work. But with applications becoming more complex and having more moving parts, creating great applications is getting harder, even with advances in tools such as Visual Studio and the .NET Framework.

One of the keys to improving applications and productivity is to automate some of the work. Continuous integration (CI) is one of the best ways to do this.

Have you ever written code that did its small task perfectly, but then discovered unexpected side effects when you integrated that piece of code with the rest of the application? Do you always have success integrating your code with code from other developers? Have you ever shipped an application, only to find that it didn’t work for the customer but you couldn’t duplicate the error? Can you always predictably measure the state of the code for your current project? CI helps alleviate these problems and more.

In this chapter, you’ll learn what CI is all about, why should you use it, and how to overcome objections to its adoption from your team. We’ll briefly introduce you to several free or low-cost tools such as CruiseControl.NET, Subversion, MSBuild, Team Foundation Server, and TeamCity that are part of a complete CI process. Throughout the rest of the book, we’ll explain in detail how to use these tools.

This chapter also demonstrates a simple CI process through an example using batch files. We’ll also get started on a more complex Visual Studio Solution that we’ll use to demonstrate various CI tools and techniques. But before we do any of that, you need to understand exactly what CI is.

1.1. What does it mean to integrate continuously?

When you adopt CI, it’s likely that you’ll make major changes in your development processes because you’ll move from a manual system to an almost completely automated system. Along the way, you may meet resistance from your team members. This section provides you with reasons to use CI and how to overcome objections. But before we take you there, we need to define CI.

1.1.1. Defining continuous integration

One of the best definitions of continuous integration comes from Martin Fowler (www.martinfowler.com/articles/continuousIntegration.html):

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.

This definition contains an important phrase: “multiple integrations per day.” This means that several times each day, the CI system should build and test the application. But multiple integrations per day isn’t where you begin your journey into CI; we recommend against this because many shops not using CI will meet enough resistance just automating the build, let alone doing multiple builds per day. (We’ll talk more about overcoming team resistance later in this chapter.) Ideally, you should set up your CI process just as you create software: by taking small steps, one at a time.

Here is another definition:

CI is the embodiment of tactics that gives us, as software developers, the ability to make changes in our code, knowing that if we break software, we’ll receive immediate feedback ... [It is] the centerpiece of software development, as it ensures the health of software through running a build with every change.

Paul Duval, Continuous Integration
(Addison-Wesley, 2007)

The key phrase here is “the centerpiece of software development.” This means whatever development process and methodology you use, CI is a key part of it.

Our definition is similar to those we’ve mentioned. Here’s how we define continuous integration:

An automated process that builds, tests, analyzes, and deploys an application to help ensure that it functions correctly, follows best practices, and is deployable. This process runs with each source-code change and provides immediate feedback to the development team.

As we were discussing this definition, we wondered what a build is. Is it the same as clicking Build on the Visual Studio menu, or something more? We finally decided that the definition varies depending on what you’re doing. Early in the development process, a build can be as simple as compiling and unit testing the code. As you get closer to release, a build includes additional and more complete testing and running code metrics and analysis. You can also go as far as combining all the different files into an install set and making sure it works correctly.

Fin...