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.

Surviving SOA - delivering (somewhat) continuously on a hostile planet

1,990 views

Published on

Slides from 11-Feb-2015 presentation at the London Continous Delivery Meetup

Published in: Software
  • Be the first to comment

Surviving SOA - delivering (somewhat) continuously on a hostile planet

  1. 1. ! Surviving SOA Delivering (somewhat) continuously on a hostile planet! ! @TomAkehurst
  2. 2. You can’t always get what you want…!
  3. 3. The Org Large, horizontally sliced programme
  4. 4. The Org Large, horizontally sliced programme ! Fixed-price contracts (inflexibility)
  5. 5. The Org Large, horizontally sliced programme ! Fixed-price contracts (inflexibility) ! DevOps and testers in separate teams
  6. 6. The Org Large, horizontally sliced programme ! Fixed-price contracts (inflexibility) ! DevOps and testers in separate teams ! Theory X (leading to endemic risk/change aversion)
  7. 7. The Process “Agile” but….
  8. 8. The Process “Agile” but…. ! Lack of feedback and improvement mechanisms
  9. 9. The Process “Agile” but…. ! Lack of feedback and improvement mechanisms ! Enabling technical practices neglected
  10. 10. The Process “Agile” but…. ! Lack of feedback and improvement mechanisms ! Enabling technical practices neglected ! Very infrequent live releases, tons of WIP
  11. 11. The Process “Agile” but…. ! Lack of feedback and improvement mechanisms ! Enabling technical practices neglected ! Very infrequent live releases, tons of WIP ! Long cycle times, but nobody seemed to notice
  12. 12. The Technology Big vendor SOA + BPM ! Old skool J2EE containers ! !
  13. 13. The Technology Big vendor SOA + BPM ! Old skool J2EE containers ! SOAP !
  14. 14. The Technology Big vendor SOA + BPM ! Old skool J2EE containers ! SOAP ! Shoddy inherited codebase ! !
  15. 15. Database
  16. 16. Database ETL
  17. 17. Database The SOAP Layer ETL
  18. 18. Database The SOAP Layer The MoreSOAP Layer ETL
  19. 19. Database The SOAP Layer The MoreSOAP Layer ETL
  20. 20. Database The SOAP Layer The MoreSOAP Layer ETL Our thing
  21. 21. The Pipeline No pre-test integration environments ! Very locked-down test environments ! ! ! !
  22. 22. The Pipeline No pre-test integration environments ! Very locked-down test environments ! Separate test team per test environment - ReleaseTesting3 ! ! !
  23. 23. The Pipeline No pre-test integration environments ! Very locked-down test environments ! Separate test team per test environment - ReleaseTesting3 ! Test automation team building vast Selenium suite !
  24. 24. ENERGIZED WORK / Metal Box Factory Unit 323 30 Great Guildford Street London SE1 0HS / www.energizedwork.com ! !! Survival! !
  25. 25. What does (as) good (as we can manage) look like?
  26. 26. What does (as) good (as we can manage) look like? Keep our own cycle time down, but don’t locally optimise
  27. 27. What does (as) good (as we can manage) look like? Keep our own cycle time down, but don’t locally optimise ! Minimise the risks we can control, manage those we can’t
  28. 28. What does (as) good (as we can manage) look like? Keep our own cycle time down, but don’t locally optimise ! Minimise the risks we can control, manage those we can’t ! Don’t compromise on quality (even if others are)
  29. 29. The Basics TDD + ATDD ! Trunk-based development ! Build discipline ! Small batches (commits, pushes, releases)
  30. 30. Service Mocking
  31. 31. Service Mocking Fast functional tests
  32. 32. Service Mocking Fast functional tests ! Parallel development with service teams
  33. 33. Service Mocking Fast functional tests ! Parallel development with service teams ! Reduce need for a dev/int environment
  34. 34. Service Mocking Fast functional tests ! Parallel development with service teams ! Reduce need for a dev/int environment ! Fault injection
  35. 35. Sham data
  36. 36. Sham data High fidelity demos ! Serendipitous bug discovery + better exploratory testing
  37. 37. Sham data High fidelity demos ! Serendipitous bug discovery + better exploratory testing ! Generative-style tests
  38. 38. App JVM App Hermetic Testing Test JVM WireMock SpockSham Geb/Selenium phantomjs Generate SOAP stubs SOAP Templates
  39. 39. SOAP minus WSDL
  40. 40. SOAP minus WSDL groovy-ws-lite - XML builders for SOAP messages, not generated source
  41. 41. SOAP minus WSDL groovy-ws-lite - XML builders for SOAP messages, not generated source ! Tolerant reader
  42. 42. SOAP minus WSDL groovy-ws-lite - XML builders for SOAP messages, not generated source ! Tolerant reader ! Reduced need for synchronised releases
  43. 43. SOAP minus WSDL groovy-ws-lite - XML builders for SOAP messages, not generated source ! Tolerant reader ! Reduced need for synchronised releases ! Use WSDL for unit tests (with off switch)
  44. 44. Telemetry
  45. 45. Telemetry SOAP request/response history
  46. 46. Telemetry SOAP request/response history ! Metrics
  47. 47. Telemetry SOAP request/response history ! Metrics ! Service check
  48. 48. Telemetry SOAP request/response history ! Metrics ! Service check ! Scenario (integration) tests
  49. 49. Exploratory Testing as Peer Review Sneaky tunnel to the test environment ! Guided by common gotchas list ! Reduce pressure on bottleneck - the testers
  50. 50. Hermetic Demo Environment Laptop install via USB key ! Sham data for realism ! Early feedback
  51. 51. Did it work? We didn’t work weekends (everyone else did)
  52. 52. Did it work? We didn’t work weekends (everyone else did) ! Able to react quickly to late, complex changes
  53. 53. Did it work? We didn’t work weekends (everyone else did) ! Able to react quickly to late, complex changes ! Defect rate so low that business sponsors thought there was a reporting problem
  54. 54. Did it work? Integration bugs due to bad assumptions about semantics persisted ! ! !
  55. 55. Did it work? Integration bugs due to bad assumptions about semantics persisted ! Manual testing remained a bottleneck
  56. 56. Did it work? Integration bugs due to bad assumptions about semantics persisted ! Manual testing remained a bottleneck ! Failed to significantly influence practices outside our team
  57. 57. ENERGIZED WORK / Metal Box Factory Unit 323 30 Great Guildford Street London SE1 0HS / www.energizedwork.com ! !! Next time we’ll…! !
  58. 58. …shun container security Tight coupling ! Frequent nasty surprises on deployment to test environments ! Hard to mock effectively for testing
  59. 59. …keep the build time down Heavy-heavy-heavyweight framework (Grails) ! Selenium overuse ! Build breakage frequency increased with duration ! Temptation to skimp on new test cases ! Adding concurrency afterwards is hard
  60. 60. …choose a better optimised tech stack Wire protocol supporting loose coupling and evolution ! Small framework - fast startup, small footprint under no load ! Embedded container - fast, simple deployments, no compatibility hassles ! Minimise need for browser-driven tests
  61. 61. If you only take away one thing Don’t settle for the lowest common denominator - CD can be practiced in hostile environments, and it’s worth it!
  62. 62. ENERGIZED WORK / Metal Box Factory Unit 323 30 Great Guildford Street London SE1 0HS / www.energizedwork.com ! !! Ta!! ! ! ! @TomAkehurst! https://github.com/tomakehurst

×