When it comes to web application releases, smaller is definitely better. I’m a huge fan of a monthly release cycle with routine development, code freeze, QA, UAT (user acceptance testing), and maintenance window milestones.
Aligning team efforts with monthly release milestones is usually not terribly difficult (depending on the team and application size) unless there are workflow dependencies that trump the release efforts by rightfully limiting or freezing change in development, test, production, etc. environments on an occasional or routine basis.
The trick is advanced prioritization, scheduling, and clear definition of deliverables comprising a release. Of couse, bigger deliverables have longer development & test cycles, but should still be scheduled to launch with a monthly release further out during a routine maintenance window.
Having automated regression test scripts is a must have. If feasible and possible, in addition to testing as much core functionality as possible they should also include test cases for new functionality.
Advanced reminders to the users who perform UAT and clearly documented UAT test instructions help the UAT phase run smoothly. Consistent use of a bug tracking system is also a must have.
The routine maintenance window is nice, because end users know, for example that on the last Tuesday of every month between 5-8PM PT, the system may be restarted and they may lose their session, new changes will be implemented, etc. It’s also a good time to perform (non-release) infrastructure (hardware changes, OS patching, etc.) maintenance work. Although I may scheduled release deployment and infrastructure work during the same maintenance window, they usually don’t happen concurrently and if possible and necessary, it’s not a bad idea to run regression test scripts in between. This way, if something does go “ass up” (a borrowed phrase from one of my favorite engineers), you can isolate the suspected cause.
And of course, since monthly release cycles result in smaller more manageable releases, risk and quality issues usually are also smaller. The idea is the above benefits far outweigh the overhead required for a release.
One last point, if your environments policy, process, whatever, prevents you from delivering as frequently as is reasonable, it’s time to punt the policy yourself (if you have the means and authority) or be the catalyst for change by shining the light on the disadvantage incurred as a result of not being able to delivery quickly and efficiently.