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...