Continuous Delivery Overview

Uploaded on

Continuous Delivery refers to the process of releasing high quality software quickly and with confidence through the use of build, test and deployment automation. By applying Lean techniques to the …

Continuous Delivery refers to the process of releasing high quality software quickly and with confidence through the use of build, test and deployment automation. By applying Lean techniques to the development, test and deployment of software, waste is reduced and staff are freed up to work on more important tasks. By following a continuous delivery model, release cycles shift from a matter of months to weeks or days.
In this presentation, we will look at the key tools and processes involved in transitioning from a manual culture to one that embraces automation. We will look at real world examples, including the tools and architectural components. We will discuss organizational impacts, including the dramatic improvements in morale as team delivery commitments are met more easily through automation.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. CONTINUOUSDELIVERYWill  Iverson,  CTO  Michael  McIntosh,  Dir.  Business  Development  
  • 2. Agenda•  Who  are  you?  •  Who  is  Dynacron  Group?  •  What  is  Con>nuous  Delivery?   •  What  pains  does  this  solve?  •  Why  It  Ma@ers  (By  Role)   •  Drill  down  on  a  few  topics/examples  •  Next  Steps  •  Q  &  A  
  • 3. Who Are You?•  Technology  Manager   •  Technology  Implementer  
  • 4. Who Are We?•  Dynacron  Group   •  Based  in  Kirkland,  WA   •  Founded  in  2010   •  ~25  Consultants,  ~30  Total  Staff   •  
  • 5. What is Continuous Delivery? •  Con>nuous  Delivery  (CD)  is:   •  a  set  of  principles  and  prac>ces  in  growing  use  in  soYware   development  to  improve  the  process  of  soYware  delivery.     •  Techniques  such  as  automated  tes>ng,  con>nuous   integra>on  and  automated  deployments  allow  soYware  to   be  developed  to  a  high  standard  and  easily  packaged  and   deployed  to  test  environments.   •  This  results  in  the  ability  to  rapidly,  reliably  and  repeatedly   push  out  enhancements  and  bug  fixes  to  customers  at  low   risk  and  with  minimal  manual  overhead.  * Wikipedia Definition
  • 6. I want to know about continuous Delivery because…!TODAY’S GOALS
  • 7. Pain & Opportunities•  Tell  me  what’s  involved  in  doing  a  release?   •  How  long  does  it  take?   •  How  many  steps  are  involved?   •  How  successful  is  the  process?   •  How  oYen  do  you  do  them?   •  Do  you  have  “heroes”?   •  What  would  happen  if  a  par>cular  environment  disappeared/melted   down?   •  Do  your  environments  match?   •  How  quickly  can  you  build  an  environment?   •  How  hard  is  it  to  do  a  patch?  A  major  release?  
  • 8. Current State of Affairs
  • 9. Current State Problem Summarized•  Key  Pain  Points:   •  Painful  releases   •  Inability  to  predict  delivery  affec>ng  business  commitments   •  Deployment  to  environments   •  Code  quality   •  Environment  configura>on  &  management   •  Expensive,  >me  consuming  manual  QA  (unable  to  build  lab)   •  Par>al  Agile  implementa>on  (Scrum  but  no  technical   processes)  
  • 10. Why?•  What  are  some  of  the  causes  of  these  pain  points?  
  • 11. Target State•  Commitments between teams & functional areas are automated & tracked in systems•  Teams use fast automation instead of slow manual processes
  • 12. So… Why Not?•  New  Tools   •  Maven/MSBuild/etc,  N/JUnit,  Jenkins/Hudson/TeamCity/TFS,  Selenium,   SauceLabs,  Puppet/MS  Config  Mgr…    •  New  Processes   •  Where  do  I  get  builds?  •  Organiza>onal  Impact   •  Cross-­‐func>onal  manager  buy-­‐in  •  New  Designs   •  Stateless  systems   •  Environments  from  tools,  not  manual  •  Iner>a   •  Comfort  
  • 13. Stuff To Learn Project QA/SDET Development IT/Ops/DevOps ManagementAgile (Scrum/Kanban/XP) u u u uUnit Testing  u u Functional/Web Testing  u /u Test-Driven Development  u u Continuous Integration  u u Binary Repository  u u uDistributed Version Control  u u(e.g. Git)Stateless Architecture  u uEnvironment (Cloud/    uVirtual)  = Understand Concepts u = Understand Technical Implementation
  • 14. Project Manager’s View•  Agile   •  Itera>ve,  reduce  risk…  •  Unit/Func>onal/TDD   •  If  requirement  exists  in  a  test,  you  won’t  have  to  worry   about  regressions   •  Full  regression  suite  run  in  minutes,  not  hours/days  •  Con>nuous  Integra>on   •  Solidifies  ongoing  work  meaning  of  “Done”  •  Binary  Repository   •  Radically  simplifies  release  meaning  of  “Done”  
  • 15. Example: Automated Traceability•  Story  wri@en  &  tracked  in  backlog  tool   •  e.g.  Story  #25431  in  Rally  •  Story  is  mapped  to  automated  tests   •  Tests  are  roughed  out  as  WIP  automated  tests,  checked  in  with  Story   #25431  •  Story  is  implemented  by  development   •  Code  checked  in  with  Story  #25431  •  Story  is  referenced  by  automa>cally  generated  release  notes  &   bundled  into  build   •  Build  #456  has  Story  #25431   •  Ready  for  release  –  just  send  an  email  “Promote  #456  to  shared  QA”  •  Everything  automated  &  traceable  
  • 16. QA/SDET View•  Biggest  shiY  is  moving  from  manual  regression  to   automa>on   •  New  tools  &  skills   •  Vastly  improved  produc>vity  •  Other  key  changes   •  Automa>ng  produc>on  of  builds  vastly  reduces  stress   •  Move  from  fire-­‐figh>ng    
  • 17. Example: Selenium
  • 18. Example: SauceLabs•  Instant QA Lab •  50-200 machine build? •  Video & screenshots for easy sharing•  Parallel Test Execution •  e.g. 200 tests x 5 browsers = 1000 tests •  Run 50 parallel threads = complete in 15 minutes
  • 19. Developer’s View•  Spend  a  LOT  more  >me  wri>ng  GOOD  code  •  Comfortable  refactoring   •  Know  that  your  refactoring  is  not  breaking  things   •  Know  that  you  can  fix  technical  debt  •  Never  hear  “works  on  my  machine”  again  •  Never  have  to  sit  wai>ng  for  a  build/release/manual   test  pass  •  Clear,  established  standards  for  defini>on  of  done  
  • 20. Example: Binary Repository Continuous Source Integration Control Server Source All work tracked, The image cannot be displayed. Your computer versioned may not have enough memory to open the image, or the image may have been corrupted. Restart your computer, and then open the file again. If the red x still appears, you may have to delete the Reference Build & Test QA image and then insert it again. Server Source Runs tests before Binary committing Compiled Repository Code Applications Stage to source control. Stores all Developers release artifacts Prod LibrariesAll builds reproducible.Code matches release. Vastly reduces wait time.Enforces a standard build, test & release environment.Broken builds notify developer immediately without breaking build. Standardizes work product.
  • 21. IT/Ops View•  Releases  are  solid,  every  >me  •  Releases  are  always  in  the  same  place  •  Releases  have  excellent  documenta>on   •  Most  of  which  is  machine  generated,  so  it’s  always  current  &   up  to  date  •  Configura>on  systems  instead  of  tribal  knowledge   means  you  can  actually  go  on  vaca>on  •  Solid,  stateless  releases  can  go  out  during  normal   business  hours,  so  you  can  enjoy  evenings  &   weekends  
  • 22. Example: Simplified Releases Centralized Virtual Environments / Private Cloud BinaryRepository Applications Applications ApplicationsStores all QA Stage Prodreleaseartifacts Versioned Versioned Versioned Configuration Configuration Configuration Configuration Management System
  • 23. NEXT STEPSHow  do  we  get  started?  
  • 24. Starting Points•  Plaoorm  Moderniza>on   •  Incremental  Rolling  Upgrade   •  Take  exis>ng  applica>on[s],  upgrade  to  new  plaoorm   •  Pro:  No  requirements  churn   •  Goes  much  faster  than  you  would  expect   •  Con:  S>ll  need  to  >e  into  business  ini>a>ve  (new  L&F?)  •  New  Applica>on[s]   •  Pro:  Build  new  func>onality  with  a  clean  start   •  Con:  S>ll  have  legacy  environment  to  maintain  
  • 25. Typical Engagement•  Assessment   •  Gap  analysis  between  current  systems  and  target  state   •  Applica>on  Inventory   •  Tool  recommenda>ons  •  Training   •  Group  learning   •  Execu>ve  &  Management  Baselines  Established  •  Execu>on   •  Combine  with  business-­‐value  project  for  paired  implementa>on   •  Typically  a  replaoorming  or  new  project   •  Best  bang  for  buck:  Clean  up  old  systems  &  code  first   •  Convert  exis>ng  manual  tests  to  automa>on,  modernized  build/release,   convert  to  stateless  
  • 26. Partner Attributes•  Exis>ng  people,  process  &  tools  •  Established  architecture  &  infrastructure  •  Experience  with  hands  on  implementa>on  •  Training  &  pairing  for  long  term  rela>onship   •  Local,  hybrid  team  engagements  •  Reference  accounts  
  • 27. Q&A