Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Beyond TDD - Enabling Your Team to Continuously Deliver Software

neraath
November 14, 2012

Beyond TDD - Enabling Your Team to Continuously Deliver Software

Many project teams have adopted unit testing as a necessary step in their development process. Many more use a test-first approach to keep their code lean. Yet, far too often these teams still suffer from many of the same impediments: recurrent integration failures with other enterprise projects, slow feedback with the customer, and sluggish release cycles. With a languishing feedback loop, the enterprise continues to put increasing pressure on development teams to deliver. How does an aspiring agile team improve to meet the demands of the enterprise?

Continuous integration is the next logical step for the team. In this talk, you’ll learn how continuous integration solves intra and inter-project integration issues without manual overhead, the value added by continuous integration, and how to leverage tools and processes to further improve the quality of your code. Finally, we discuss the gold standard of agile teams: continuous deployment. You’ll learn how continuous deployment helps close the feedback loop with your customers, increases visibility for your team, and standardizes the deployment process.

neraath

November 14, 2012
Tweet

More Decks by neraath

Other Decks in Technology

Transcript

  1. Me • Fightin’ Texas Aggie • C# and PHP Developer

    • Agilist since 2007 • Senior Consultant at Improving Enterprises • [email protected] Wednesday, November 14, 12
  2. Twitter Promotion • @neraath • #AgileATX2012 • #beyondtdd • #thisguyisawesome

    • #awesomesauce • #terrbilepresenter Wednesday, November 14, 12
  3. Twitter Promotion • @neraath • #AgileATX2012 • #beyondtdd • #thisguyisawesome

    • #awesomesauce • #terrbilepresenter • #worstpresentation Wednesday, November 14, 12
  4. Agile, Microsoft, Open Technologies, UX Applied Training, Coaching, Mentoring Certified

    Consulting Rural Sourcing Recruiting Services Wednesday, November 14, 12
  5. Overview • No code or demonstrations • TDD in your

    current environment • Continuous Integration • Continuous Delivery • Is it worth it? • Your next steps Wednesday, November 14, 12
  6. using System; namespace BeyondTDD { public class StringUtils { ///

    <summary> /// Strips double quotes from the provided <paramref name="sourceString" />. /// </summary> /// <param name="sourceString">The source to strip quotes from.</param> /// <returns>A string without quotes.</returns> public string StripQuotes(string sourceString) { if (string.IsNullOrEmpty(sourceString)) throw new ArgumentNullException("sourceString"); return sourceString.Replace('\"', string.Empty); } } } Wednesday, November 14, 12
  7. using System; namespace BeyondTDD { public class StringUtils { ///

    <summary> /// Strips double quotes from the provided <paramref name="sourceString" />. /// </summary> public string StripQuotes(string sourceString) { if (sourceString == null) { throw new ArgumentNullException("sourceString"); } return sourceString.Replace('\"', ""); } // Look at all the spaces, ma! } } Wednesday, November 14, 12
  8. using System; namespace BeyondTDD { public class StringUtils { /***

    I had to change this method cause I'm a n00b. public string StripQuotes(string sourceString) { foreach(char c in sourceString) { if (c == '\"') { sourceString[c] == ""; } } return sourceString; } */ // comments? what comments? this makes sense, right? public string StripQuotes(string sourceString) { if (sourceString == null) { //throw new ArgumentNullException("sourceString"); // I <3 Exception more than anything else. throw new Exception("sourceString"); } return sourceString.Replace('\"', ""); } } } Wednesday, November 14, 12
  9. I will hunt you down and shoot you like a

    duck dog. Wednesday, November 14, 12
  10. CI is a Practice • Integrate now, and frequently, rather

    than at the end of development • Smaller surface area for integration problems • Devs can rapidly fix when they occur • Reduces “Integration Hell” Wednesday, November 14, 12
  11. What do you need? • Automate your build • Manual

    steps increases risk of failure • Make your build self-testing • Writing unit tests is not enough • Must be able to execute tests with a single command Wednesday, November 14, 12
  12. Source Control Build Server Accessible by Entire Team Your Shell

    Scripts Commit to trunk / master / mainline often What do you need? Wednesday, November 14, 12
  13. • Every commit (to the trunk) should be built •

    Keep the build fast • Notify (and make visible to) the entire team • Intrusively notify the team of failures • Make sure to fix the build after it’s broken “Fail Fast” Wednesday, November 14, 12
  14. Other CI Considerations • Repeatable & reliable • Should be

    able to run the same build process locally • Break up large testing suites • Remember, “Fail Fast” Wednesday, November 14, 12
  15. Continuous Delivery is developing in such a way that software

    is always ready for release. Wednesday, November 14, 12
  16. More on Being Agile “Our highest priority is to satisfy

    the customer through early and continuous delivery of valuable software.” Wednesday, November 14, 12
  17. More on Being Agile “Our highest priority is to satisfy

    the customer through early and continuous delivery of valuable software.” Wednesday, November 14, 12
  18. Users Drive Your Value Much like beauty, value is in

    the eyes of the beholder. Wednesday, November 14, 12
  19. The “Last Mile” Problem “The further apart your releases are,

    the more risk you introduce that the changes are wrong.” - Jez Humble Wednesday, November 14, 12
  20. Why? • We want constant feedback • How else do

    we know what we’re doing is valuable? • Constant testing and improving our delivery process Wednesday, November 14, 12
  21. Incomplete Features • Sometimes a feature is just too big

    • Incomplete features across releases Wednesday, November 14, 12
  22. Incomplete Features • Sometimes a feature is just too big

    • Incomplete features across releases • Ship it anyways! Wednesday, November 14, 12
  23. Incomplete Features • Sometimes a feature is just too big

    • Incomplete features across releases • Ship it anyways! • Beware the Beta Wednesday, November 14, 12
  24. Incomplete Features • Sometimes a feature is just too big

    • Incomplete features across releases • Ship it anyways! • Beware the Beta • Solution: Feature Toggles Wednesday, November 14, 12
  25. Everyone’s Responsibilities • How do I automate the testing and

    validation after deploying? • How do I make it easier for the team to release? Wednesday, November 14, 12
  26. Developer Responsibilities • How do I keep my software releasable?

    • What does it take to deploy my software? Wednesday, November 14, 12
  27. DBA Responsibilities • How do I automate schema deployments? •

    How do I give the build server autonomy to deploy? Wednesday, November 14, 12
  28. Ops Responsibilities • How do I want the software to

    be deployed? • How do I give the build server autonomy to deploy? Wednesday, November 14, 12
  29. Tester Responsibilities • Did the automated deployment succeed? • This

    is not the same as testing software. Wednesday, November 14, 12
  30. Deployment for SaaS • FTP/SCP • PowerShell • Shell Scripting

    • MSBuild • MSI/Installer Packages Wednesday, November 14, 12
  31. Deployment for Products • Windows Installers • Built-in, InstallShield, Wise,

    VISE, etc. • Installer (Mac OS) Wednesday, November 14, 12
  32. Deployment Quality • Important to establish trust • End-to-end functional

    tests become more valuable • Behavior-Driven Development helps to realize this • Other quality metrics become just as useful • Performance, compatibility, security Wednesday, November 14, 12
  33. When It Goes Wrong • Turn off the feature or

    rollback • Don’t “hack” a fix Wednesday, November 14, 12
  34. Risk • By removing barriers, rehearsing, and continuously improving the

    release process, the risk of a release is reduced • Becomes a regular occurrence rather than a traumatic procedure Wednesday, November 14, 12
  35. Risk • Feedback determines the viability of your feature •

    Increases confidence when it’s right • Decreases cost when it’s wrong Wednesday, November 14, 12
  36. Moving Forward • Identify a single task • Something that

    is particularly time consuming and/ or painful • Automate the task • Start collecting metrics • Build team confidence Wednesday, November 14, 12
  37. Moving Forward • You need to talk to the business

    • Ask these questions: • Would you like to set the release schedule? • Would you like to minimize risk during deployments? • Would you like to maximize investment on features our customers really want? • Be sure to alert them of the up-front investment required! Wednesday, November 14, 12
  38. Moving Forward • Need help? • After the talk •

    Ask me about Lunch ‘n Learns or Assessments! Wednesday, November 14, 12