[Silhouette]

The motivation for continuous integration I can certainly understand. I'm sure many of us have worked on projects where someone was working on a branch for an extended period to implement some big new feature, and then ran into the mother of all merge conflicts when they finally wanted to release their changes for general use. I don't think CI is appropriate in all cases, but I find it a better strategy than mega-merges for most projects, most of the time.

It's specifically the motivation for continuous deployment that I'm curious about here. Fixing bugs quickly is obviously a plus, and I found the point 'twic mentioned about rapidly instrumenting a production system interesting. These are good arguments for being able to release an update on demand, and indeed for continuous integration as a technique to support that goal.

However, to me neither seems like a strong argument for routinely releasing multiple updates per day. I've always been a little surprised that so many web sites and SaaS applications seem to take pride in making such frequent changes, even though doing so surely incurs some risk of breaking things and typically also causes some degree of instability in the UI. I was just wondering whether anyone had experiences and/or actual data they could share about whether the practice made a measurable improvement to, for example, revenues or reported customer satisfaction -- something concrete that might outweigh the risks -- or whether it's more of a subjective preference for that way of working.

[gtaylor]

> However, to me neither seems like a strong argument for routinely releasing multiple updates per day.

I don't understand this line of thinking. If there's a bug that you can fix in short order, why not fix it and deploy said fix? If you've set your CI and infrastructure up correctly, update rollouts aren't something the user even notices.

I've always been a big proponent of small, atomic commits. Being able to deploy just one thing at a time means we often know where breakage comes from (when it happens), and we can respond to feedback sometimes within minutes.

The customers love it, and we enjoy excellent stability and development velocity. These are the reasons we deploy many times a day. There's no reason for us not to deploy things once they are tested and ready.

[Silhouette]

If there's a bug that you can fix in short order, why not fix it and deploy said fix?

If you've got an important bug to fix, sure, of course you want it dealt with as quickly as possible.

If you've set your CI and infrastructure up correctly, update rollouts aren't something the user even notices.

Not if it's for a bug fix or security patch, but presumably most of your development work is adding new features? In that case, isn't the whole point that it's something the user will notice?

I've always been a big proponent of small, atomic commits.

And again, no argument from me there. While I don't think every development project is suitable for that approach, I favour it most of the time myself.

Being able to deploy just one thing at a time means we often know where breakage comes from (when it happens)

This is where my experience and background seem to be very different to the deploy-hourly kind of philosophy. I've noticed that proponents of the latter often seem to assume that stuff is going to be breaking all the time, and therefore that being able to deploy bug fixes or diagnostics very quickly will be a significant advantage.

However, if you have so many significant bugs that you need to deploy multiple times per day just to keep up, to me that seems like a clear demonstration of insufficient QC/QA in the development process. And so I can't help wondering whether the pressure to release so often, and the consequent almost exclusive reliance on some sort of automated test suite for quality checking, is a causal factor in having so many bugs in the first place.

The customers love it, and we enjoy excellent stability and development velocity. These are the reasons we deploy many times a day. There's no reason for us not to deploy things once they are tested and ready.

I guess this is the paradoxical part that I don't understand. If your project enjoys excellent stability and your deployments are all soundly tested before they go live, then by definition you don't need the rapid deployments just to rush out bug fixes or diagnostics.

So that brings me back to where I came in: do you experience any concrete, measurable benefits from the "excellent development velocity" you mentioned, or is it simply your team's preferred development style?

[gtaylor]

> So that brings me back to where I came in: do you experience any concrete, measurable benefits from the "excellent development velocity" you mentioned, or is it simply your team's preferred development style?

Yes, see the following:

> The customers love it, and we enjoy excellent stability and development velocity. These are the reasons we deploy many times a day. There's no reason for us not to deploy things once they are tested and ready.

We're not just deploying bug fixes quickly (which you seem to be fixating on a bit), we are constantly making small iterations. If we're handling support and see something that could be improved, we improve it and roll it out quickly. If we have a moderate sized feature branch, it is merged, tested, and rolled out immediately as soon as it passes QA. No need to set a rigid "We only deploy on Wednesdays" schedule. Pass QA, deploy immediately.

> Not if it's for a bug fix or security patch, but presumably most of your development work is adding new features? In that case, isn't the whole point that it's something the user will notice?

No, a huge chunk of dev time is spent iterating on and improving existing features. There gets to be a point in a product's life cycle where you are more or less feature complete, where the emphasis shifts to refining and improving what you already have. Sure, there are new features, but if you never iterate, you've got older stuff accumulating dust and ageing badly.