Ask Slashdot: How Often Do You Push To Production? 182
First time accepted submitter Stiletto writes "I work for a traditional 'old school' software company that is trying to move into web services, now competing with smaller, nimbler 'Web 2.0' companies. Unfortunately our release process is still stuck in the '90s. Paperwork and forms, sign-off meetings, and documentation approvals make it impossible to do even minor deployments to production faster than once a month. Major releases go out a couple of times a year. I've heard from colleagues in Bay Area companies who release weekly or daily (or even multiple times a day), allowing them to adapt quickly. Slashdotters, how often do you push software changes into production, and what best practices allow you to maintain that deployment rate without chaos?"
Be careful that 'nimble' doesn't become 'untested' (Score:4, Insightful)
Why not talk to your colleagues and suggest ways of speeding things up?
It's good to talk.
Release when ready is quite a good frequency :-)
chaos (Score:4, Insightful)
>> Slashdotters, how often do you push software changes into production,
3 times a month, generally.
>> and what best practices allow you to maintain that deployment rate without chaos?"
IMHO, you can't. Having a deadline every week, programmers cut corners to make dates. QA cuts corners to make the date. This much code changing without any "bake time" inevitably leads to an unstable code base, full of "corner cuts" from the last N releases.
Set a schedule (Score:2, Insightful)
I think customers don't really NEED the frequent updates that you're getting used to seeing with apps. I would think only the foolish really expect rapid releases. That's been a side-effect of "apps" - not what we expect of software in the business world. If you set and can stick to a release schedule, I think your clients will appreciate it.
End users find updating all the time a headache - only super-geeks like us like seeing every possible iteration of an application. The average user doesn't want to be bothered with YET ANOTHER UPDATE (ahem... Flash and Java). But they do appreciate when you have their security interests at heart (like an out-of-cycle Windows Update).
I would say every other month for 'service releases' - every six months for major releases. The biggest exception being "out of cycle" emergency releases when deemed necessary.
Comment removed (Score:5, Insightful)
Sounds like you have a good process. (Score:4, Insightful)
Or were you looking forward to having to explain why your database got cracked and leaked 2 million passwords or that tens of thousands of customer machines will have to be manually patched to repair the damage done by your last update?
It depends on how critical the product is (Score:4, Insightful)
Sometimes all of those meetings and paperwork serve a useful purpose when an application is critical. If a one-day build of instagram doesn't work, then the only consequence is that there are fewer grainy photographs of someone's cat. If a one-day build of a power distribution system doesn't work, then an entire city loses electricity.
As a customer (Score:5, Insightful)
Time to market is not always the metric (Score:4, Insightful)
Re:Sounds like you have a good process. (Score:2, Insightful)
Wait, what? How about explaining why your database got cracked due to your *lack* of updates?
You can do rapid deployments poorly and you can do them well. But when you really really need to deploy and *can't* because of the red tape involved, you're in bad shape.
Re:Gotta raise his Joel Test Scores, first (Score:3, Insightful)
Oh yes, and its worth noting that if you're not careful - easy deployment can quickly result in lower software quality. If you make deployment too easy quality drops like a rock if people think they can fix it easily the next day or even intraday. Some cultures reward by the # of releases/features in prod without looking at the total impact. 'Faster' is not necessarily better although useful in certain situations certainly.