Fighting Continuous Entropy

Fighting Continuous Entropy

What happens when you leave a codebase alone for a year? Would you expect it to still work? What about 5 years? 10 years?

If you've experienced you know the answer: it's a whole bunch of work to replatform the code to something more modern, more supported.

It doesn't have to be like this.

What if we used continuous integration and deployment techniques to ensure an easier future for ourselves and our future teams? Let's discuss a world in which we can write systems that, to a large degree, can look after themselves when we're not looking.

In this session, we'll explore code rot, continuous deployment, and the tools (automated and otherwise) you can use to keep your code alive for a bit longer.

1b5863cbb2d0009e78eaa85ea89fe2a6?s=128

garyfleming

April 04, 2019
Tweet

Transcript

  1. 1995

  2. 1995

  3. 1995

  4. 1995

  5. 1995

  6. !

  7. NOVEMBER FIFTEEN, NINETEEN NINETY-FIVE

  8. SIXTEEN => SOXTEEN

  9. SIXTEEN => SOXTEEN

  10. TWO THOUSAND SOXTEEN

  11. ▸ No source code (written in an older language) ▸

    Runs in a green screen terminal, ▸ Has to be emulated.
  12. FIGHTING CONTINUOUS ENTROPY ADVENTURES IN CONTINUOUS DELIVERY @GARYFLEMING

  13. WHAT IS ENTROPY? "a thermodynamic quantity representing the unavailability of

    a system's thermal energy for conversion into mechanical work, often interpreted as the degree of disorder or randomness in [a closed] system."
  14. WHAT IS ENTROPY? "Disorder of a closed system"

  15. SYSTEM EXPERIMENT: FISHES

  16. SYSTEM EXPERIMENT: FISHES AND TIME ▸ 10 minutes? ▸ 10

    hours? ▸ 10 days? ▸ 10000 years?
  17. ENTROPY IN SOFTWARE

  18. !

  19. MULTI-FACETED

  20. Problem KNOWING WHETHER YOUR SOFTWARE IS DEPLOYABLE

  21. BRIEF INTRO TO CI/CD

  22. CONTINUOUS INTEGRATION All developers/testers merge their code to a shared

    mainline at least once a day.
  23. CONTINUOUS INTEGRATION Related: ▸ Trunk-Based Development ▸ Feature Toggles

  24. IF IT HURTS, DO IT MORE OFTEN.

  25. CONTINUOUS DEPLOYMENT All changes go to production; safely, quickly, and

    sustainably.
  26. CONTINUOUS DEPLOYMENT Related: Blue-Green releases.

  27. None
  28. Problem DEPENDENCY UPDATES

  29. IF IT HURTS, DO IT MORE OFTEN.

  30. IDEA UPDATE DEPENDENCIES DAILY

  31. CONTINUOUS REGENERATION

  32. CONTINUOUS REJUVENATION

  33. EXPERIMENT: DEPENDENCY UPDATE DAILY ▸ Update ▸ Build and test

    ▸ Commit/Revert ▸ Commit causes CD to happen
  34. OUTCOME: DEPENDENCY UPDATE DAILY Mostly success! ▸ Some Major Version

    upgrades would need intervention, ▸ Temporary exclusions are important, ▸ Found unexpected end-to-end issues!
  35. DEPENDENCY UPDATES: OTHER LANGUAGES ▸ Single versioned: Maven, Gradle, packages.config

    e.g 5.4.1 3.0-ALPHA 1.3.2
  36. DEPENDENCY UPDATES: OTHER LANGUAGES ▸ Ranges and Lock files: gem/bundler,

    most JS frameworks. >=5.4.1 3.* [3.7.1)
  37. DEPENDENCY UPDATES: OTHER LANGUAGES ▸ Possibly open: pip, some JS

    frameworks, gem some-dep a-different-dep
  38. ALWAYS USE A LOCK FILE! Avoid "It works on my

    machine"
  39. RECENT DEVELOPMENTS ▸ Dependabot ▸ Atomist

  40. GOOD TESTS ARE ESSENTIAL!

  41. Problem RUNTIME ROT

  42. ROT WILL SET IN ▸ JVM ▸ .NET ▸ NPM

    version
  43. THE CONTINUOUS NOW

  44. INTERMEDIARY TOOLING ▸ Java -> Jabba ▸ Ruby -> RVM

    ▸ Node -> NVM ▸ Python -> Virtualenv (to some degree)
  45. Problem STANDING SERVERS

  46. Problem STANDING SERVERS

  47. AVOID SNOWFLAKE SERVERS ▸ Hard to Reproduce ▸ Hard to

    Modify ▸ Require manual processes, auditing, and docs.
  48. IF IT HURTS, DO IT MORE OFTEN.

  49. INFRASTRUCTURE AS CODE ▸ Chef/Puppet/Ansible ▸ Terraform ▸ Containerisation ▸

    Various cloud toolkits
  50. ENGINEERING PRACTICE ▸ Daily Deletion ▸ Chaos Engineering ▸ Dev

    Laptop Wipes
  51. CAUTION: TAKE THE UPDATES

  52. Problem LANGUISHING LANGUAGES

  53. Problem LANGUISHING LANGUAGES

  54. None
  55. AVOIDING OBSOLESCENCE ▸ Move to new versions, ▸ Cautiously embrace

    new languages, ▸ Design language agnostic APIs
  56. DESTROY YOUR MICROSERVICES

  57. Problem PEOPLE COME AND GO.

  58. Problem PEOPLE COME AND GO.

  59. IF IT HURTS, DO IT MORE OFTEN.

  60. People Prepping RETROS

  61. People Prepping DOMAIN KNOWLEDGE ▸ User Story Maps ▸ Example

    mapping
  62. People Prepping STAFF LIQUIDITY MATRICES

  63. None
  64. People Prepping BIGGER CHANGES

  65. EVERYTHING IS ROTTING...

  66. ...YOU CAN GET BETTER

  67. THANK YOU @GARYFLEMING #TALK-CONTINUOUSENTROP -> SELFCONF.SLACK.COM