At my company (3-yr-old web industry startup), we have frequent problems with the product team saying aaaah this is a crisis patch it now! (doesn't everybody?)This has an impact on the productivity (and morale) of engineering staff, self included.  Management has spent some time thinking about how to reduce the frequency of these same-day requests and has come up with the solution that we are going to have a release every week.  (Previously we'd been doing one every two weeks, which usually slipped by a couple of days or so.)There are 13 developers and 6 local / 9 offshore testers; the theory is that only 4 developers (and all testers) will work on even-numbered releases, unless a piece of work comes up that really requires some specific expertise from one of the other devs.  Each cycle will contain two days of dev work and two days of QA work (plus 1 day of scoping / triage / ...).My questions are:(a) Does anyone have experience with this length of release cycle?(b) Has anyone heard of this length of release cycle even being attempted?(c) If (a) or (b), how on Earth do you make it work?  (Any pitfalls to avoid, etc., are also appreciated.)(d) How can we minimize the damage if this effort fails?
One-week release cycle: how do I make this feasible?
agile;quality;release management
You can certainly deliver every week - or even more frequently. At the moment we generally release every two weeks, but it isn't unusual to deploy functionality when something has arrived with no notice from one of our partners that would be irrelevant if we waited for the next cycle. At some point in the next few months I'd like us to move to continuous delivery (items are released as soon as is practical once they're 'done') as standard, but we're not quite confident enough yet to go that far.The critical thing is you need your website strongly covered by automated tests - both unit tests and end-to-end acceptance tests/executable specifications. By implication this also means that your build is fully automated. At the acceptance level we use Robot Framework which is excellent for quickly building up a maintainable test suite thanks to it's keyword approach. For look and feel our onsite tester makes some cursory checks, but we also have a couple of guys in India who do a more thorough check across different browsers (there are sites which help with this sort of thing by taking screenshots for you, e.g. BrowserLab).We don't fully automate the deployment (the very final step requires manual intervention, this is a concious decision for us) - but we do automate all the things like ensuring that the correct database connections are being used, etc, with short deployment cycles it'd be too easy to make a mistake with this sort of thing.There's a pretty good recentish book on continuous delivery that you might want to check out, I've skimmed it but not gone through it in detail yet. What I've read so far chimes well with our experiences though: Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment AutomationIn summary you need a highly disciplined team, a high level of automation and - most important of all - an extremely high degree of trust in that automation. To me it seems that moving to weekly cycles in your case may be a mistake - crisis patches hint at other issues and you should work to eliminate those. Upping the tempo could potential make the situation worse...