So how does this tie in with continuous deployment where people "release" several times a week, or even several times a day?
Not that I disagree, whenever I was working on pretty much anything the constant "We can't release this, there's this missing and this, and that thing doesn't work, and that isn't the prettiest" ... well it can kill pretty much any project.
Release early, release often. Hide in shame if you have to, but just bloody release.
I think the basic premis of his article is sound- Having a schedule for releases lets you better plan the elements of the release (migration? config changes?) and makes the release an occasion (everybody knows that day is "release day", that afternoon is QA, you can make sure they know what is included in the release).
For bugs, I can't agree they should always wait a week. Keeping a production branch where the code is in sync with your deployments lets devs quickly patch and roll out bugfixes, comfortable in the knowledge they aren't deploying somebody else's code at the same time. I've make some customers darn happy by fixing a bug that same afternoon, and I couldn't kick that habit.
But for larger feature rollouts or refactorings, I'm a fan of having everybody on the larger team (devs and non-devs) in sync- and that's easiest when there is a regular, predictable schedule.
I'd also argue that having a regular schedule for deploys makes you more likely to ship, you need to ship something Thursday! :-)
