. .

Software Delivery at the Next Level: Continous Deployment

You do continous integration – but every release is still a big THING. You fear it, you sit there and you hope it will work. In case you are in this situation, you are obviously behind the next development in our industry. A friend reommended a posting to me that I liked so much, I must put it here again:

So what should Alex do? Continuously deploy. Every commit should be instantly deployed to production. Let’s walk through her story again, assuming she had such an ideal implementation of Continuous Deployment.
Alex commits. Minutes later warnings go off that the cluster is no longer healthy. The failure is easily correlated to Alex’s change and her change is reverted. Alex spends minimal time debugging, finding the now obvious typo with ease. Her changes still caused a failure cascade, but the downtime was minimal. (found at T. Fitz Blog)
When he posted this, what happend, people do not believed him, so his next blog posting is even cooler:

Continuous Deployment isn’t just an abstract theory. At IMVU it’s a core part of our culture to ship. It’s also not a new technique here, we’ve been practicing continuous deployment for years; far longer than I’ve been a member of this startup.

It’s important to note that system I’m about to explain evolved organically in response to new demands on the system and in response to post-mortems of failures. Nobody gets here overnight, but every step along the way has made us better developers. (Fitz)

So – teams who are not able to do this — you are too slow and not professional anymore.

Great test coverage is not enough. Continuous Deployment requires much more than that. Continuous Deployment means running all your tests, all the time.

Well, and there are teams who do not even do tests. And if you do not believe Tim:

The point is that Continuous Deployment is real. It works and it scales up to large clusters, large development teams and extremely agile environments.

My message to all Teams that are not doing Unit Testing, Automated Integration Testing, Continuous Integration and Deployment: “Start to work in this … hard, harder. Do more. If this is possible than you MUST do it also.

My message to Customers: When this is possible than demand it from your teams also.

Avatar of Boris Gloger
„Mut“ ist jener Wert von Scrum, mit dem sich Boris Gloger am stärksten identifiziert. Er hat in seinem eigenen Leben keine Angst vor radikalen Entscheidungen und vor dem Glauben an eine Idee. Für kein Geld der Welt würde er sich Regeln unterwerfen, die keinen Sinn machen. Er glaubt an Scrum, weil es nicht nur bessere Produkte, sondern auch eine bessere und menschlichere Arbeitswelt schaffen kann.
  • martin

    So how do you handle environments with a high frequency or a large number of concurrent workers, when errors might not be so easy to blame on a single developer?

    What do you do about larger changes, when deployment to production needs a large changeset? Rolling out a complicated feature might depend on a lot of files.

    How do you keep individual developers from using SVN because what they need to check in is not deployable?

  • http://chip.de Sebs

    martin: blame? single developer ;) I guess to blame always is the team, never a single person. hard to get that one, but worth working.

    If you got a good continous integration system, a natural decision imho for a scrumming team, non deployable code gets less frequent ;)

    Anyway, question: How to care for different projects. We have one that is deployable in like 1,5 hrs and could be a daily deployment, but another gets a 4 weeks deployment. had a discussion about that and we get back to deploy both tools at sprint end. Its better for the sprint goal,i guess that was the argument of the team.

  • martin

    Blame not in the Forks-and-Torches sense, but as to where to look for the reason for failure. And i wasn’t asking about Continuous Integration but specifially about the Deployment part.

    In the article, some people claim CD works and is scalable but don’t explain how and why. When a build takes 20 to 30 minutes to run, there can be quite a lot of commits in between.
    Also the question still stands how you continuously deploy larger features that normally don’t go into revisioning in a single commit. Deploying to production also means you can’t simply merge something large from a branch to the trunk and try out afterwards whether someone commited something into the trunk in between that breaks it.

  • Pingback: Who is Joke Vandemaele? | Yves Hanoulle