Automation and Technical Debt


Published on

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Collected technical work left undone.When a feature changes, there’s immediate debt to documentation. When we branch, as we work longer in parallel, we accumulate a debt towards integrating. CI minimizes the accumulation of that debt.
  • My apologies to Mr. Rumsfeld.
  • Automation and Technical Debt

    1. 1. How Automation Reveal Technical Debt1
    2. 2. Eric’s Bio I’m a Lead Consultant at Urbancode where I helps customers get the most out of their build, deploy and release processes. I have 9 years of automation experience throughoutEric Minick the application life-cycle in roles a developer, test automation engineer, and support engineer. I’ve been at the forefront of CI & CD for 7+ years 2
    3. 3. Technical Debt3
    4. 4. Why do we accumulate technical debt?• We leverage technical debt to deliver more faster. Scope Time• De-leveraging is rarely accounted for in project planning. Resources• Green-Shifting*4 *
    5. 5. Why should we care?Baggage that slows the team Quality issues• Lack of automated tests • Lack of tests results in lengthen QA cycles buggier code• Fear of merging work • Releases are error prone and lead to unnecessary• Unrefactored code slow to work with outages• Slow build / deploy processes delay learning and release pace5
    6. 6. The limits of what we know• Known Knowns: Bugs confirmed and tracked• Known Unknowns: Undiscovered bugs• Unknown unknowns: One of our project teams is using a GPL’d library making their product impossible to ship6
    7. 7. Where Automation Helps• “Testing” for debt: Automated tests, code scans and reports can help identify (and quantify) problems.• Automation as a learning experience: The act of automating brings surprises.7
    8. 8. Testing for Debt• Continuous Integration (multi-component)• Code Inspection• Watching Trends8
    9. 9. Testing for Debt: Continuous Integration• On code commit, build and test the software• Roll up changes to build-time or runtime dependencies and test those too to identify API incompatibilities9
    10. 10. Testing for Debt: Code Inspection Code Reviews – Rapidly detect issues Static Code Analysis – Tool based checks for bugs, code duplication, code theft, & non- compliance with dev standards.10
    11. 11. Testing for Debt: Code Inspection Code Reviews – Rapidly detect issues Static Code Analysis – Tool based checks for bugs, code duplication, code theft, & non- compliance with dev standards.11
    12. 12. Testing for Debt: Watching Trends12
    13. 13. More visualizations: Sonar13
    14. 14. An example safety net• Continuous build & unit test• Nightly slow tests / code scans• Emails identifying new issues – ideally tied against source code changes• Regular inspection of trends• Bugs / Stories entered around issues14
    15. 15. Automation as a learning experience Implementing the safety net helps us discover unacknowledged debt15
    16. 16. Tests? What tests?16
    17. 17. Automation Examples: The Build• Build time dependencies not understood• Build scripts missing or incomplete• “Magic build server” anti-pattern17 sitories_in_Software_Configuration_Management.html
    18. 18. Automation Examples: Deployment• Deployment scripts scarce• “Special Instructions” with most deployments indicate non-repeatable process• Environmental differences handled poorly• Separation of duties less than real18
    19. 19. Automation Example: Test Automation• Requirements less well understood• Existing tests are few, stale, un-optimized• Application not architected for testability19
    20. 20. Expect the unexpected when automating• At scale, Green-Shifting, has hidden issues• Include these discoveries in ROI estimations for automation (positively and negatively)• This is a happy side effect20
    21. 21. Direct and Indirect Automation Benefits• Direct: We tested for problems and found them.• Indirect: In attempting to be more efficient, we automated, and accidently discovered problems.21
    22. 22. Automating for the team• Provide a “safety net” to detect and recognize issues.• Diagnose and repair lack of repeatability in build-deploy-test• Quantify accumulating debt in support of fighting scope creep• Team level tooling is fine22
    23. 23. Automating the Enterprise• Benefits extend beyond aggregate team level benefits• Central Automation and Reporting gets us: – Identify who can use shared configuration – Who has tests, who doesn’t – Who is using what tools – Build / deploy failure rates23
    24. 24. Favorite Examples: Deployment Failures• Problem: High rate of deployment failures a problem• Goal: Reduce failure rate from 40% to 5%• Approach: Avoid manually fixing a deployment. Fix the automation and redeploy.• Enforcement: Monthly / weekly spreadsheet of success to CIO with a six month plan.24
    25. 25. Favorite Examples: “End of Day” Commits• Problem: Developers commit breaking changes at the end of the day• Goal: Avoid other devs staying late to clean up• Approach: Report on failures, and react to negative patterns as a team.25
    26. 26. 26
    27. 27. Favorite Examples: Low numbers of tests• Problem: Unit testing discipline breaking down over time• Goal: Maintain high or improving coverage• Approach: Standard coverage tools and an emphasis on upward trends.• Enforcement: Trending report on monitor over CIO’s door27
    28. 28. Summary• We accumulate technical debt as we race to deliver more, faster.• This causes us to eventually release less, slower, with worse quality• Automation directly and indirectly helps us find issues.• There are benefits at both team and enterprise levels.28
    29. 29. More References• Enterprise CD Maturity Model• Lean Build & Deployment Automation• Managing Release Risks with
    30. 30. Yes, we sell products for this• AnthillPro – Build automation and build promotion• uDeploy – Deployment and release management30
    31. 31. Questions? @EricMinick