Testing and DevOps Culture: Lessons Learned

2,754 views

Published on

0 Comments
6 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,754
On SlideShare
0
From Embeds
0
Number of Embeds
26
Actions
Shares
0
Downloads
67
Comments
0
Likes
6
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Testing and DevOps Culture: Lessons Learned

    1. 1. Testing and DevOps Culture
    2. 2. LB Denker
    3. 3. Cynical Things I’ve Learned“The two virtues of a good developer arelaziness and hubris”“You can’t tell a developer to do anything”
    4. 4. Things I’ve LearnedNearly every “Best Practice” was developedto address a particular situation.Identify interdependent relationships andrespect them.The code is not everything.
    5. 5. My PastRochester Institute of TechnologyUniversal Instruments CorporationGoogle, Inc.Etsy, Inc.
    6. 6. RIT Computing MajorsInformation TechnologyNew MediaComputer ScienceSoftware EngineeringComputer EngineeringComputational Mathematics
    7. 7. RITComputational Mathematics, BSComputer Science, MSTeaching Assistant in MathematicsTeaching Assistant in Computer Science
    8. 8. Software Engineering I @RIT Team of Four to Five (4-5) Team Coordinator Development Coordinator Requirements Coordinator Test Coordinator* Configuration/QA Coordinator
    9. 9. Software Engineering I @RIT Team of Four to Five (4-5) Team Coordinator Product Manager Development Coordinator Technical Lead Requirements Coordinator Project Manager Test Coordinator* Configuration/QA Coordinator Sys Admin
    10. 10. Software Engineering I @RIT Team of Four to Five (4-5) Team Coordinator Product Manager Development Coordinator Technical Lead Requirements Coordinator Project Manager Test Coordinator* Release Eng Configuration/QA Coordinator
    11. 11. Software Engineering I @RIT Team of Four to Five (4-5) Team Coordinator Product Manager Development Coordinator Technical Lead Requirements Coordinator Project Manager Test Coordinator* Configuration/QA Coordinator QA
    12. 12. Software Engineering I @RIT Team of Four to Five (4-5) Team Coordinator Product Manager Development Coordinator Technical Lead Requirements Coordinator Project Manager Test Coordinator* Configuration/QA Coordinator Operations
    13. 13. Universal Instruments Corporation I’m a real Software Engineer!
    14. 14. Universal Instruments CorporationSurface MountMachinesOptimizerLine Balancer
    15. 15. Universal Instruments CorporationSoftware Engineers Machine Level (C and Assembly) Software (MFC C++ or C#) Red, Blue, and Purple
    16. 16. Universal Instruments CorporationSoftware EngineersSystem AdministratorsQA AnalystsSCM Team
    17. 17. SilosSoftware Engineers ... wrote code ... completed ClearQuest tickets ... waited for QA to test nightly builds ... revisited code when QA opened a ticket ... played Counter-Strike at lunch
    18. 18. SilosSystem Administrators ... maintained the nightly build servers ... kicked the nightly build in the morning when it failed during the night ... maintained staff workstations ... provide lots of reasons why not
    19. 19. SilosQA Analysts ... waited for nightly builds ... verified completed tickets ... manually tested ... sometimes used WinRunner ... opened tickets for bugs
    20. 20. SilosSCM Team ... decided stream layout in ClearCase ... dictated whether: <major>.<minor>.<maintenance>.<patch> ... burned CDs ... pre-loaded machines
    21. 21. DevOps
    22. 22. Why DevOps?Embrace the interdependence betweenDevelopers and other IT ProfessionalsContinuous Deployment
    23. 23. Continuous Deployment Pro Safety Net Implementation Difficulties Ops giving more access to Developers Lack of confidence Limitation Deploy Medium
    24. 24. One Button Deploy
    25. 25. Mostly AutomatedOne Button Deploy
    26. 26. Continuous What?!?Continuous... Unceremoniously... Initiated By... Push toDeployment Anyone Production Apply QualityIntegration Anyone Process Release a New Delivery ??? Feature
    27. 27. Continuous Delivery
    28. 28. Continuous Deployment+ Continuous Integration Continuous Delivery
    29. 29. Continuous Deployment+ Continuous Integration Continuous Delivery lac yFal
    30. 30. Continuous Integration
    31. 31. TDDTest Driven Development
    32. 32. WaterfallThe Assembly Line
    33. 33. TDD vs. Waterfall
    34. 34. Developer Testing TDD is a Design Process
    35. 35. Inside Out vs. Outside In Implement First Test First Easy to Code Easy to Test Difficult to Test Easy to Code
    36. 36. “Tests should always be treatedlike every other consumer of the subject under test.”
    37. 37. Testing Pyramid
    38. 38. Confidencein System Testing Pyramid
    39. 39. Detailed,Confidence Durable,in System Coverage, Faster Testing Pyramid
    40. 40. PHPUnit Groups@small — default@medium@large
    41. 41. Four Tenets of TestingNeed to Know How Much is Being CoveredNeed to Know What is Being TestedNeed to Be Able to Detect Test RunnerErrorsNeed to Have Actionable Test Results(Ownership)
    42. 42. More PHPUnit Groups@group cache for tests that depend on a cache, like memcache@group database for tests that depend on a database@group network for tests that depend on a network@group flaky for tests that fail without code changes
    43. 43. Pre-Commit ProcessLint CheckCode ReviewsCode SnifferAutomated Tests
    44. 44. a·gil·i·ty [uh-jil-i-tee]  noun1. the power of moving quickly and easily;nimbleness: exercises demanding agility.2. the ability to think and draw conclusionsquickly; intellectual acuity.
    45. 45. Agile ManifestoIndividuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan
    46. 46. Things I’ve LearnedNearly every “Best Practice” was developedto address a particular situation.Identify interdependent relationships andrespect them.The code is not everything.
    47. 47. Things I’ve LearnedNearly every “Best Practice” was developedto address a particular situation.Identify interdependent relationships andrespect them.The code is not everything.Nothing is ever complete, finished, done.
    48. 48. Non-Technical Suggested ReadingThe Goal: A Process of On-GoingImprovement by Eliyahu M. GoldrattSwitch: How to Change Things WhenChange is Hard by Chip and Dan Heath
    49. 49. DisclaimersEverything is based on my experienceThings have likely changed since
    50. 50. CreditUIC Genesis 2 Picture: http://www3.uic.com/wcms/images2.nsf/(GraphicLib)/Genesis_GC120Q_new_cvr_lg.jpg/$File/Genesis_GC120Q_new_cvr_lg.jpgDevOps Picture: http://en.wikipedia.org/w/index.php?title=File:Devops.svg&page=1One Button Deploy Picture: http://www.flickr.com/photos/kellan/2422461496/sizes/m/in/photostream/

    ×