Chapter 1: Getting Started

Build Software at Every Change

What is a Build?

A build is much more than a compile (or its dynamic language variations). A build may consist of the compilation, testing, inspection, and deployment—among other things. A build acts as the process for putting source code together and verifying that the software works as a cohesive unit.

Version Control Repository
Simply put, you must use a version control repository in order to perform CI. In fact, even if you don’t use CI, a version control repository should be standard for your project. The purpose of a version control repository is to manage changes to source code and other software assets (such as documentation) using a controlled access repository.

A CI server runs an integration build whenever a change is committed to the version control repository. Typically, you will configure the CI server to check for changes in a version control repository every few minutes or so. The CI server will retrieve the source files and run a build script or scripts. CI servers usually provide a convenient dashboard where build results are published. Although it is recommended, a CI server isn’t required to perform continuous integration.

Build Script
The build script is a single script, or set of scripts, you use to compile, test, inspect, and deploy software. You can use a build script without implementing a CI system. Ant, NAnt, make, MSBuild, and Rake are examples of build tools that can automate the software build cycle, but they don’t provide CI by themselves. To be clear, using an IDE to run a build is appropriate as long as you can run the same build without using the IDE as well.

Feedback Mechanism
One of the key purposes of CI is to produce feedback on an integration build, because you want to know as soon as possible if there was a problem with the latest build. By receiving this information promptly, you can fix the problem quickly.

Integration Build Machine
The integration build machine is a separate machine whose sole responsibility is to integrate software. The integration build machine hosts the CI server, and the CI server polls the version control repository.

Features of CI
Now that we have an example to build from, we can delve into the features of CI. There are only four features required for CI.

• A connection to a version control repository
• A build script
• Some sort of feedback mechanism (such as e-mail)
• A process for integrating the source code changes (manual or CI server)

By performing automated and continuous database integration, testing, inspection, deployment, and feedback, your CI system can reduce common risks on your project, thus leading to better confidence and improved communication. Some features depend on other features; for instance, automated testing depends on source code compilation.

Source Code Compilation
Continuous source code compilation is one of the most basic and common features of a CI system. In fact, it’s so common that it has almost become synonymous with CI. Compilation involves creating executable code from your human-readable source.

Database Integration
Some people consider the source code integration and integration of the database as completely separate processes—always performed by different groups. This is unfortunate because the database (if you are using one on your project) is an integral part of the software application. By using a CI system, you can ensure the integration of a database through a single source: your version control repository.

We treat the database source code—Data Definition Language (DDL) scripts, Data Manipulation Language (DML) scripts, stored procedure definitions, partitioning, and so on—in the same manner as any other source code in the system. For instance, when a project member (developer or DBA, for instance) modifies a database script and commits it to the version control system, the same build script that integrates source code will rebuild the database and data as part of the integration build process.

Testing
Many consider CI without automated, continuous testing not to be CI. We couldn’t agree more. Without automated tests, it is difficult for developers or other project stakeholders to have confidence in software changes. Most developers on projects that use a CI system use unit testing tools such as JUnit, NUnit, or other xUnit frameworks to run tests. Furthermore, you can run different categories of tests from a CI system to speed up your builds. These categories may include unit, component, system, load/performance, security, and others.

Inspection
Automated code inspections (e.g., static and dynamic analysis) can be used to enhance the quality of the software by enforcing rules. For instance, a project might have a rule that no class may be longer than 300 lines of non-commented code. You can use your CI system to run these rules automatically against a code base.

Deployment
Many processes encompass what is considered deployment. In fact, most of the other processes discussed in this section are a part of the deployment process. Continuous deployment enables you to deliver working, deployable software at any point in time. This means a key purpose of a CI system is to generate the bundled software artifacts with the latest code changes and make it available to a testing environment. CI can even automatically deploy or install files to the appropriate environment.

Documentation and Feedback

Many developers work under the firm belief that documentation belongs in the source code, in fact, that clear, concise code with well chosen class, variable, and method names (for instance) is the best documentation. A CI system can provide the benefits of documentation without some of the hassles. You can use tools such as Maven, Javadoc, or NDoc to generate documentation. Moreover, there are tools that can generate class diagrams and other information, all based on the committed source code in your version control repository. You’ll find significant benefits in obtaining near-real-time documentation of source code and project status using your CI system.

 

A critical feature to good CI systems is speed. The essence of a CI system is to provide timely feedback to developers and project stakeholders. It’s easy to load so much into a CI system—for the sake of completeness—that it takes an unreasonable amount of time to finish a cycle. As such, a balance must be struck between the breadth and depth of a CI process against the need to provide rapid results. This is especially important when using continuous testing. We discuss techniques for creating fast builds in Chapters 4 and 6.

 

How do you know you are doing CI correctly? These questions can help you decide what’s missing on your projects –

  • Are you using a version control repository (or SCM tool)?
  • Is your project’s build process automated and repeatable? Does it occur entirely without intervention?
  • Are you writing and running automated tests?
  • Is the execution of your tests a part of your build process?
  • How do you enforce coding and design standards?
  • Which of your feedback mechanisms are automated?
  • Are you using a separate integration machine to build software?
Advertisements
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: