Introduction to Continuous Integration

Preview:

DESCRIPTION

An overview of what continuous integration is, its relationship to other software development practices, and steps to get started. As presented to Charm City Linux on March 25, 2014. http://www.meetup.com/CharmCityLinux/events/168288632/

Citation preview

Bill  Havanki  |  Solu.ons  Architect  Charm  City  Linux  |  March  2014

Introduc.on  to  Con.nuous  Integra.on

1Monday, March 24, 14

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

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

Not  CSI

Part  I:  What  is  CI?

4

4Monday, March 24, 14

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

Real  defini.on

Stop  digging  holes

6

CC  BY-­‐SA  2.0:  Chris  Wimbush

6Monday, March 24, 14

XP  Origins

Kent  Beck:  “turn  all  the  knobs  up  to  10”

Don’t  integrate  some.mes,  integrate  all  the  -me7

CC  BY-­‐SA  2.0:  Rick  Kimpel

7Monday, March 24, 14

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

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

A  happy  family

Part  II:  CI  and  Other  Prac.ces

10

10Monday, March 24, 14

“ ”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

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

CI  +  unit  tes.ng

Unit  tests  indicatewhether  integra.onhas  succeeded

13

hdps://wiki.jenkins-­‐ci.org/display/JENKINS/JUnit+graph,  retrieved  2014-­‐02-­‐21

13Monday, March 24, 14

CI  +  automated  builds

• tools  require  a  non-­‐manual  build  process• builds  must  work  outside  developers’  specific  environments

14

14Monday, March 24, 14

CI  +  con.nuous  delivery

F**k  it,                    it15

15Monday, March 24, 14

CI  +  con.nuous  delivery

CI  enables  you  to  move  toward  con.nuous  delivery

16

16Monday, March 24, 14

Subheading:  Calibri  20pt  approved  light  blue

Aside:  On  Processes

17

17Monday, March 24, 14

18

Lovely

18Monday, March 24, 14

Gorgeous

19

19Monday, March 24, 14

Oh  my

20

20Monday, March 24, 14

Zounds!

21

LICENTIOUSLYREPUDIATE

THAT CACOPHONY

LICENTIOUSLYREPUDIATE

THAT CACOPHONY

21Monday, March 24, 14

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

Agile  Manifesto

Individuals  and  interac/ons  over  processes  and  toolsWorking  so4ware  over  comprehensive  documenta.on

Customer  collabora/on  over  contract  nego.a.onResponding  to  change  over  following  a  plan

agilemanifesto.org

23

23Monday, March 24, 14

Replacing  you  with  a  small  shell  script

Part  III:  Star.ng  up  CI

24

24Monday, March 24, 14

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

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

Step  Two:  Tool  up

A  script  under  cron  can  do  it

27

cd  /home/bill/projectgit  pullmvn  clean  packageif  ((  $?  !=  0  ));  then        echo  "Build  failed"  |  mail  -­‐s  "Build  failed"  \                bill@our.com  alex@our.comfi

27Monday, March 24, 14

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

Step  Two:  Tool  up

And  then  you  realize  youcould  use  a  robust  tool

29

CC  BY-­‐SA  3.0,  the  Jenkins  Project(hdp://jenkins-­‐ci.org/)

29Monday, March 24, 14

OMG  DEMO  TIME

30

30Monday, March 24, 14

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

Step  Four:  More  stuff

•Add  unit  tests•Add  sta.c  analysis  like  Findbugs• Feed  quality  analyzers  like  Sonar

32

32Monday, March 24, 14

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

Wherein  we  conclude

Conclusion

34

34Monday, March 24, 14

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

Thank  you

Bill  Havankibill@clouderagovt.comhavanki4j@gmail.com

37

37Monday, March 24, 14

38Monday, March 24, 14

Recommended