Slashdot Mirror

← Back to Stories (view on slashdot.org)

Ask Slashdot: How Often Do You Push To Production?

Posted by samzenpus on from the hold-on-we're-going-live dept.

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

3 of 182 comments (clear)

  1. As soon as it's ready by knetcomp · · Score: 5, Informative

    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.

  2. Read the Facebook Model? by Malenx · · Score: 4, Informative

    Slashdot posted this story earlier,

    http://www.businessweek.com/articles/2012-10-04/facebook-the-making-of-1-billion-users

    Interesting read on how Facebook, arguably the largest website challenge so far this century updates daily.

  3. From Decision to Release in less than an hour by preaction · · Score: 4, Informative

    At $dayjob, we decide to release and our process takes about an hour. All the automated tests are run by Jenkins CI, and are run again during the release on every box being deployed to in order to ensure stability. We tend to deploy to User-Acceptance Testing boxes before full production boxes.

    At the game company, we wrote a system that works like:

    1) Tag release in git
    2) Release is pushed to beta servers. Beta players get immediate updates.
    3) Click button in Jenkins to run stable release

    Completely automated, even down to restarting the servers in a staggered fashion to ensure that users always have a game to connect to (even if they have to disconnect in 20 minutes to receive the client update).

    Automated testing, Continual Integration, and automated release processes (including cfengine3 and custom Perl scripts working with Git) come together to produce a painless release process. Since it's easy, we can do it whenever we want. As soon as it starts releasing bad code, we'll have to put process in place to ensure bad code does not reach our stable users.