4/23/15  

1  

Release Automation

Better Quality Faster Deployment

Amazing ROI

Overview METHODOLOGY   PROCESS   TOOLS  

4/23/15  

2  

DevOps = Release Automation

DevOps is Methodology It’s a way of doing

things, not what things to do.

DevOps with Agile

DEVELOPMENT  

EXECUTIVES  

BUSINESS  

IT  OPERATIONS  

AGILE  

DEVOPS  

4/23/15  

3  

HP Case Study >  3  year  transformaFon  Fme  (2008  to  2011)  >  Overall  dev  costs  reduced  by  ~40%  >  AcFve  programs  in  development  up  ~140%  >  Dev  costs  per  program  down  78%  >  Resources  freed  up  to  work  on  innovaFon  up  500%  

They  went  from    

Build  cycle  =me:  1  week  TO  3  hours  (10–15  builds  per  day)  Commits:  1  code  commit/day  TO  100  commits/day  Regression  test  cycle  =me:  6  weeks  TO  24  hours  

 

How? • Architecture  DirecFon  

• All  LaserJet  code  in  main  trunk  • Design  to  fight  impediments  mid-­‐sprint  (put  out  fires/phoenixes)  

• Full  system  in  Dev  • Acceptance  test  in  non-­‐integrated  environment  

• IntegraFon  uses  “test  doubles”  • CI  to  CD  to  CD  • Test  AutomaFon  and  Process  AutomaFon  

• Planning  Process  (Agile  and  DevOps)  

4/23/15  

4  

Economics Puppet  Labs  2014  DevOps  Survey  

DevOps  Users  

30X more  frequent    deployments  

8,000X faster  lead  Fmes    than  their  peers  

50% fewer    failures  

Automation Maturity

Con=nuous    Deployment  

CD  

CI  

Test  AutomaFon  

CD  

CDel  

CI  

Test  Automa=on  EFFORT  

MATURITY

 

4/23/15  

5  

CI Roadmap •  “Keep  a  single  place  where  all  the  source  code  lives  and  

where  anyone  can  obtain  the  current  sources  from  (and  previous  versions)  

•  Automate  the  build  process  so  that  anyone  can  use  a  single  command  to  build  the  system  from  the  sources  

•  Automate  the  tes6ng  so  that  you  can  run  a  good  suite  of  tests  on  the  system  at  any  ;me  with  a  single  command  

•  Make  sure  anyone  can  get  a  current  executable  which  you  are  confident  is  the  best  executable  so  far.”  

-­‐Mar;n  Fowler  “Con;nuous  Integra;on”  (Essay)  

September  2000  

CI Process Plan  IteraFon  • Review  and  EsFmate  

Code  • Unit  Test  

Build  • Unit  Test  • Unit  IntegraFon  Test  

Deliver  • Acceptance  Test  

Deploy  • Acceptance  Test  

Performance  and  Security  TesFng  too!  

Performance  and  Security  TesFng  too!  

Performance  and  Security  TesFng  too!  

Performance  and  Security  TesFng  too!  

4/23/15  

6  

CI in Action

Code  

Unit  Test  

Build  

Integrate  

Unit  IntegraFon  

Test  

Deliver  to  ENV  

IntegraFon  is  just  pugng  units  of  code  together  and  tesFng  them  that  way.    ConFnuous  IntegraFon  is  doing  this  on  every  change.      Example:  3  team  members  code  new  components  and  unit  test  them.  They  pass.      Then  you  put  them  together  in  Dev  with  the  rest  of  the  system  and  something’s  broken  (Unit  IntegraFon  Test  fails).      

CI in Action

Code  

Unit  Test  

Build  

Integrate  

Unit  IntegraFon  

Test  

Deliver  to  ENV  

STOP!      

OK,  so  the  new  code  didn’t  work  with  the  rest  of  the  system.  Then  what?                                                  ROLLBACK.      Revert  your  exisFng  environment  to  the  previous  code  base  –  preferably  automaFcally  -­‐  and  go  fix  the  problem(s)  right  then  and  there.  Once  fixed,  THEN  you  can  try  again,  and  if  it  works  move  on  to  bigger  and  bener  builds.      

4/23/15  

7  

Why use CI? •  MarFn  Fowler,  in  his  September  2000  essay  on  CI  explained  that  integraFng  once  per  week  doesn’t  take  5x  as  long  as  once  per  day…  it  takes  25x  as  long.  

•  Why?  Risk  calculus:  •  Maciej  Zawatzki,  Director  of  the  Deploy  and  Release  Product  Line  at  IBM  Urban  Code  explains  in  his  video  

•  YouTube:  hnps://www.youtube.com/watch?v=f9NAZmtxYJg  

•  IBM:  hnps://developer.ibm.com/urbancode/videos/urbancode-­‐video-­‐blog-­‐1-­‐term-­‐devops/urbancode-­‐video-­‐blog-­‐4-­‐risk-­‐calculus-­‐release-­‐management/    

Automate Everything •  “Automate  the  build  process”  •  “Automate  the  tesFng”…  and  all  that  supports  it  •  Make  it  truly  automaFc.  Saved  a  client  75%  execuFon  Fme  doing  this  last  year.  

4/23/15  

8  

Code Change Demo

CD… and CD

•  ConFnuous  Delivery  (CD)  •  ConFnuous  Deployment  (CD)  •  Both  processes  •  Both  keystone  pieces  of  Release  AutomaFon  

DELIVERY  

DEPLOYMENT  Absolutely  required  for  successful  DevOps  projects!  

Not  for  everyone.  

4/23/15  

9  

Delivery vs. Deployment

Unit  Tests  Unit  

IntegraFon  Tests  

Deliver  to  <Your  Pre-­‐Prod  ENV>  

Acceptance  Tests  

Unit  Tests  Unit  

IntegraFon  Tests  

Delivery  to  <Your  Pre-­‐Prod  ENV>  

Acceptance  Tests  

Deploy  to  Prod  

Post-­‐Deploy  Tests  

DELIVERY  

DEPLOYMENT  

“Con6nuous  Delivery  doesn't  mean  every  change  is  deployed  to  produc;on  ASAP.  It  means  every  change  is  proven  to  be  deployable  at  any  6me.”              -­‐Carl  Caum  

Compile  Code   Run  Unit  Tests  Run  Unit  IntegraFon  

Tests  

Deliver  to  Pre-­‐Prod  

Environments  

Run  Acceptance  

Tests  Deploy  to  Prod  

Run  Acceptance  

Tests  

Run  AddiFonal  Post-­‐Deploy  

Tests  

Massive Speed = Massive ROI

4/23/15  

10  

Questions?

Thank You!

4/23/15  

11  

Risk Calculus

Complexity  =  the  number  of  relaFonships  between  features.      

(n2  –  n)  /  2  (n  =  number  of  features)  

 Going  back  to,  in  general,  1  out  of  3  items  being  defect  density,  this  tells  me  how  many  defects  to  expect  from  integra6on  itself.