Integration is process. Delivery is a result.

Continuous integration is a process for controlling the code life cycle of a multi-person system that probably has several distinct modules that need to be "integrated". In addition to being integrated, this process tries to ensure that this happens continuously, that is, that there is a certain standard in the procedures that allow to treat the problems that occur in a logical way without having to stop to think about the solution to each problem.

The most common parts of continuous integration (very briefly) are:

• Source code repositories : where you can control the versions, that is, you can have a "photo" of the source code of each package you release for testing, for example.
• Build Steps : where you can have an automated script that compiles source code and generates a testable "package" of your system. In case the code does not compile the developers are alerted as soon as they commit the sources.
• Test Steps : where you can perform manual or automated testing (unit, integration, etc.) of your packages.
• Setup : where you can generate a system-wide "package" that can be installed in a test or production environment.
• Deployment : where there may be a script to automatically install the "package" in the production environment.

Continuous delivery is a result of the continuous integration process with delivery of installable packages to the customer, that is, each period is delivered to a package of the system containing the adjustments and new functions.

In this way, it is possible to have the process of continuous integration without necessarily making continuous deliveries. The term "Continuous Integration" comes from the 1990s and "Continuous Delivery" is more recent because it has become more feasible with new technologies and software dedicated to running and monitoring processes.

Recently (for me) another term appeared in this process called Continuous Deployment . Basically, not to go into detail, deployment would be a step beyond delivery. The delivery ends with a system ready to be deployed to some client or production environment, and continuous deployment would be the process in which that part would also be automated.

I updated the steps in the list above with this new phase of the process.

Searching the Internet:

• link

Continuous Delivery is a set of practices to ensure that a new code is able to be made available in the production environment. The practice incorporates, in addition to all actions foreseen in Continuous Integration, additional and necessary processes for the modification to be accessible to users and thus final inspections, manual and / or automated.     

Leveraging Amazon's definitions:

link

  

Continuous delivery is a DevOps software development practice where code changes are automatically created, tested, and prepared for release to production. It expands based on seamless integration by deploying all code changes in a test environment and / or production environment after the authoring stage. When seamless integration is properly implemented, developers will always have a ready-to-deploy authoring artifact that has undergone a standardized testing process.

link

  

Continuous integration is a DevOps software development practice where developers often merge their code changes into a central repository. After that, creations and tests are executed. Generally, continuous integration refers to the stage of creation or integration of the software launch process, as well as an automation component (eg, an IO or creative service) and a cultural component (eg, frequency). The main goals of continuous integration are to find and investigate bugs faster, improve software quality, and reduce the time it takes to validate and launch new software updates.

devmedia also talks about it:

• INTEGRATION

  

Continuous integration is a term originated in the agile XP methodology and    used in several methodologies, consisting of something simple: the    developer integrates code changed and / or developed to the project    the same frequency that the features are    developed, being done many times a day instead of just one    turn. The main objective of using continuous integration is to    make sure that the changes or new features have not created new    defects in the existing project. The practice of continuous integration    can be done through manual or automated processes,    using tools like Jenkins, Hudson and others.

• DELIVERY

  

Continuous delivery exists for functionality to be released    continuously and safely to the customer. Imagine that when    submit a file to the source repository, the    approval is automatically updated and the adjustment is    available for testing without the need for manual intervention.