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
- 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
Speak to your mentor if you need a refresher.
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.
Choosing Continuous Integration branching style comes with some rules, and associated practices.
This is the investment needed to make Continuous Integration work.
origin/mastershould pass it’s tests at all times. All commits in master should compile and pass all tests.
origin/mastershould 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.
- 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
- 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
- Have automated deployment into a 1-click deploy.
- Use branch by abstraction and feature toggles to decouple release from deployment.
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
- Trigger a build on Travis CI. Does it pass?
- Open a pull request, does it run your tests?