Continuous Integration

What is it?

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

working copies to a shared mainline several times a day.

So what does that mean?

It means that we should be merging feature branches into the main branch (master), regularly.

Why is it important?

The main aim of CI is to prevent us from entering Integration Hell, caused by large unwieldy branches with so many merge conflicts, that it's unclear as to

the working state of the app.

How does it work?

The concept of CI was intended to be used with automated unit tests, written through the practices

of Test Driven Development. Initially, this was just done on the developers local

machine before merging. In recent times however, we tend to utilise build

servers to run these suites for us after every commit

What else does it do?

In addition to unit tests, CI practices now include myriad things such as updating documentation,

static analysis, measure and profile performance, and facilitate manual QA processes.

It also leads us into the practice of Continuous Delivery

Best Practices

→ Maintain a code repository

Best Practices

→ Maintain a code repository→ Automate the build

Best Practices

→ Maintain a code repository→ Automate the build

→ Make the build self-testing

Best Practices

→ Maintain a code repository→ Automate the build

→ Make the build self-testing→ Everyone commits to the baseline every day

Best Practices (cont)

→ Every commit to the baseline should be built

Best Practices (cont)

→ Every commit to the baseline should be built→ Keep the build fast

Best Practices (cont)

→ Every commit to the baseline should be built→ Keep the build fast

→ Test in a clone of the production environment

Best Practices (cont)

→ Every commit to the baseline should be built→ Keep the build fast

→ Test in a clone of the production environment→ Make it easy to get the latest deliverables

Best Practices (cont)

→ Everyone can see the results of the latest build

Best Practices (cont)

→ Everyone can see the results of the latest build→ Automate deployment

Continuous Delivery

What is it?

Continuous delivery (CD) is a software engineering approach in which teams produce software in short

cycles, ensuring that the software can be reliably released at any time.

It aims at building, testing, and releasing software faster and more frequently.

What does that mean?

Every commit to the mainline (master) should be deployable and releaseable to the customers.

It also means we should deploy as soon as that code is merged.

What are some best practices?

CODE ALL OF THE THINGS!All of the scripts to build, test, and deploy the app

should be contained in the project itself.

Separate scripts

We should aim to have a bootstrap script in every project, that sets the machine up with all the

dependencies required to run the app.For example, bundle install, npm install, bower

install, etc

README!!

The README file should list any large dependencies that need to be installed before running the

bootstrap script, and also how to install them!Things like, ruby version, node version, database

server, etc

Build it

If your app requires building before it can be tested, you should create a build script that does that

automatically.

Test suite

Every project should have a test suite, and a way of running that suite.

Create a test script that runs any dependencies for your suite, and then runs the suite itself.

Deployment

Deployments need to be automatedThis means we need to have a scripted way of

deploying to the different environments

Recap Time

→ Merge regularly into common mainline→ Run tests every commit→ Automate everything

→ Keep it fast→ Test in a clone of production

→ Script all of the things

Continuous Integration

It's for everyone