Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Continuous Delivery for people who do not write code - Matthew Skelton - Conflux

811 views

Published on

Continuous Delivery is a proven set of practices for reliable software releases through build, test, and deployment automation. Organisations around the world have adopted Continuous Delivery (CD) to increase speed and safety of software changes whilst reducing errors and problems in Production.

This talk is an overview of Continuous Delivery for people who do not write code. If you are a delivery manager, project manager, release manager, operations person, business analyst, or anyone else involved in the building, testing, releasing, and running of software systems, this talk will give you an understanding of what Continuous Delivery is about and how it feels to be part of a CD organisation.

(From a talk given in Leeds, UK on 24 Sept 2018)

Published in: Software
  • This whitepaper explains how we built a continuous testing framework for one of our high value enterprise clients and the challenges we faced along with the solutions we created to overcome those challenges. http://bit.ly/2FTSWT2
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Continuous Delivery for people who do not write code - Matthew Skelton - Conflux

  1. 1. Continuous Delivery for people who do not write code Matthew Skelton, Head of Consulting, Conflux confluxdigital.net / @ConfluxHQ Leeds, 24 Sept 2018
  2. 2. 2
  3. 3. Continuously Delivering CD since 2012 Matthew Skelton, Conflux @matthewpskelton matthewskelton.net Leeds, UK 3 2012 2014 2015 2016
  4. 4. Continuous Delivery Learning Zones 4 learn.londoncd.org.uk learn.pipelineconf.info Over 150 talks on Continuous Delivery from practitioners around the world
  5. 5. What is Continuous Delivery? 5
  6. 6. 6
  7. 7. 7
  8. 8. Continuous Delivery “Reliable Software Releases Through Build, Test, and Deployment Automation” A specific set of practices and disciplines, tried and tested in many different sectors & contexts worldwide since 2010.
  9. 9. Continuous Delivery for all Applies to all kinds of software: ● Mobile ● Embedded ● Web ● ... From Continuous Delivery with Windows & .NET, O’Reilly, 2016, cdwithwindows.net
  10. 10. Why Continuous Delivery? 10
  11. 11. 11 speed safety
  12. 12. We need Speed and Safety Modern software systems are too complicated for manual inspection and assessment We need automated checks for almost every aspect of the software system Use pervasive tooling to detect problems early
  13. 13. 13 High risk Low risk
  14. 14. Small changes are less risky Large batches of changes are almost guaranteed to have errors or problems Small batches are easier to reason about, easier to diagnose, easier to change 14
  15. 15. Agile → Continuous Delivery 15 Jez Humble, continuousdelivery.com
  16. 16. Agile → Continuous Delivery Automated testing of all aspects of a feature or story as soon as it has been written: ● Behaviour ● Operational ● Security ● ... The ability to release a feature or story as soon as it is ready. 16
  17. 17. CD practices for all areas 17
  18. 18. CD practices for all areas Business/Workstream applications & services Core supporting products Auxiliary tooling: build & deployment, monitoring Infrastructure (Kubernetes, environments, etc.) 18
  19. 19. cdchecklist.info 19
  20. 20. CD Key Principles Rapid feedback on every change Code is always releasable: no big manual testing Deployment Pipeline is the only “route to live” Decoupled, independently releasable units Cross-functional team empowered to deploy live 20
  21. 21. Real example - 2013 Use visibility to increase trust → speed & safety 21
  22. 22. Short, wide pipelines ❌ ✅ Shortest (responsible) path to live Long wait for complicated testing https://continuousdelivery.com/2010/09/deployment-pipeline-anti-patterns/ 22
  23. 23. Testing in Continuous Delivery 95% of testing is automated Operational features tested automatically Most testers sit within Service/Product teams Some testers act as SMEs for test approach Exploratory Testing - specific, manual discipline 23
  24. 24. Deployment in CD Deployment steps fully automated Deploy during the day - with people around Tracked using an orchestration tool (pipeline) Rollbacks (if possible) or rapid roll-forward 24
  25. 25. Metrics and logging in CD Service/Product teams see live metrics and logs “Feel the hum” of running systems Metrics and logging for: Services/Products Build / Deployment / Test infrastructure 25
  26. 26. What does Continuous Delivery feel like? 26
  27. 27. 27 High-fidelity information
  28. 28. High-fidelity information Near real-time feedback on changes Instant visibility of the flow of change Rapid drill-down for diagnostics Rapid requirements trace-back for changes 28
  29. 29. 29 No waiting for a release train
  30. 30. No waiting for a release train Independent routes to Production Each worksteam moves at its own speed Interdependencies handled by disciplined engineering practices (including versioning, backwards-compatibility, testing techniques) 30
  31. 31. 31 Heavy lifting done by tooling
  32. 32. Heavy lifting done by tooling No need for manual inspection of change quality No manual progressing of change sets No ‘worrying’ whether software will work More time to focus on more valuable things 32
  33. 33. 33 Reliable releases
  34. 34. Reliable releases Reliable tests Reliable deployments Reliable rollbacks Reliable monitoring, logging, metrics 34
  35. 35. How do activities change with Continuous Delivery? 35
  36. 36. Agile → Continuous Delivery 36 Jez Humble, continuousdelivery.com
  37. 37. 37 Early & continuous expertise
  38. 38. Early & continuous expertise Bring expertise from Release Management / Change Management / Testing / Operations into software dev teams on an ongoing, daily basis The ‘wise Yoda’ for the ‘young Jedi’ teams Enable flow of change 38
  39. 39. 39 Assess progress regularly
  40. 40. Assess progress regularly Automated code checks across multiple dimensions Regular checks of engineering practices Track delivery metrics: Cycle Time, Deployment Frequency, mean time to restore service (MTTR) 40
  41. 41. How do we get to Continuous Delivery? 41
  42. 42. 42 Many parallel routes to live
  43. 43. Many parallel routes to live Each family of applications and services has its own route to live Rigorous testing with stubs, fakes, proxies Rapid detection of problems and rapid restore of previous good version 43
  44. 44. 44 Continuous operability
  45. 45. Continuous operability Work on operational features ~30% of effort every week, every month Operational aspects tested using automated tests in a deployment pipeline Availability is the #1 feature 45
  46. 46. Continual small steps 46
  47. 47. Continual small steps 47
  48. 48. Continual small steps There is no sudden “switch to CD” Incremental improvements over many months Track using metrics, especially cycle time 48
  49. 49. Summary: Continuous Delivery 49
  50. 50. Continuous Delivery Small, focused changes with rapid feedback High-fidelity information on changes via tools Early and continuous expertise from Testing, Release Mgt, Change Mgt, Operations Focus on operability to reduce the unexpected 50
  51. 51. Further reading 51 Continuous Delivery checklist http://cdchecklist.info/ Continuous Delivery with Windows & .NET http://cdwithwindows.net/ Continuous Delivery Learning Zones https://learn.pipelineconf.info/ https://learn.londoncd.org.uk/
  52. 52. thank you @ConfluxHQ confluxdigital.net

×