Continuous Integration 101

Maor Hayun

19/3/2014

Agenda

Continuous Integration 1

2 Dealing with Dependencies

3 Package Managing – using Nuget

1 Continuous Integration

What did we have before?

Software development life cycle methodologies

• Long development iterations

• Integration as a phase

• Each developer worked on his own environment

• At most, Nightly build

• “Don’t Break the Build” Culture

What is Continuous Integration?

“Continuous integration (CI) is the practice, in software engineering, of merging all

developer working copies with a shared mainline several times a day”

Martin Fowler, May 2006

Main Goal

• Detect integration errors as quickly as possible

• Ability to deploy software to production at any time

Treat Integration as Non-Event

What’s Integration All About

How often is continuously?

As frequently as possible or… at least daily

1 Developer commits changes

2 CI server detects changes

3 Latest code repository is

retrieved

4 Build! 5 Deploy

6 Get Feedback

5 Deploy

CI Core Practices• Maintain a code repository

• Single point of truth, no developer branch, shared ownership

• Automate the Build

• Make your build self-testing• Unit & Integration tests, failed test breaks the build

• Every commit should build on an integration machine

• Keep the build fast

• Test in a clone of the production environment

• Everyone can see what’s happening

• Automate deployment

Well…

THEY’RE MORE WHAT YOU’D CALL GUIDELINES

THAN ACTUAL RULES

The Agile Maturity Model

Level -1

Regressiveunrepeatable, poorly

controlled and reactive

• Manual processes for building software

• No management of artifacts and reports

Level 0

Repeatableprocess documented and

partly automated

• Regular automated build and testing

• Any build can be recreated from source control using automated process

Level 1

Consistentautomated processes applied across whole application lifecycle

• Automated build and test cycle every time a change is committed

• Dependencies managed• Reuse of scripts and

tools

Level 2

Quantitatively Managed

process measured and controlled

• Build metrics gathered, made visible and acted on

• Builds are not left broken

Level 3

Optimizingfocus on process

improvement

• Teams regularly meet to discuss integration problems and resolve them with automation

• Faster feedback and better visibility

By Jez Humble and Rolf Russell | September 2009

http://info.thoughtworks.com/rs/thoughtworks2/images/agile_maturity_model.pdf

• Immediate feedback on code quality & functionality

• Developers detect and fix integration problems continuously

• Constant availability of a "current" build

• Immediate unit testing

• Frequent code commits leads modular, less complex code

• Metrics

• Initial setup time required

• Requires Team’s responsibility and maintenance

CI Anti-Patterns

• Infrequent commits

• Broken builds

• Minimal feedback

• Spam feedback

• Slow Build Machine

• Relying on a bloated build

CI Tools

Demo – TeamCity

2 Dealing with Dependencies

Dependency Hell

1. Too many dependencies Lengthy downloads, not portable easily

“A term for the frustration of software users who have installed software packages which have dependencies on specific versions of other packages.”

Dependency Hell

1. Too many dependencies Lengthy downloads, not portable easily

2. Long dependency chainapp depends on LibA -> LibB -> … > LibZ

“A term for the frustration of software users who have installed software packages which have dependencies on specific versions of other packages.”

Dependency Hell

1. Too many dependencies Lengthy downloads, not portable easily

2. Long dependency chainapp depends on LibA -> LibB -> … > LibZ

3. Conflicting dependenciesapp1 depends on libFoo 1.2, app2 depends on libFoo 1.3

“A term for the frustration of software users who have installed software packages which have dependencies on specific versions of other packages.”

Dependency Hell

1. Too many dependencies Lengthy downloads, not portable easily

2. Long dependency chainapp depends on LibA -> LibB -> … > LibZ

3. Conflicting dependenciesapp1 depends on libFoo 1.2, app2 depends on libFoo 1.3

4. Circular dependencies

“A term for the frustration of software users who have installed software packages which have dependencies on specific versions of other packages.”

3 Package ManagementUSING NUGET

Nuget

• Package Manager for Microsoft ecosystem

• In Nuget Gallery: ~20600 unique packages, ~175K in total

• Provides a centeral location to store common knowledge• code, assemblies, configuration and automation scripts

• Provides concrete solutions rather than guidance, samples or abstract standarts

Nuget Package

Basically, just a simple zip file containg:

• content and source files – to be injected into target project

• PowerShell scripts and executables

• Configuration files and source code transformations• Using David Ebbo’s WebActivator –

light-up-your-nupacks-with-startup-code-and-webactivator.aspx

Nuget Package Structure

Folder structure

• Tools (init.ps1, install.ps1, uninstall.ps1)

• Content

• Manifest (.nuspec file)

• Lib

Nuget Package Manifest

Nuspec manifest file

• Xml file (with XSD available)

• Package metadata

• Can be generated from csproj file

Demo - Nuget

Resources

• Continuous Integration: Improving Software Quality and Reduce Risks• By Paul M. Duval, Steve Matyas, Andrew Glover

• Continuous Integration Manifest• http://martinfowler.com/articles/continuousIntegration.html

• TeamCity • http://www.jetbrains.com/teamcity/

• Nuget• http://www.nuget.org/

• MyGet• http://www.myget.org/