Issuu on Google+


Consulting  Services  

Contents   Contents  ..................................................................................................................................................  2   Introduction  ..........................................................................................................................................  3   Sources  ....................................................................................................................................................  3   Subversion  and  Review  Board:  Simple  Configuration  Management  ............................  3   Simple  Administration  .................................................................................................................  3   Simple  Development  Process  ...................................................................................................  3   Implementation  Guidelines  .......................................................................................................  4   Jenkins:  An  Enabler  for  Agile  Development  ............................................................................  4   Why  Jenkins?  ....................................................................................................................................  5   Implementation  Guidelines  .......................................................................................................  5   Component-­‐based  Development  ..................................................................................................  6  

   

 

 

2  


Consulting  Services  

Introduction   Historically,  the  legacy  Source  Code  Management  (SCM)  systems  IBM  Rational   ClearCase  and  IBM  Rational  Synergy  placed  the  control  of  the  software   development  process  firmly  in  the  hands  of  the  configuration  managers,  with   developers  required  to  jump  through  hoops  to  accomplish  their  jobs.   Fortunately  software  development  has  moved  on  with  the  rise  in  popularity  and   adoption  of  more  agile  development  processes,  seeing  a  shift  in  responsibility   towards  the  developers  –  who  want  to  spend  their  time  developing,  not  doing   configuration  management.    Tools  such  as  Subversion  and  Jenkins  have   infiltrated  corporate  environments,  installed  on  user’s  desktops,  with  legacy  SCM   systems  being  used  periodically  to  satisfy  project  mandates.   Subversion  and  Jenkins  are  designed  to  support  a  wide  range  of  development   processes,  but  the  key  is  that  the  development  process  needs  to  be  defined.  It  is   not  sufficient  to  use  the  tools  –  they  must  be  used  in  the  correct  way.   This  paper  highlights  how  to  transition  from  a  heavier  development  process   implemented  in  the  aforementioned  tools  to  a  more  agile  development  process   using  Subversion,  Jenkins  and  Review  Board.  

Sources   • •

http://svn.apache.org/repos/asf/subversion/trunk/doc/user/svn-­‐best-­‐ practices.html   https://wiki.jenkins-­‐ci.org/display/JENKINS/Meet+Jenkins    

Subversion  and  Review  Board:  Simple  Configuration   Management   Simple  Administration   •

• •

Administration  of  Subversion  is  extremely  easy  when  compared  to  other   legacy  SCM  tools.  Software  installation  and  configuration  can  be   completed  in  under  20  minutes  with  a  new  repository  created  in  seconds.     There  is  no  dependency  on  an  external  database,  avoiding  the  additional   administrative  burden  that  comes  with  it.   Backup  of  repositories  can  occur  without  disruption  to  the  users  –  no   need  to  make  the  server  read-­‐only  or  take  the  server  offline  whilst  the   backup  is  taking  place.  

Simple  Development  Process  

 

Subversion  enforces  no  development  process,  but  allows  Configuration   Managers  to  define  their  own  process  based  on  current  best  practices.  

The  key  to  implementing  a  simple  development  process  is  to  limit  the   need  to  branch.    When  using  branches,  developers  need  to  spend  more   time  doing  configuration  management:  branches  need  to  be  kept   synchronized  with  the  main  line  of  development,  minimising  divergence   3  


Consulting  Services   of  the  code  and  thus  the  number  of  conflicts  that  will  arise  when  the   branch  is  subsequently  merged  back  to  the  main  line.   •

“With  great  power  comes  great  responsibility”:  developers  have  more   control  over  their  code,  but  also  have  a  responsibility  for  the  code  they   check-­‐in  to  the  trunk.  

Subversion  allows  developers  to  share  code  changes  without  branching   or  committing  the  code  to  the  repository  using  patch  files.  Review  Board   uses  Subversion  patchfiles  to  track  peer  reviews  of  code  in  a  central   location.  

Implementation  Guidelines   •

Define  process  for  branching  and  conventions  for  branch  naming.  All   users  on  a  project  should  adhere  to  documented  conventions,  for  the  sake   of  clarity  and  to  prevent  errors  during  the  development  process.  

Create  access  controls  to  protect  tags  from  further  modification.  Tags   should  be  immutable  once  they  are  created,  but  Subversion  doesn’t   prevent  further  modifications  to  a  tag  with  its  out-­‐of-­‐the-­‐box   configuration.  

Users  commit  their  day-­‐to-­‐day  work  on  /trunk  after  it  has  been  peer-­‐ reviewed  using  Review  Board.  Once  the  user  is  ready  to  have  their     changes  peer-­‐reviewed,  they  create  a  patch  file,  create  a  review  task  on   Review  Board  and  upload  the  patchfile  to  the  review  task.  The  person   performing  the  peer  review  can  view  the  individual  file  changes  within   review  board,  and  could  even  use  the  patchfile  to  apply  the  changes  to   their  own  working  copy  in  order  to  run  further  tests.  

Rule  #1:  /trunk  must  compile  and  pass  regression  tests  at  all  times.   Committers  who  violate  this  rule  are  disciplined.  The  use  of  Continuous   Integration  will  highlight  when  this  occurs,  so  it  will  be  immediately   obvious  who  caused  CI  to  fail.    

Rule  #2:  a  single  commit  (changeset)  must  not  be  so  large  so  as  to   discourage  peer-­‐review.  If  a  developer  has  made  so  many  changes  that   they  cannot  be  realistically  reviewed  together,  then  they  need  to  be  split   into  multiple  changesets.  

Rule  #3:  if  rules  #1  and  #2  come  into  conflict  (i.e.  it's  impossible  to  make   a  series  of  small  commits  without  disrupting  the  trunk),  then  the  user   should  create  a  branch  and  commit  a  series  of  smaller  changesets  there.   This  allows  peer-­‐review  without  disrupting  the  stability  of  /trunk.  

Jenkins:  An  Enabler  for  Agile  Development   Key  to  making  agile  development  work  is  the  implementation  of  Continuous   Integration  to  provide  constant  automatic  feedback  on  the  code  being   committed.  This  allows  bugs  and  code  regressions  to  be  caught  soon  after  they   are  introduced,  and  are  therefore  easier  to  fix.  

 

4  


Consulting  Services  

Why  Jenkins?   •

Jenkins  is  an  award  winning  open  source  build  server  supporting   Subversion,  amongst  other  SCM  tools.    

Integrated  plug-­‐ins  for  publishing  build  reports  generated  by  a  variety  of   static  code  analysis  and  test  coverage  tools.  

Easy  to  install,  and  does  not  require  the  necessity  for  an  additional   database.  

It  can  be  configured  entirely  from  its  user-­‐friendly  web  GUI  with   extensive  on-­‐the-­‐fly  error  checks  and  inline  help  menus.  

Can  generate  a  list  of  changes  made  into  the  build  from  Subversion/CVS.   This  is  accomplished  in  an  efficient  fashion  in  order  to  reduce  the  load  on   the  repository.  

Provides  clean  readable  URLs  for  most  of  its  pages,  including  permalinks   such  as  "latest  build"/"latest  successful  build",  that  can  be  easily  linked   from  elsewhere.  

Can  easily  distribute  build/test  loads  to  multiple  computers.    

Keeps  track  of  which  build  produced  which  artifacts,  and  which  build  is   using  which  version  of  the  artifacts,  and  so  on.  This  works  even  for   artifacts  that  are  produced  outside  Jenkins,  and  is  ideal  for  projects  to   track  dependency.  

Implementation  Guidelines  

 

Install  the  “Subversion  tagging”  plugin  to  allow  post-­‐build  tagging   operations  from  within  Jenkins.    A  successful  build  will  always  be   retrievable  from  Jenkins,  and  the  revision  of  the  code  that  generated  the   build  is  captured  as  part  of  the  build  information.  In  order  to  have  a   record  of  the  revision  of  a  successful  build  within  Subversion  itself,  the   “Subversion  tagging”  plugin  is  used  to  create  a  tag  from  the  revision  of   builds  that  are  successful.  

Install  the  “Copy  artifact”  plugin  to  allow  build  artifacts  to  be  used  as  the   input  to  other  build  projects,  thus  creating  a  sequence  of  build  projects   known  as  a  “build  chain”.  It  is  often  the  case  that  some  build  projects  are   expensive  to  run  in  terms  of  time  and  compute  resources.  As  such,  these   should  be  triggered  “downstream”  only  upon  successful  execution  of   more  basic  build  projects  such  as  compilation  and  unit  tests.  The   downstream  build  projects  will  take  the  build  artifacts  of  upstream   projects  as  input.  Jenkins  will  finger  print  the  artifacts  to  keep  track  of   them  as  they  are  utilized  through  the  build  chain.  

Install  the  “Promoted  builds”  plugin  to  enable  the  ability  to  promote   builds  following  successful  execution  of  downstream  build  projects.  When   the  more  expensive  build  projects  in  the  latter  stages  of  the  build  chain   complete  successfully,  the  build  that  initially  created  the  build  artifact  is   promoted  to  indicate  that  it  is  mature  enough  to  be  passed  to  the  next   phase  of  the  project  lifecycle,  for  example  testing  by  a  QA  team  or  even   5  


Consulting  Services   deployment  into  production.  Promotion  can  be  triggered  automatically  as   post-­‐build  operation,  or  manually  from  within  the  Jenkins  web-­‐gui.   Promotion  can  itself  trigger  further  build  projects  to  run,  for  example  to   deploy  or  archive  the  build  artifact.   •

Use  Jenkins  CLI  to  clone  build  projects  when  branching.  Typically  build   projects  are  configured  to  fetch  source  code  from  the  main  line  of   development.  When  working  on  a  branch  it  may  be  desirable  to  have   Continuous  Integration,  in  which  case  the  most  convenient  method  of   configuring  new  build  project  for  the  branch  is  to  clone  the  existing  build   projects.  The  cloned  build  project  will  checked  out  from  the  location  of   the  branch  instead  of  the  main  line.  

Component-­‐based  Development   Programming  best  practices  dictate  that  large  software  systems  be  broken  down   into  smaller  modular  sub-­‐systems,  called  components.  This  enables  better  re-­‐use   of  code,  and  leads  to  fewer  conflicts  in  code  changes  as  it  reduces  the  number  of   developers  working  on  a  particular  set  of  files.  Subversion  and  Jenkins  can  be   used  for  component-­‐based  development  by  following  these  guidelines:    

 

Each  component  follows  its  own  release  cycle,  culminating  in  a  new   tagged  version  for  the  component.  

Use  “svn:externals”  definitions  for  shared  component  referencing.  The   target  of  the  “svn:externals”  definitions  referencing  the  shared   component  should  be  a  tag  of  the  component.  A  “latest”  tag  can  be  created   for  the  shared  component,  which  is  derived  from  the  latest  static  tag  of   the  component.  This  ensures  all  components  are  always  referencing  the   same  version  of  the  shared  component.    

Care  must  be  taken  when  creating  tags  with  components  that  include   “svn:externals”  to  ensure  that  they  point  to  static  tags  of  the  sub-­‐ component  themselves.  This  can  be  automated  via  the  use  of  release   scripts,  that  will  modify  the  “svn:externals”  definitions  after  a  component   has  been  tag,  and  then  creates  an  access  rule  to  prevent  further   modification  to  the  tag.  

Use  build  dependencies  for  ensuring  automated  integration  testing  of   shared  components.  A  build  project  should  be  created  to  watch  for   changes  to  the  “latest”  tag  of  the  shared  component,  and  if  a  change  is   detected  it  will  trigger  the  build  project  execution  for  all  components  that   reference  the  shared  component.  

The  top-­‐level  component  is  simply  a  tag  made  up  of  the  collection  of   tagged  sub-­‐components.    This  is  the  result  of  an  “svn  copy”  from  the  tag   content  of  each  sub-­‐component  component,  and  this  much  is  apparent   when  looking  at  the  Subversion  log  (as  well  as  the  name  of  the  path  itself).  

A  Jenkins  project  will  be  configured  for  the  top-­‐level  component  setup  to   monitor  promoted  artefacts  from  the  sub-­‐component  builds.  If  the  job  is   successful,  the  original  component  artefacts  should  be  promoted  in  

6  


Consulting  Services   Jenkins,  and  further  build  projects  with  more  time  consuming  and   thorough  tests  can  be  started  as  a  result.     •

 

The  top-­‐level  tag  will  be  created  as  a  post-­‐build  operation  using  a  release   script,  which  will  take  care  of  instantiating  access  control  rules  to  prevent   further  modification  of  the  tag.  

7  


Software development with SVN, Reviewboard and Jenkins