Continuous Integration(CI) and delivery(CD) is a software engineering practice that requires steps to be carried out soon after development and is intended to build and test code more often and with smaller changes. The goal is to find problems quickly before they become too expensive to fix: for example, bugs that might take a long time to track down and fix. The result is ultimately higher quality software by finding problems early.

Defining Continuous Integration(CI) and delivery(CD).

Both Continuous integration (CI) and continuous delivery (CD) are being used with test-driven development (TDD) and Continuous Integration (CI).
They all aim at the same thing: building software more often and with smaller changes. The choice of CD as opposed to CI is partly a matter of terminology, but most important is how they differ with respect to speed of implementation: CI runs slow, but CD runs fast. Up to now, CD technology has lagged behind CI in part because most tools for generating code from test cases have focused on CI. And with the introduction of the Git Large File Storage (LFS) extension for Subversion, many CI tools now also work for CD.

What is Continuous Integration(CI)?

Continuous integration (CI) is the practice of merging all developer working copies to shared mainline several times a day. It typically involves an automated process that checks out development work from its version control system, performs tests and quality assurance, and produces updates which are then automatically merged back into the shared workspace. The goal is that if any failure occurs, the entire team can find and fix the problem quickly. In addition, doing so allows the team to roll back changes if tests fail after a change has been merged into production.

In short, CD is taking the CI model further. In this case, developers “commit” their changes to a test environment as soon as they finish making them. If there are no significant problems, testers will run a quick test to ensure the software still works as expected. If it does – and you have told your continuous integration system about this – then you can release it to production at any time with a simple click of a mouse.

Benefits of CI

• CI immediately brings about many positive effects that can improve quality and reduce risk. For example, tests could fail if a change doesn’t use an expected library or function or if a test case fails due to a bug related to that library or function. The CI process can be designed, so files are verified and tested for correctness, leading to faster detection of problems and faster fixes. This has the benefit that the feature may be fixed and tested even if developers didn’t notice it.
• Continuous integration can also provide an early warning about problems with production infrastructure, such as issues with links to the database or memory tables. CI will notice such problems quickly, preventing functional errors from causing production downtime.
• Continuous integration does not require any dedicated testing phase. Instead, tests are run whenever developers check-in code, which ensures they are executed as often as possible.
• Continuous integration may be used to test newly written features and improve their quality before deployment.

What CI is NOT

CI is not a substitute for manual testing or non-functional testing (e.g., usability testing). For example, a developer could still spend a couple of hours manually testing a new feature before it goes into production to ensure that it works as designed.

It’s important to note that Continuous integration is not unit testing because unit tests should not be run unless a feature is first ready for deployment. Continuous integration is typically used as the first line of defense instead of unit testing because unit tests should at least be run after a code change has been merged into a branch in version control.

Note

Some types of automated tests may run for a long time, and CI servers may not have enough resources to run them on time. If one task takes too long, the build fails even if most tasks complete successfully.

Continuous delivery

In software development, continuous delivery is the practice of deploying features frequently and over small time intervals. In a typical scenario, a build will be prepared every night and automatically deployed after a successful run by an automated build or release management tool. The idea underlying continuous delivery is to reduce friction between developers and operations staff by keeping the software in a state where it can be deployed at any given moment to production systems. Once launched, the new functionality will immediately be visible to users. In this way, developers gain more confidence that what they’ve built works as intended before it takes root on production systems.

In short words, Continuous delivery (CD) is the practice of integrating, testing, and deploying code at various points to achieve availability (e.g., “on-demand”). CI/CD tools provide automation, which can make each integration pass faster than it would be performed manually. The main benefit of CD over manual methodologies like TDD is that automated tests can give suggestions about problems before code is deployed to production.

In most cases, Continuous delivery tools require less customizability than continuous integration tools because the promise is that all operations are already automated.

Continuous delivery is a specific practice within the agile software development process. In this process, all changes to the system are tested and deployed incrementally. The key aspect of continuous delivery is that many small incremental changes are deployed concurrently from a continuous integration server. Therefore, this process typically has no final release—there will always be new changes being made to it.

Conclusion

Continuous integration is closely related to continuous delivery when both concepts are used in conjunction with one another.

Read a more interesting article on the different types of automation testing.