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?"

Comments

Visual Studio

[PieDkaj]

I push to production fairly often. Our company's Visual Studios have been configured with test cases that make testing easy, and therefore we can push to production much more often than those who do not use Visual Studio.

As soon as it's ready

[knetcomp]

Most companies I've worked for have a continuous deployment cycle. All changes, from small bug fixes to major releases go through a ticketing system. After the ticket has gone through all the steps (code review, QA, UAT) it goes into the deployment manager's queue, who then deploys the change to production depending on each ticket's priority. This means that in general, changes go out as soon as they are ready, sometimes up to two times a day for the same project.

Depends

[falcon5768]

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.

Gotta raise his Joel Test Scores, first

[Safety Cap]

If he can't deploy to production in one step, he needs to fix that first.

I'm not talking about from dev box to production. I'm talking about the physical act of someone running a single command (or for the Winlazy, pressing a button) then walking away. All code checkouts from source control, database changes, app server code deployments, web server restarts—whatever—happen without user intervention.

He should also be able to roll back in one step.

For all the meetings, forms, etc., it sounds like there is A LOT of CYA in that company. In that case, it is cultural and can only be changed from the top. Until/unless the company becomes less risk adverse, there is no point in trying to become more "agile" (i.e., risk-accepting) except making your job easier. Build your tools/scripts/whatever to make it easier to do stuff.

tl;dr: If you want a more nimble company, switch jobs.