Agile is King, But Continuous Integration is an Elusive Goal

Methinks the article title is misstated. I don't think it is the continuous integration that is most elusive, but the continuous deployment!

Getting a small-team to breakdown work into small, testable chunks that every developer commits & integrates multiple times a day is no mean feat, but is nowhere near as elusive as having it "go live" to production deployment more than daily.

Even continuously delivering working software every day into the hands of business-users (for feedback) is formidable, yet not as much as deploying to live production at comparable frequency.

The progression usually goes from infrequent "big-bang", to frequent integration/build, often to daily build, then continuous integration before ultimately getting to continuous delivery, then continuous deployment.

Folks have enough difficulty getting to continuous integration as part of their agile efforts. Let's not make it more intimidating by implying that deploying to production is part of CI, rather than a successor to CI.

I second this! The bigger challenge is to achieve continuous deployment.

Thanks for your feedback. The article is not about Continuous Deployment because this state of maturity implies automatic deploys with no explicit deployment action performed by a human. I can agree that the title could be easily changed to mention Continuous Delivery because it is mostly about "Continuous integration with an ability to deploy often".

Best regards,

Rui Miguel Ferreira.

It would be nice to get more info on these trends... What kind of changes, what environments, and what they feel to be the roadblocks.

Our team deploys to UAT every 2 hours 24/7, and to production on a daily basis. Thats for planned changes, and doesn't cover configuration changes, just meta and code. Configurations are changed right away, hotfixes take two hours because of dependency validations and automated tests performance.

And yes... It is continuous delivery, not just CI. If you commit to the staging branch, at 8PM it goes live.

Thanks for the reply!
So I gather your interpretation of the primary difference between continuous delivery vs continuous deployment is that the latter is fully automatic from commit to deploy (in production) with no option to (manually) trigger the deploy instead of always doing it automatically?

That would be a good assumption to explicitly state, because there are some key differences between the two, but not always the same ones.

• Some would say continuous deployment merely requires continuously deploying to production after every small change, even in the face of many changes per day, whether the final "deploy to prod" step is manually triggered or automated


• and that "continuous delivery" doesn't have to be "live" in (mass)production operation, as long as it still gets into the hands of real business-users in a production-like environment to get real feedback


• whereas others would say both imply deploying to the live production operating environment, whether fully automated or with the option for manual trigger of the final "go live" step)

"continuous delivery" is highly overrated

it's mostly a management wet dream crossed with developer ego bragging rights

zuckerbean's notorious and facile "move fast and break things" is fanboi sloganeering

maybe ok for a silly consumer website, but any application with real business value has numerous considerations, such as stability, reliablity, security, not to mention the impact on real world users, most of whom do not value shiny new doodads over actual functionality