It's a name for a method of operation by software developers.

Originally, programmers didn't think much about how they wrote some particular software. They were talked to hack on the keyboards asap. The result was a mess of buggy, unmaintainable spaghetti code. After some time, people decided they need to structure the process of developing software. That lead to the "waterfall" model, which divides the process into several steps:

1. understanding what the clients want
2. (possible) prototyping
3. design phase: modeling classes, defining relationships, brainstorming flowcharts, outlining user interfaces and so on
4. integration phase: what is planned should be implemented without any change to the design
5. testing phase: code is reviewed, runned against tests and bugs shall be fixed, maybe progressive enhancements to the code, but no breaking changes (like, switching from MySQL to PgSQL: not allowed, but exchanging an algorithm for a faster one that accomplishes the same: allowed)
6. presentation phase: software is reviewed by the client. if everything is ok: ship it

Devs applied to software development the same model that was known from hardware engineering. This was acceptable until the late 90s. Requirements didn't change very often. But today, they do. Management of clients is continuously evaluating how they could improve their product/the way they sell it/how to lower costs etc. Today it's the default that a client wants some additional feature after a few months or wants to change some existing feature or wants to change the UX. This is whee continuous integration kicks in. Software cannot be planned statically. If the software is designed and written in the right way, it can be changed quick and with extremely low costs compared to hardware, means it is possible to have developers continuously integrating additional changes.