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"?
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.
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).
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.