Slashdot Mirror
Ask Slashdot: How Often Do You Push To Production?
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?"
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 :-)
>> 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.
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.
This really seems like it depends on WHAT your company does. Pushing to production a browser or a utility weekly or even daily is a lot easier and less disruptive than say a OS or a major software product thats used by hundreds of large companies. I would say the biggest obstacle is to get rid of the paper process, bring in git or something else for changes that everyone can view, and limit the signing offs to production, QA, or gold master (or whatever your company calls them) while keeping the dev stuff out of it so that the dev team can be more flexible. Also have a pretty good test lab/suite that will enable you to test stuff on the fly on multiple machines and configuration. Case in point Apple has a testing lab of EVERY machine they have made for the last 3 years in multiple configurations for their software. Granted they are a closed ecosystem so its easy for them to do that, but generally you could get a good roundup of machines to use that span from the insane configs to the "are you fing kidding me you are using that???" type stuff.
"Slashdot, where telling the truth is overrated but lying is 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?
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
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.
-Glires
As a customer I hate daily updates to my applications. Unless the application is in Alpha or Beta it is very disconcerting to see updates at that frequency. I only want to see an update that quick when something is really broken. If brokeness is a daily occurence then maybe you need to slow down.
It depends on your business which metric is meaningful. E.g. for a global bank, quality is more important than time to market. Make sure that your business really gains something by playing release time against quality.
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.