ARS
This is the home of the Agile Release Strategies space. This space was initiated by Niklas Bjørnerstedt and Johannes Brodwall. They plan for the information here to be structured into one or more publications.
- "It won't work here"
- Accept transition costs
- Agile Release Strategies Home
- Antipatterns
- Arguments against releasing often
- Asynchronous deployment
- Automate releases
- Book club system
- Build in stages
- Build trust
- Case studies
- Competing system
- Continuous deployment
- Continuous production
- Customer by customer
- Database views
- Differentiators
- Duplicate input
- Enhancement project
- Facilitate switching
- Feature parity
- Few releases in production
- Follow the workflow
- Incremental migration
- Input split
- Investment in outdated system is waste
- Is it necessary
- Learning curve
- Limited release
- Limited releases
- Live beta
- MRP
- Migrate on demand
- Minimal Deployable Entity
- Minimize migration
- Minimize releases in production
- Navigation
- New business
- New orders
- New product
- New user set
- Pain relievers
- Painless transition
- Partial history
- Partition the workflow
- Patterns
- Potentially shippable
- Principles and patterns
- Product by product
- Read only operations
- Reducing release costs
- Release length - why three months?
- Replacement project
- Replicated database
- Research application system
- Safety in rollback plans
- Sanity check versions
- Scope control
- Scope control and buffer
- Separate schema modifications from data migration
- Shared database
- Study existing system
- Synchronized database
- Synchronous deployment
- Tag data
- Techniques
- The value of Pain
- The value of delaying
- Trojan Project
- Umbrella
- User by user
- User set by user set
- Verify patterns
- Verify patterns and principles
- Why release often
- Workflow by workflow
- Workflow tail first
- XP2010 Workshop
- three months