1. Bill
Havanki
|
Solu.ons
Architect
Charm
City
Linux
|
March
2014
Introduc.on
to
Con.nuous
Integra.on
1Monday, March 24, 14

2. 2
About
Bill
• Jersey
Shore
na.ve
• Rutgers,
NC
State
grad
• Java
development
since
’96
• DoD
contractor
for
15
years
• Clouderan
for
6
months
2Monday, March 24, 14

3. Agenda
• Part
I:
What
is
con.nuous
integra.on
(CI)?
• Part
II:
How
does
CI
relate
to
other
things?
• Interlude:
About
“process”
• Part
III:
How
do
I
start
with
CI?
• Conclusion
and
QA
Time
3
3Monday, March 24, 14

4. Not
CSI
Part
I:
What
is
CI?
4
4Monday, March 24, 14

5. 5
Boring
defini.on
Con.nuous
integra.on
(CI)
is
the
prac.ce,
in
so[ware
engineering,
of
merging
all
developer
working
copies
with
a
shared
mainline
several
.mes
a
day.
-­‐
Wikipedia
5Monday, March 24, 14

6. Real
defini.on
Stop
digging
holes
6
CC
BY-­‐SA
2.0:
Chris
Wimbush
6Monday, March 24, 14

7. XP
Origins
Kent
Beck:
“turn
all
the
knobs
up
to
10”
Don’t
integrate
some.mes,
integrate
all
the
-me
7
CC
BY-­‐SA
2.0:
Rick
Kimpel
7Monday, March 24, 14

8. Benefits
of
CI
• integra.on
happens
before
it
gets
hairy
• no
more
“well,
it
builds
on
my
machine”
• code
stability
• springboard
for
increasing
quality
8
8Monday, March 24, 14

9. Costs
of
CI
• major
features
need
to
evolve,
not
just
drop
• steers
aden.on
toward
fixing
builds
• need
some
infrastructure
• build
needs
to
work
without
a
human
running
it
9
9Monday, March 24, 14

10. A
happy
family
Part
II:
CI
and
Other
Prac.ces
10
10Monday, March 24, 14

11. “ ”Without
some
sort
of
version
control
system
in
place,
you
can't
reasonably
call
yourself
a
so;ware
engineer.
–
Jeff
Atwood
11
11Monday, March 24, 14

12. 12
CI
+
version
control
• first,
you
should
be
using
it
anyway
• neutral,
available
home
for
code
• remembers
past
working
states
for
when
integra.on
fails
• holds
your
branches
that
need
integra.ng
12Monday, March 24, 14

13. CI
+
unit
tes.ng
Unit
tests
indicate
whether
integra.on
has
succeeded
13
hdps://wiki.jenkins-­‐ci.org/display/JENKINS/JUnit+graph,
retrieved
2014-­‐02-­‐21
13Monday, March 24, 14

14. CI
+
automated
builds
• tools
require
a
non-­‐manual
build
process
• builds
must
work
outside
developers’
specific
environments
14
14Monday, March 24, 14

15. CI
+
con.nuous
delivery
F**k
it,
it
15
15Monday, March 24, 14

16. CI
+
con.nuous
delivery
CI
enables
you
to
move
toward
con.nuous
delivery
16
16Monday, March 24, 14

17. Subheading:
Calibri
20pt
approved
light
blue
Aside:
On
Processes
17
17Monday, March 24, 14

18. 18
Lovely
18Monday, March 24, 14

19. Gorgeous
19
19Monday, March 24, 14

20. Oh
my
20
20Monday, March 24, 14

21. Zounds!
21
LICENTIOUSLY
REPUDIATE
THAT CACOPHONY
LICENTIOUSLY
REPUDIATE
THAT CACOPHONY
21Monday, March 24, 14

22. The
purpose
of
process
Good
so[ware
processes
help
you
do
beder
work.
They
serve
you,
you
do
not
serve
them.
22
22Monday, March 24, 14

23. Agile
Manifesto
Individuals
and
interac/ons
over
processes
and
tools
Working
so4ware
over
comprehensive
documenta.on
Customer
collabora/on
over
contract
nego.a.on
Responding
to
change
over
following
a
plan
agilemanifesto.org
23
23Monday, March 24, 14

24. Replacing
you
with
a
small
shell
script
Part
III:
Star.ng
up
CI
24
24Monday, March 24, 14

25. 25
Step
Zero:
Use
version
control
Without
version
control
there
is
no
point
CC
BY
3.0,
Jason
Long
CC
BY-­‐SA
3.0,
Smile4ever
25Monday, March 24, 14

26. Step
One:
Fix
your
builds
• One
step,
like
make
or
mvn
package
• From
a
command
line
• In
a
neutral
and
well-­‐defined
environment
26
26Monday, March 24, 14

27. Step
Two:
Tool
up
A
script
under
cron
can
do
it
27
cd
/home/bill/project
git
pull
mvn
clean
package
if
((
$?
!=
0
));
then
echo
"Build
failed"
|
mail
-­‐s
"Build
failed"
bill@our.com
alex@our.com
fi
27Monday, March 24, 14

28. Step
Two:
Tool
up
• Do
not
build
if
nothing
changed
• Trigger
on
commit
instead
of
using
cron
• Keep
build
logs
and
ar.facts
• Keep
history
of
stability
• Do
more
than
just
compile
...
test,
analyze
...
28
Then
you
get
fancier
28Monday, March 24, 14

29. Step
Two:
Tool
up
And
then
you
realize
you
could
use
a
robust
tool
29
CC
BY-­‐SA
3.0,
the
Jenkins
Project
(hdp://jenkins-­‐ci.org/)
29Monday, March 24, 14

30. OMG
DEMO
TIME
30
30Monday, March 24, 14

31. Step
Three:
Actually
integrate
con.nuously
This
is
the
hard
part.
Your
team
has
to
start
commipng
to
the
mainline
more
frequently.
The
CI
tool
is
your
safety
net.
31
31Monday, March 24, 14

32. Step
Four:
More
stuff
• Add
unit
tests
• Add
sta.c
analysis
like
Findbugs
• Feed
quality
analyzers
like
Sonar
32
32Monday, March 24, 14

33. Step
Five:
Add
lava
lamps
33
hdp://www.devbridge.com/ar.cles/con.nous-­‐integra.on-­‐in-­‐net-­‐projects/,
retrieved
2014-­‐02-­‐24
33Monday, March 24, 14

34. Wherein
we
conclude
Conclusion
34
34Monday, March 24, 14

35. 35
CI
is
just
here
to
help
• catch
regressions
for
you
• check
on
merges
for
you
• generate
handy
reports
for
you
• reduce
your
stress
level
• move
you
to
the
next
level
35Monday, March 24, 14

36. For
more
informa.on
hdp://mar.nfowler.com/ar.cles/con.nuousIntegra.on.html
hdp://www.extremeprogramming.org/rules/integrateo[en.html
hdp://jenkins-­‐ci.org/
36
36Monday, March 24, 14

37. Thank
you
Bill
Havanki
bill@clouderagovt.com
havanki4j@gmail.com
37
37Monday, March 24, 14

38. 38Monday, March 24, 14