What does "continuous" mean in "continuous deployment", "continuous delivery" and "continuous integration"?

What is it opposed to?

Does "continuous" make "deployment", "delivery" and "integration" do more things than without "continuous"?

  • Think about a continuous industrial process vs a batch process.
    – user253751
    Sep 28, 2017 at 22:10
  • Not quite an answer, but might be helpful not to take that term too much by word. The term "continuous" has some history. Was used and popularized by Fowler in 2000. Its meaning might have shifted since then. I quote Duvall to make it clearer: We use the term "continuous" in this book, but the usage is technically incorrect. "Continuous" implies that something kicks off once and never stops. [..] So what we are describing in this book is more like "continual integration". (Source: "Continuous Integration", Paul M. Duvall, p . xxii) Oct 1, 2017 at 14:36

4 Answers 4


Traditionally, before Continuous Integration, Continuous Build, Continuous Deployment, Continuous Testing, etc., the system was split into modules and those modules were developed by independent teams which didn't interact very much.

The term "integration" refers to the event when those independently developed modules were assembled together into the complete system. (That's also where the term "integration testing" comes from.) This was usually a one time event. I.e. the entire system was developed, sometimes for years, in complete isolation without ever once having worked as a complete system. Then, at the very end, the modules were put together ("integrated"), built, tested, and deployed. This means that basically the first time ever that the entire system was running, was directly before the delivery date.

Except of course, most of the time, it didn't run. And then you had to go hunt down the problem in a complex system with complex interactions between complex modules. And because integration was such a painful event, it was seen as something painful and expensive.

The idea of Continuous Integration turns this on its head: instead of pushing off the integration until the very end, and making it a huge painful one-time event, you do it always, every time there is a change to any module. That way, you get better at doing it (because instead of only doing it once per year, you do it several times a day, thus you have much more practice) and it becomes much simpler (because if you integrate at every change, then you spot integration problems early, and you know that the problem is with that single change).

So, that's where the idea of Continuous XYZ comes from: instead of pushing XYZ to the very end, when it is too late to actually change anything, and only doing it once, you do it as early and often as possible.

In order to facilitate this continuity, usually the process is automated to a large degree, which gave rise to the idea of Continuous Build Servers, Continuous Integration Servers, etc.

Note that that's the same idea with Pair Programming (which you could see as "Continuous Code Review"), making frequent small commits, etc.

  • 1
    "Continuous" in "continuous integration" is used in a slightly different way than it is in "continuous deployment/delivery" as explained in Bastian Stein's answer. CI usually means something like running integration tests automatically after each commit (or some variation on this). Continuous deployment/delivery may mean deploying after each commit, but it more usually just means that deployment can be done whenever requested. E.g. you don't need to wait until the end of a "sprint" to have a deployable artifact containing the features completed so far. Sep 29, 2017 at 21:48

Continuous integration (CI) is the practice of frequently integrating changes with the main codebase. In order to do CI, you probably want a CI server running automated tests on your codebase with each commit, verifying successful integration. Developers pushing to the codebase should keep their commits small, and pull/push changes frequently.

Continuous deployment is the capability to deploy software to production at any given time, with no manual effort (other than maybe pressing a button). Typically this is achieved by means of deployment pipelines and test automation.

Continuous delivery is the capability to deliver software at any given time. If you have a set of features ready for release, the business can decide which features to release at which time, and on an individual basis. It necessitates decoupling of release from deployment.

The distinction between deployment and delivery lies within whether the code is active in production or not.

Deployed means, the code has made it to the production servers. It may or may not be active. For instance, you may have feature toggles which control the delivery of the software after it has already been deployed. If you don't know what feature toggles are, you may think of them as if-branches which you can manipulate/toggle at runtime.

Delivered means, the code not only has made it to production, but is also "active", thus providing business value.

In this context, "continuous" is opposed to "discrete". Where continuous would describe an uninterrupted flow of events (i.e. water streaming from a tap), discrete would describe an isolated sequence of events (i.e. drops of water dripping from a tap).

In terms of software development: As opposed to only integrating/deploying/delivering in fixed intervals, possibly necessitated by technical limitations, regulations or simply lack of knowledge, you are able to do these things continuously, when it best suits your purpose or the business needs.


Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day


The 'continuous' means that you have a process on which you are able to perform the integration of new code, the build and deployments sistematically and frequently (usually in a daily-basis).

  • Daily basis would be called "Daily-XXX" Continuous to me means at every changed pushed in the source control. Or at least that would be the aim depending on the time it takes to do the task.
    – Newtopian
    Sep 28, 2017 at 20:42
  • @Newtopian I agree, I just provided a quick summary of the content from Fowler's page. I guess he stated the daily basis as usual frequency already considering only bigger projects on which the builds take a long time to be performed. Oct 4, 2017 at 10:15

Unlike other guys here said, I would say these things are not about trying to make releases more frequent but about making the overall process more smooth. When each person or department works on its component without excessive meetings and distracting others the whole development becomes faster. The release frequency is more a derivative effect than a goal.

And all three terms are pretty much the same thing:

  • Continuous Integration (CI) is about having no need to ask "hey dude, in what state our master branch is now? is it broken? can I merge?" -- instead you don't care in what states of work your buddies are and when you finish with your component you make the CI system know about that by, for example, creating a merge request. The automation will take care of the rest like starting automated testing, integrating your component with others.
    Is branches merging automated or not, who and how decides to merge or return the ticket back to you for improvement -- that's another question.

  • When the step of compiling of your software product is in the CI pipeline it is called the Continuous Delivery (CD).

  • When your product is a website or some sort of a running application the CD can be called a Continuous Deployment.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.