Continuous Integration

Lior TalAutomation Developer

Continuous Integration Automated Builds Tools DVCS (Git)

Agenda

Continuous Integration

How good is our code? I think it’s pretty good…

Does the code work? I tested it, it seems to do what it should…

Does the code have bugs? I hope not…

Continuous Integration

Need to simplify complex integration of code Need a good criteria for measuring our code

quality Need to have “Self-testing” code

“a software development practice where members of a team integrate their work frequently, leading to multiple integrations per day.Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.

Continuous Integration

Developer checks in new code An automated build is kicked off with all

latest code changes Unit tests and [optional] other tools are

executed Developer receives a notification if the build

succeeded or failed [optional] Failing commits are rejected from

the source code repository

Continuous Integration

The code should build directly from source control

The code should be built in a single automated command

This makes it easier in multiple scenarios: New developer joins the team Code is built automatically on a build server

Automated Builds

Build script can be created using standard technologies MSBuild Batch file

Multiple build configurations should be defined “Small” build that runs on every check in

Should be very fast “Big” build that runs nightly

Can have a bigger scope (build MSI, run integration tests)

Automated Builds

Many tools can be integrated into the build process

Some examples (.NET): Code Coverage – Coverage (in %) by unit tests. Code Duplications – find duplicated code Code Analysis

StyleCop – Find styling errors in code FXCop – Static code analysis

Tools

Tools – Code Coverage

Tools – Code Coverage

Define a set of styling rules:

These can be run from the IDE or from a build script

Show warnings/errors when compiling:

Tools - StyleCop

Many tools can be integrated into the build process

Some examples (.NET): Code Coverage – Coverage (in %) by unit tests. Code Duplications – find duplicated code Code Analysis

StyleCop – Find styling errors in code FXCop – Static code analysis

Tools – FXCop

Older VCS tools are centralized (central server model) Subversion, ClearCase

Centralized tools suffer from a few issues: Network latency (server needed for most

operations). Submitting “half-ready” code can break other

people’s work.

DVCS (Git)

Many modern VCS tools are distributed This means a central server is optional Each developer gets a copy of the entire

repository A central server can still be setup

Used as a sync point for team members

DVCS (Git)

Git offers a command line tool (comes from Linux)

On Windows: Shell Extension Visual Studio integration using plugins

DVCS (Git)

Git offers a command line tool

On Windows: Shell Extension Visual Studio integration using plugins

DVCS (Git)

Git Workflow

Centralized Workflow

Git Workflow

Integration-Manager

CI Implementation #1

CI Server

Build Agent

TeamCity Source

Control (Git)

CI Build

Nightly Build

CI Implementation #1

What we gained: Basic framework for more complicated tasks Source control contains a “clean” copy of the

code Fast notification on build issues Starting to incorporate basic unit tests Installer (.MSI) creation is automatic Using a modern source control system (Git)

CI Implementation #2

CI Server

Build Agen

t

Git

CI Build

Nightly Build

Build Agen

t

Build Agen

t

…

VM Server

Win7 x64

Win7 Win XP…