Continuous integration 101

31
Continuous Integration 101 by Manuel Spezzani Bologna, October 30, 2014

Transcript of Continuous integration 101

Continuous

Integration 101

by Manuel Spezzani

Bologna, October 30, 2014

Manuel SpezzaniTechnical Lead

IConsulting S.p.A.

[email protected]@indyco.com

@manuelspezzanihttp://it.linkedin.com/in/manuelspezzani/it

Me, myself & indyco

What is Continuous

Integration

Continous integration before

Continous integration after

A basic continuous

integration process

At every commit:

Get latestsources

Build Test Package

Even if one minor test fails, the build is marked as RED

A basic continuous

integration process

No IDE allowed!

Sources comes from ONE repository

Build scripts are sources

Database scripts are sources

Test everything!

Database scripts counts as everything

No-one needs 100% coverage , everyone needs 100% confidence !

Continous integration and me

More discipline

Checkin frequently

Don’t checkin broken / untested code!

Don’t checkin when the build is broken

Don’t go home after checking in until the system builds

http://www.thoughtworks.com/continuous-integration

Why?

Efficiency

Automate Everything

No monkey-work

Coded, self-documented processes

Reproducibility

Reduce human errors

Artifact versioning and traceability

Release early – release often

Ensure the mainline is always shippable

Reduce packaging and release time

Multiple configurations

Environment OS

Browsers

Network

Third-party integrations Databases

Libraries

Where to start?

Set a goal: 1-click release

Clear and easy to measure

It’s easy to estimate a «ROI»

You can sell it to your boss!

Involves a lot of processes

Probably it will change the way you work

Set rules, and follow them

Developers have no access to C.I. servers

No log-in access

No file-system access

No-one is allowed to release manually

Build == Code

Coding principles applies

KISS

DRY

YAGNI

The build should evolve with your project

Wich one?

Anti-Patterns

Fragility

Occasional failures

«Don’t stop that build» syndrome

Interference

Shared resources

Limitation on concurrent build

Limitation on concurrent tests

Reproducibility

Dependency hell

Developers have to access the CI machines to throubleshoot

build issues

The build script can’t be executed a standard dev machine

Poor feedback

The build takes too long

Email notifications

Moving forward

Personal build

Nightly build as a companion

Useful when:

Working on large projects, with lot of integration / UI tests

Resource intensive builds

Be careful:

Daily integration is not enough!

http://www.alittlemadness.com/2009/01/27/continuous-integration-myth-ci-vs-nightly-builds/

Continuous delivery

Your software is deployable throughout its lifecycle

You can perform push-button deployments of any version of

the software to any environment on demand

http://martinfowler.com/bliki/ContinuousDelivery.html

http://blog.crisp.se/2013/02/05/yassalsundman/continuous-delivery-vs-continuous-deployment

Continuous deployment

Your software is deployed throughout its lifecycle

Is it a good idea or not? It depends on your business!

http://blog.crisp.se/2013/02/05/yassalsundman/continuous-delivery-vs-continuous-deployment

…and more!

Automated performance check

Git(Hub) Flow

Continuous Integration 101by Manuel Spezzani

Bologna, October 30, 2014