Presenting a short introduction to version control, and how to set up your tools to make sure you can always deploy.
Download the version with annotations here: https://www.dropbox.com/s/nweywk72ztldphf/Advanced%20CI%20Pygrunn%20-%20standalone.pptx
Reinout van Rees wrote a summary of the presentation, which can be found on his blog: http://reinout.vanrees.org/weblog/2014/05/09/continuous-integration.html
Thanks for the intro
I’m Dirk Zittersteyn
I’ll be talking about continuous integration
But you’re not here to hear about me
This is a screenshot of a build of mine on paylogic’s CI server
The green light is so satisfying
It’s like your code is saying: Well done!
So how do you get there?
First off, Version control.
Still use version control.
Which one?
Git is cool, Mercurial is python, subversion is a wise old granddad
Now we have some very powerful tools.
But they seem to do things very complicated!
They don’t magically make things awesome!
You have some codebase, and you start implementing a sweet new feature
Clearly your project is now better
What if you break your build?
Can’t deploy!
Can’t do anything before fixing the bug!
This workflow breaks down with multiple people.
Also, you can’t deploy quickly.
You’ve gone from something that’s pretty useless
To something that’s way more advanced, but still useless
Let’s solve this.
This mainline can be your ‘base’ branch,
In Git: Master
In Mercurial: Default
In SVN: Trunk (kinda)
Or any other branch, by convention
Deliverable means: it works.
You create a branch, which is a copy of the mainline
You work on your copy, and you commit
Nothing happens in the mainline
You can break your branch, but not the mainline!
And when you’re convinced your feature is done, you merge!
You can now do more than one thing at the same time!
You decide to work on two features, at the same time!
Integrate Often!
Why?
Glengarry GlenRoss
The longer you wait to integrate, the harder it is.
That would make for a really short talk
We aren’t.
Not just in algorithms,
also in development!
Charlie is a programmer.
He thinks he’s quite clever.
Now obviously, I would never commit broken code,
But charlie does!
Now your mainline is broken!
And it breaks for everyone!
Finger pointing results
And finger pointing can be very wrong.
My code might be buggy as well, but hidden by the other bug!
This situation is so common…
Someone made the effort to make this.
How do we solve this?
Don’t merge broken code!
Never!
You make an agreement with your devs: Don’t commit broken code.
It’s so easy, it won’t break anything
For example accidentally leaving debug statements in your code
But even when you disregard this
Even when you do everything right, we’re making an assumption
Merging good code in a good mainline results in a good new mainline
And we want to count the number of adds we do.
Well, maybe?
Ofcourse, there are plenty of people that say this is an intentional vulnerability,
Used by the nsa to spy on us.
Joseph heller said the following in the book catch-22
This not only works for Surveilance agencies, but also for keeping your mainline safe.
Ergo, developers shouldn’t do the merging
We start with a mainline
You branch
And somebody makes a change in the mainline (doesn’t matter how)
You test your build
You test your build
And the build is successful
You request
The Gatekeeper merges the code into the mainline, but doesn’t commit yet!
First the build is tested
If the build succeeds?
The changes are commited to the mainline
Much rejoicing
The merge is discarded,
And the developer is notified
Developer f
And ask for forgiveness
With a very pretty please.
For bare metal we use our ‘old’ hardware, using Wake-on-LAN to conserve power
When the bare metal is fully used, and there’s still more, we spin up a couple of DigitalOcean droplets
Tasks are distributed over multiple nodes with py.test xdist
For bare metal we use our ‘old’ hardware, using Wake-on-LAN to conserve power
When the bare metal is fully used, and there’s still more, we spin up a couple of DigitalOcean droplets
Tasks are distributed over multiple nodes with py.test xdist
And the cycle continues!
That would make for a really short talk
We aren’t.