SlideShare a Scribd company logo

Understanding the CloudStack Release Process

•Download as PPTX, PDF•
•
K
ke4qqq

The document discusses the CloudStack release process. It describes the current process which involves feature development, feature freeze, code freeze, and multiple release candidates that cause frustration. The process aims for a 4 month release cycle but has never maintained the schedule. The document proposes moving to reliance on automated testing, more rigid acceptance standards, gated commits based on passing tests, and releasing more frequently with smaller changes to improve quality and reduce delays.

Related slideshows

Continuous Delivery and Micro Services - A Symbiosis
Continuous Delivery and Micro Services - A SymbiosisContinuous Delivery and Micro Services - A Symbiosis
Continuous Delivery and Micro Services - A Symbiosis
 
Micro Services - Smaller is Better?
Micro Services - Smaller is Better?Micro Services - Smaller is Better?
Micro Services - Smaller is Better?
 
Micro Services - Neither Micro Nor Service
Micro Services - Neither Micro Nor ServiceMicro Services - Neither Micro Nor Service
Micro Services - Neither Micro Nor Service
 
1 of 15
Understanding the CloudStack Release Process David Nalley @ke4qqq ke4qqq@apache.org
#whoami • Director, The Apache Software Foundation • VP Infra, The Apache Software Foundation • PMC Member, Apache CloudStack • Employed by Citrix – Work in the Open Source Business Office – Originally at Cloud.com
Releases • Releases provide end users with usable software • Releases are official actions of the Foundation • Aside from a vote, the release process is left up to the project.
Releases – what we’ve done • We ‘strive’ for a 4 months release cycle. – We’ve never maintained schedule • We have multiple ‘phases’ for the release cycle.
Phase 1: Feature Development • Features developed on branches and merged when ready in this phase.
Phase 2: Feature Freeze • No new functionality • Only bugfixes committed
Phase 3: Code freeze • When all testing is supposed to occur • Stabilize the code base in preparation for release
Phase 4: Release candidates • This is when most testing seems to occur • We end up with many release candidates – The churn causes much frustration
The result • We ‘generally’ have acceptable releases, but sometimes they are delayed many months. • We exhaust our community with repeated test cycles.
Where we want to move (Disclaimer: I am only one person – my views may not be what we end up with. I do not have fiat authority)
Where we want to move • Reliance on automated testing. • Much more rigid acceptance standards for code – Require automated test coverage for new features – Require that problems be fixed and have tests
Where we want to move • Gated commits – based on automated testing. (passing tests as a requirement for each commit)
Faster • We want to release more frequently • Smaller changesets – minimize the effect of change on quality
Questions?
Join us • dev@cloudstack.apache.org • @cloudstack on Twitter • #cloudstack on irc.freenode.net

More Related Content

Understanding the CloudStack Release Process

  • 1. Understanding the CloudStack Release Process David Nalley @ke4qqq ke4qqq@apache.org
  • 2. #whoami • Director, The Apache Software Foundation • VP Infra, The Apache Software Foundation • PMC Member, Apache CloudStack • Employed by Citrix – Work in the Open Source Business Office – Originally at Cloud.com
  • 3. Releases • Releases provide end users with usable software • Releases are official actions of the Foundation • Aside from a vote, the release process is left up to the project.
  • 4. Releases – what we’ve done • We ‘strive’ for a 4 months release cycle. – We’ve never maintained schedule • We have multiple ‘phases’ for the release cycle.
  • 5. Phase 1: Feature Development • Features developed on branches and merged when ready in this phase.
  • 6. Phase 2: Feature Freeze • No new functionality • Only bugfixes committed
  • 7. Phase 3: Code freeze • When all testing is supposed to occur • Stabilize the code base in preparation for release
  • 8. Phase 4: Release candidates • This is when most testing seems to occur • We end up with many release candidates – The churn causes much frustration
  • 9. The result • We ‘generally’ have acceptable releases, but sometimes they are delayed many months. • We exhaust our community with repeated test cycles.
  • 10. Where we want to move (Disclaimer: I am only one person – my views may not be what we end up with. I do not have fiat authority)
  • 11. Where we want to move • Reliance on automated testing. • Much more rigid acceptance standards for code – Require automated test coverage for new features – Require that problems be fixed and have tests
  • 12. Where we want to move • Gated commits – based on automated testing. (passing tests as a requirement for each commit)
  • 13. Faster • We want to release more frequently • Smaller changesets – minimize the effect of change on quality
  • 15. Join us • dev@cloudstack.apache.org • @cloudstack on Twitter • #cloudstack on irc.freenode.net