Post on 10-May-2015
description
Advanced CI
I’m Dirk Zittersteyn,Software engineer @ since mid 2013
Did some stuff @ before that
The wonderful world of Continuous Integration.
A.k.a.:
Getting to green
Version Control
Is your team larger than 1 person?
Use version control.
Is your team 1 person?
Use version control.
Big (open source) players
Version control can look overly complicated
Codebase
More awesome
Working
on feature
X
Built feature Y
Finished feature X
Mainline branch
Mainline branch
The mainline stays deliverable
Mainline branch
Branch “New feature”
$ git branch$ hg branch$ svn copy
Mainline branch
Branch “New feature”
Mainline branch
Branch “New feature”
Mainline branch
Branch “New feature”
Integrate your changes
Concurrent work!
Concurrent work
Mainline branch
Branch “New feature”
Branch “Other feature”
To a
void
“In
tegr
ation
Hel
l”
So, are we done?
Concurrency is hard
Meet Charlie.
My code isn’t
broken!
My code isn’t
broken!
You better check yo buildBefore you wreck yo build
Ice Cube
!
Mainline should be green
Agreement ≠ RealityMissing testcases “It’s so simple, it won’t break”
Agreement ≠ Reality‘Bad’ commits $ git commit -m ’removed debug statement’
Agreement ≠ RealityQuick fixes w/o running tests $ git commit -m ’server no longer explodes’
But wait, there’s more!
+ =
!+ = !
Mainline + Branch = New Mainline
!+ != ?
Yes!
!+ !=
Yes(ish)!
!+ !=
Assuming everything is okay.e.g.
all environments are the same, nobody is removing tests,
nobody is setting this up to happen
!+ !=
+ = ?
Mainline:
add(a, b):result = a + breturn result
test_add():assert add(1,1) == 2
+ = ?
Developer A:
add(a, b):+ g.adds += 1
result = a + breturn result
test_add():+ g.adds = 0
assert add(1,1) == 2+ assert g.adds == 1
Developer B:
add(a, b):result = a + b
+ g.adds += 1return result
test_add():+ g.adds = 0
assert add(1,1) == 2+ assert g.adds == 1
Merge A’s changes with mainline
add(a, b):+ g.adds += 1
result = a + breturn result
test_add():+ g.adds = 0
assert add(1,1) == 2+ assert g.adds == 1
Merge B’s changes with mainline
add(a, b):g.adds += 1result = a + b
+ g.adds += 1return result
test_add():g.adds = 0assert add(1,1) == 2assert g.adds == 1
add(a, b):g.adds += 1result = a + bg.adds += 1return result
test_add():g.adds = 0assert add(1,1) == 2
! assert g.adds == 1
!+ =
!
Developer A
Developer B
Does this happen?
if ((err = SSLFreeBuffer(&hashCtx)) != 0) goto fail;if ((err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0) goto fail;if ((err = SSLHashSHA1.update(&hashCtx, &clientRandom)) != 0) goto fail;if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail;if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail;! goto fail;if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) goto fail;
At least, that’s what the NSA wants you to think
Just because you're paranoiddoesn't mean that they're not after you
Joseph Heller
Developers shouldn’t change the mainline
Every merge is a change!
Oh merciful Gatekeeper,
please merge my code!
✓
!
!
Calm down, Try again
!
Calm down, Try again
!
What do we use?Our judge, jury and execut(ion)er
Jenkins-CI.org
• Test execution: py.test
• Code mergingGatekeeper
plugin• Developer notification
Fogbugz plugin
.com/ /paylogic-jenkins-plugins
Running on
Bare metal
Running on
+
Bare metal
Release 1418
Unstable
Unstable
Release 1418
Case 1
Case 2
Unstable
Release 1418
Case 1
Case 2
Unstable
Release 1418
Case 1
Case 2
Unstable
Release 1418
Case 1
Case 2
Unstable
Release 1418
Case 1
Case 2
Unstable
Release 1418
✓
Case 1
Case 2
Unstable
Release 1418
✓
Case 1
Case 2
Unstable
Release 1418
✓
Case 1
Case 2
Unstable
Release 1418
✓
Case 1
Case 2
Unstable
Release 1418
✓
!
Case 1
Case 2
!
Unstable
Release 1418
✓
Case 1
Case 2
!
Unstable
Release 1418
✓
Case 1
Case 2
!
Unstable
Release 1418
✓
Case 1
Case 2
!
Unstable
Release 1418
✓
Case 1
Case 2
!
Unstable
Release 1418
✓
✓Case 1
Case 2
!
Unstable
Release 1418
✓
✓
✓
Case 1
Case 2
!
Unstable
Release 1418
✓
✓
✓
Staging
✓
Case 1
Case 2
!
Unstable
Release 1418
✓
✓
✓
Staging
✓
Release 1420
Case 1
Case 2
So, are we done?