CONTINUOUSDELIVERYWill	  Iverson,	  CTO	  Michael	  McIntosh,	  Dir.	  Business	  Development	  
Agenda•  Who	  are	  you?	  •  Who	  is	  Dynacron	  Group?	  •  What	  is	  Con>nuous	  Delivery?	      •  What	  pains	 ...
Who Are You?•  Technology	  Manager	     •  Technology	  Implementer	  
Who Are We?•  Dynacron	  Group	     •  Based	  in	  Kirkland,	  WA	     •  Founded	  in	  2010	     •  ~25	  Consultants,	...
What is Continuous Delivery?     •  Con>nuous	  Delivery	  (CD)	  is:	          •  a	  set	  of	  principles	  and	  prac>...
I want to                know about                continuous                Delivery                because…!TODAY’S GOALS
Pain & Opportunities•  Tell	  me	  what’s	  involved	  in	  doing	  a	  release?	      •  How	  long	  does	  it	  take?	 ...
Current State of Affairs
Current State Problem Summarized•  Key	  Pain	  Points:	     •  Painful	  releases	     •  Inability	  to	  predict	  deli...
Why?•  What	  are	  some	  of	  the	  causes	  of	  these	  pain	  points?	  
Target State•  Commitments between teams & functional areas are automated   & tracked in systems•  Teams use fast automati...
So… Why Not?•  New	  Tools	     •  Maven/MSBuild/etc,	  N/JUnit,	  Jenkins/Hudson/TeamCity/TFS,	  Selenium,	        SauceL...
Stuff To Learn                                Project                                               QA/SDET        Develop...
Project Manager’s View•  Agile	     •  Itera>ve,	  reduce	  risk…	  •  Unit/Func>onal/TDD	     •  If	  requirement	  exist...
Example: Automated Traceability•  Story	  wri@en	  &	  tracked	  in	  backlog	  tool	      •  e.g.	  Story	  #25431	  in	 ...
QA/SDET View•  Biggest	  shiY	  is	  moving	  from	  manual	  regression	  to	   automa>on	    •  New	  tools	  &	  skills...
Example: Selenium
Example: SauceLabs•  Instant QA Lab     •  50-200 machine build?     •  Video & screenshots for easy sharing•  Parallel Te...
Developer’s View•  Spend	  a	  LOT	  more	  >me	  wri>ng	  GOOD	  code	  •  Comfortable	  refactoring	     •  Know	  that	...
Example: Binary Repository                                                                   Continuous                 So...
IT/Ops View•  Releases	  are	  solid,	  every	  >me	  •  Releases	  are	  always	  in	  the	  same	  place	  •  Releases	 ...
Example: Simplified Releases                                     Centralized Virtual Environments /                       ...
NEXT STEPSHow	  do	  we	  get	  started?	  
Starting Points•  Plaoorm	  Moderniza>on	     •  Incremental	  Rolling	  Upgrade	     •  Take	  exis>ng	  applica>on[s],	 ...
Typical Engagement•  Assessment	     •  Gap	  analysis	  between	  current	  systems	  and	  target	  state	     •  Applic...
Partner Attributes•  Exis>ng	  people,	  process	  &	  tools	  •  Established	  architecture	  &	  infrastructure	  •  Exp...
Q&A
Upcoming SlideShare
Loading in …5
×

Continuous Delivery Overview

1,426 views

Published 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 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.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,426
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
30
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Continuous Delivery Overview

  1. 1. CONTINUOUSDELIVERYWill  Iverson,  CTO  Michael  McIntosh,  Dir.  Business  Development  
  2. 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. 3. Who Are You?•  Technology  Manager   •  Technology  Implementer  
  4. 4. Who Are We?•  Dynacron  Group   •  Based  in  Kirkland,  WA   •  Founded  in  2010   •  ~25  Consultants,  ~30  Total  Staff   •  www.DynacronGroup.com  
  5. 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. 6. I want to know about continuous Delivery because…!TODAY’S GOALS
  7. 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. 8. Current State of Affairs
  9. 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. 10. Why?•  What  are  some  of  the  causes  of  these  pain  points?  
  11. 11. Target State•  Commitments between teams & functional areas are automated & tracked in systems•  Teams use fast automation instead of slow manual processes
  12. 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. 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. 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. 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. 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. 17. Example: Selenium
  18. 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. 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. 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. 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. 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. 23. NEXT STEPSHow  do  we  get  started?  
  24. 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. 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. 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. 27. Q&A

×