Your SlideShare is downloading. ×
0
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
How not to_release_software_read_version
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

How not to_release_software_read_version

661

Published on

Published in: Technology
1 Comment
1 Like
Statistics
Notes
No Downloads
Views
Total Views
661
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
9
Comments
1
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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
  • Transcript

    • 1. How not to release software Laura Thomson laura@{mozilla,laurathomson}.com @lxt
    • 2. Conference speakers and book authors arepeople too. Despite our smug demeanor,we also fail.Frequently.
    • 3. This talk sparked by the release-that-shall-not-be named.It went so badly that the version numberwas retired.After 24 hours, people started bringing incasseroles.
    • 4. Thus I present this catalogue of failure, acompendium of things not to do when youwant to release any kind of software.
    • 5. Methodology
    • 6. Agile fail #1Cynical basis of agile: estimation is intractableAvoid estimation by working in short sprints- surely we can estimate the next twoweeks, right?Right?
    • 7. Sprint fail #1: rolloverWe will build these five thingies/bugs/storiesin the next two week sprintTwo are more complex than anticipatedOne is blockedShip two, roll the other three overRinse, repeat
    • 8. Sprint fail #2: Mara-sprintWe can’t get these five things done. Shouldwe ship with only two?If we just push the deadline out a week,everything will be fine.And then another.And then another.
    • 9. Sprint fail #3: Death sprintsWe HAVE to get these five things doneThe deadline is an immovable objectWe’ll just work really really late or all nightevery night for the next two weeksAnd then the same thing again....andagain...and again
    • 10. Things I’ve learnedPlan the dimension of flex and choose: Less functionality in the same time Flexible timelines or slower velocity Continuous deployment Train model
    • 11. Coding
    • 12. Coding fail #1:Build a new bikeshedSitting down to code when you don’t knowwhat you’re doing vsAnalysis paralysis/bikeshedding: getting stucktalking through a complex problem, over andover
    • 13. Coding fail #2: One True RingThere’s one right way to solve this problemComplexGoing to take a long timeScope keeps expanding
    • 14. Coding fail #3: Over-engineeringClosely related to the One True RingBeautiful class hierarchy and architectureLovely diagramsIt doesn’t do anything
    • 15. Things I’ve learnedDifferent people work in different ways.Some people deal better with uncertainty.Those people should build a prototype.Do The Simplest Thing That Could PossiblyWorkBe happy with 60-80% solutions. Iterate.Even if you’re not a startup, Minimum ViableProduct is valid.
    • 16. Testing
    • 17. Test fail #1:The Null HypothesisHave no tests.
    • 18. Test fail #2: Epic confidenceHave some tests, but no idea aboutcoverage.Ensures you have a great level of over-confidence going into a release.
    • 19. Test fail #3:UR DOING IT RONGTest the wrong things.99% unit test coverage, no load tests.Push something out and don’t realize that it’stoo slow, causes data or user loss, until toolate.
    • 20. Things I’ve learnedKnow your coverage and your limitationsUse CIUse browser testingUse load and smoke testingGet QA’s opinion on whether you’re readyto ship something
    • 21. Release anddeployment
    • 22. Deployment fail #1: Version chaosPush master/trunk/head.Have no other branches.Have no tags.Have things that aren’t under versioncontrol.
    • 23. Deployment fail #2:Fail forward, fail backHave no rollback plan.Have no ability to fail forward, either.If failing forward fails, have no backup plan.
    • 24. Deployment fail #3: Manual pushesRelease by manually logging into eachmachine and updating a checkout.This is even better under high load.Scaling is something best not talked about.
    • 25. Deployment fail #4:ALTER TABLE ADD FAILRequire manual changes to databases. Haveno record of the changes in version control.Don’t estimate how long these changes willtake, how much they will degradeperformance, or how much downtime will berequired before kicking them off.
    • 26. Deployment fail #5: Config of DoomRequire manual changes to configuration,especially if there are more than twomachines involved - 30 or more is especiallygood.
    • 27. Deployment fail #6:Single Person Of FailHave only one person that knows how todeploy your stuff.(Don’t document any of it.)
    • 28. Deployment fail #7: It Worked In StagingStaging not the same as prod:Different OS, packages, hardwareOnly one of something where there are >1in prod (classic examples: db replication,memcache)
    • 29. Things I’ve learnedHave a release management systemBuild the capability to deploy continuouslyAutomate everything: build, test, deployUse configuration managementDocument everythingLoad test when neededEliminate SPOFs, including peopleStaging should reflect production
    • 30. Operations
    • 31. Ops fail #1: Devops FailOps and Dev don’t speak to, work with, ortrust each otherMost communication takes place throughaggressive ticket filing and email
    • 32. Ops fail #2: Dilettante devsStuff breaks at 2amDevs have not documented anything andaren’t available to fix itOps gets the blame for extended downtime
    • 33. Ops fail #3: Telepathic troubleshootingStuff breaksDevs have to troubleshoot via remote:Did you look at this log, what did it say?What is this config value set to?
    • 34. Things I’ve learnedEverybody who works on a system isresponsible for itCross train your teamsOpen up systems to devs for read access toconfig + loggingTroubleshoot together
    • 35. Questions?laura@mozilla.com PS We’re hiring

    ×