Improving software delivery in every organisation

Continuous Integration

This workshop assumes you are already familiar with Git, and the concept of Pull Requests.

In this workshop we assume that you have locally configured your shared git remote to be named origin.

Prerequisites

  • You need a project hosted on GitHub (preferably open-sourced, and without an automated build tool configured for it).

Before continuing, make sure that you can:

  • Draw out a simple Git branch with commits that apply on top of each other.
  • Draw out what happens when a Git branch is merged with two parent commits.
  • Draw out what happens when a Git branch is rebased ontop of a branch with commits.
  • Explain what HEAD, master and origin/master refer to.

Speak to your mentor if you need a refresher.

Git Branching

Martin Fowler talks about the different approaches to branching, and weighs up the relative pros and cons of each approach.

You should go ahead and read that article, as it’s invaluable knowledge.

At Made Tech we practice “Continuous Integration” branching style, as we have come to the same shared agreement that the pros of this approach outweigh the cons.

  • Why do you think that is?
  • Discuss with someone else your thoughts on when “Continuous Integration” branching would not be appropriate.

The Trade-off

Choosing Continuous Integration branching style comes with some rules, and associated practices.

This is the investment needed to make Continuous Integration work.

Some Rules

  • origin/master should pass it’s tests at all times. All commits in master should compile and pass all tests.
  • origin/master should be deployable at all times. All commits in master should be of sufficient quality to be deployed.
  • Where necessary, release should be decoupled from deploy. It should be possible to deploy master, and turn on new features independently.
  • Pull requests should be short lived (~4 working hours maximum), and short (~400 lines of code maximum). Pull requests should be simple to review.
  • Pull requests should pass all tests, and not have any linter warnings (where appropriate). Pull requests should be tested before merging.

Some Practices

  • Build new functionality in small increments, by employing a good software architecture and a comprehensive suite of tests.
  • Use an automated build tool (e.g. Jenkins, Travis, Gitlab CI, CircleCI, etc) to run tests every time a new commit is pushed to origin/master
  • Use an automated build tool to run tests every time a new commit is pushed to a Pull Request branch, and also run the tests as an “Integration” with master. (More on this later)

Not covered in this workshop

Automating Tests

We’re going to use Travis CI to automate some tests.

First, you’ll need to pick a project to automate tests on. If you have built this project with someone else, pair or mob with them through this part of the workshop.

If your project is open-sourced you can use a cloud-hosted build tool such as Travis CI for free, otherwise you’ll need to pay a subscription.

If you are using RSpec your .travis.yml file can be as simple as:

language: ruby
script: bundle exec rspec
rvm:
  - 2.5.0

If your GitHub project is at github.com/craigjbass/tictactoe, your Travis CI build will be at travis-ci.org/craigjbass/tictactoe.

  • Trigger a build on Travis CI. Does it pass?
  • Open a pull request, does it run your tests?

How effective is your business at software delivery?

Answer these 20 questions and find out where the principal software delivery challenges lie within your organisation.

Get started now