Agile is King, But Continuous Integration is an Elusive Goal

| by Rui Miguel Ferreira Follow 4 Followers on Mar 23, 2017. Estimated reading time: 1 minute |

A recent survey led by Dimensional Research on the testing trends in modern development teams shows that agile methods are widely adopted, whereas only a few organizations reported the ability to deploy on a hourly-basis, an increasing goal amongst the respondents.

It’s rather common to see this sentence in the topics’ related sites:

It's not continuous delivery if you can't deploy right now!

Although 89% of the organizations reported the adoption of an agile development methodology, compared to 82% reported two years ago, the results on the ability to deploy often are quite different.

As mentioned by Charles Babcock in his article:

Continuous integration with an ability to deploy hourly, often described as an end goal of adopting an agile development process, was cited by 28% as the destination they were shooting for. However, only 14% were actually doing so. Hourly continuous integration a year ago was a goal for only 18%. The added 10% a year late shows how quickly continuous integration is rising in the consciousness of development staffs. It's rising faster than the actual ability to deploy, currently at 14%, but a year ago a similar Dimension Labs survey showed it to be 10%.

The results in the report show a “notable improvement” in the past year in the time it takes to deploy a new build. When asked “how often does your team typically deploy a new build?”, the interviewees answered that:

  • 14% deploy on an hourly basis
  • 34% deploy once a day
  • 21% deploy weekly and 31% deploy less often than weekly

It is worth mentioning that more organizations want to deploy more frequently and less organizations are willing to maintain long deployment cycles.

Devops adoption, often seen as a needed step to improve the ability the deliver faster - amongst other set of advantages - was reported as being in progress / in consideration for 88% of the organizations and only a few reported not having plans to adopt DevOps (6%), or not even considering it (6%).

A total of 732 individuals participated in the survey. Participants included a variety of roles, company sizes, industries and regions. The report was performed by Dimensional Research and sponsored by Sauce Labs.


Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Continuous integration, or continuous deployment? by Brad Appleton

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.

Re: Continuous integration, or continuous deployment? by Lucose Eralil

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

Re: Continuous integration, or continuous deployment? by Rui Miguel Ferreira

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.

Deployment rate by Denys Braga

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.

Re: Continuous integration, or continuous deployment? by Brad Appleton

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)

Either way, the article is really about CD rather than CI (regardless of whether D means 'delivery' or 'deployment'). And that ability to have the (fully or partially) automated option to deploy immediately after the CI is still a much more demanding (and elusive) capability than CI alone.

overrated by phloid domino

"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

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

6 Discuss