Assembla - Release More Frequently Webinar


Published on

Release More Frequently Webinar from September 10, 2013.

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

Assembla - Release More Frequently Webinar

  1. 1. Assembla Approach and followup resources From Andy Singleton,
  2. 2. Agenda  Why Continuous?  Resources  Highlights  Questions
  3. 3. When to use Continuous Delivery?  You provide an online service. Competitive pressure will force you to continuous: Office 365 vs Google Docs  Your release times are getting longer, stressful  You are developing a new product with lean startup and MVP techniques  You have a big project with a lot of contributors  You need to release frequent security patches
  4. 4. Assembla in 2011  “Scrumban” with iterative releases, but continuous planning to accommodate a distributed team.  Releases took longer as system got bigger and there was more to test. 2 weeks -> 3 weeks  Bugs in production. 2 days for fixes. Stressful  Competitors achieved faster velocity with continuous delivery  Made a study of continuous methods with our own team, customers, and tools.  Now – releasing about 250 times per month. Fewer bugs. Much less stress.
  5. 5. Assembla results
  6. 6. What is Continuous Agile?  Continuous Integration test strategies  Continuous Delivery code management  Kanban task management  Continuous “Story Owner” product management Lean, not Scrum  Works for distributed teams, different sizes, faster releases  Not team building and coaching. That is indirect. Focus directly on output. Teams will become high performing when they feel success.  Scrum compatible. Scrum teams are good contributors.
  7. 7. Our Master Plan 1. Release more frequently 2. Improve
  8. 8. Resources Unblock! A Guide to the New Continuous Agile eBook at:  Other vendors and authors – Thoughtworks and Jez Humble with “Continuous Delivery”. Aging.  Vocal practitioners. Etsy. Github. Facebook. Google. Many small Web startups.  LinkedIn discussions – Lean Agile, Continuous Delivery  Workshops: 90 minutes to answer questions with a dev team. Usually finds some simple next steps for RMF
  9. 9. Unblock! on Distributed Teams  Read the chapter on distributed teams. It will make your life easier.
  10. 10. Unblock! Cases Four stories show the diversity of work on CD.  Google and radically centralized CI  Assembla and distributed CD  Mobile – continuous delivery of a user experience  Consulting and Outsourcing – CD for clients
  11. 11. Centralized CI/CDContributor Commits – “as early as possible” to find problems Continuous Integration tests Fail - alarm Release Candidate Test System Release QA Testing Pass
  12. 12. Distributed Continuous Delivery Contributor Commits Branch Fork or Stream Deployed version Peer review merge requests Other contributions merged and released “as late as possible” QA Consults Pass Final Auto Test? Merge back Current Deploy
  13. 13. Multiple Test Systems Contributor 1 Contributor 2 Production Revision Release Anytime CI System QA Team Test System 1 Test System 2
  14. 14. Assembla spins up test servers
  15. 15. Some Client Service Results SaaS Release in 6 weeks. Full builds from week 2. Accelerating.
  16. 16. Unblock! Tactics to Release More Frequently  Scrumban  Test layering  Code Review  Reversible and Risk Free  Feature Switch and Unveil  Release & Measure
  17. 17. Test Layering  Monitor your released software: Errors, Usage volume, usage patterns, user feedback  Wrap services in top-level tests  Code review. This is both a manual test, and a place to ask for test scripts.  Then … Add good unit test coverage with continuous integration
  18. 18. Review after commit. Don’t Contributor Commits Feedback
  19. 19. Review before merge Contributor Commits Fail Pass and merge Team Review and/or “preflight” automated tests • Can scale a centralized CI process • Perforce has a holding area for this called a “Changelist”
  20. 20. Test and Review on temp Branches Contributor Commits Auto tests Mainline Review Auto tests Review • Github style – Pull requests or merge requests going to CI system • Gerrit style – Temporary branches for each contribution • Assembla git supports both – merge requests, and temp branches created by a push to a protected branch.
  21. 21. Reversible Changes Eliminate Risk  Code (use an SCM system)  Servers (Rollback or Swap)  Data (Keep the old data structure while you add the new)  Features (Add new features with on/off switches)  Reversible Thinking  Don’t fix on the fly. Reverse, and then fix  Yoda says “Cling not to your ideas”
  22. 22. Switch and Unveil Hidden Programmer sees a change locally. Change is tested in the main version but not seen. Test Story Owner and testers see the change on test systems. Beta Insiders see it and use it. Story Owner can show it to users for feedback or A/B testing. UNVEIL! The big event. Communicate with all users. Measure reaction. Onecodeversion Nospecialtestbuilds Nolong-runningbranches
  23. 23. Release & Measure  You can force yourself or your team to adapt to frequent releases MERELY BY RELEASING  Who do we release to?  Our dev team  Our company  Our “beta” volunteers  Our free or annoying users, or a random sample  Measure everything possible about usage
  24. 24. Unblock! Roles  Product Managers / Product Owners  Developers (Programmers)  QA  Senior managers  Ops and the controversy around DevOps
  25. 25. Role: Product Manager/Owner  Batch to Continuous  Requirements to User Experience  Strategy and Market Research to Usage Measurement
  26. 26. Product Owner -> Story Owner
  27. 27. Role: Developer  Developers have more power and responsibility.  Developers have more responsibility for testing.  Developers (not QA or PM) decide when to release. This is a strong finding.  Incentives are correct. Developer might have to come back from Friday night beers to fix a problem. This provides a motivation to make good decisions and automate testing.  Features can be released but hidden. Product Managers and Marketers will unveil when they are ready. Unblock!
  28. 28. Role: QA  QA is a consultant.  QA gets more respect. Developers have to ASK for service.  Developers do more of the testing work. They should organize reviews and automated tests so that bugs don’t go through into the manual test process.  QA has more time to investigate usability  QA monitors productivity and quality metrics
  29. 29. Role: Senior Manager  Experiment – start small, learn before launch  Fund the team, not specific features  Measure  Prioritize and limit WIP  Indulge in a few high priority requests  Accelerate other parts of the organization
  30. 30. Our Master Plan 1. Release more frequently 2. Improve
  31. 31. Commercial Message and Q&A  More info at the Unblock! eBook –  Release More Frequently workshop and other hands- on help - or  Assembla Renzoku product contains features for continuous agile task management, review, merge, and measurement. -