

Importance of regular, consistent release schedules in webdev. - mromaine
http://mygengo.com/talk/blog/release-schedules/

======
SAASie
I don't know about this guys. Seems simple to me —If the product ain't ready,
you don't release.

------
Swizec
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.

~~~
mixonic
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! :-)

