As continuous integration and continuous deployment/delivery become everyday terms in software development and the DevOps world, it’s useful to define what they mean and clarify what each concept includes (and doesn’t).

What Does Continuous Mean?

While the word “continuous” evokes the image of software that is updated with changes coming down the development pipeline around-the-clock, this is not the case. What it typically does mean is that changes are pushed frequently, usually every twenty-four hours or so. Though this is a far cry from truly continuous development, it is faster than conventional cycles using methodologies like waterfall.

Continuous Integration


Source: Carnegie Mellon University’s Software Engineering Institute

Depending on the context, continuous integration (CI) can mean one of two things:

  1. The work done by a continuous integration server, such as Jenkins or Bamboo

Many companies use servers such as Jenkins or Bamboo to automate the test and build process. Code submissions (which are made often) automatically trigger a build and test cycle (during which the developers are still working, since these actions should not require developer intervention), which provides feedback on whether the change(s) are okay or not shortly after the code has been written. Each change is tested, both by itself and as a part of the whole application. The fact that developers are integrating code that has been written and tested on a more frequent basis minimizes the possibility that any given change causes serious problems.

  1. The process of integrating changes into software at all stages of the delivery pipeline

Generalizing on the actions described above, continuous integration is simply the idea that software changes are tested frequently and integrated into the main code base regardless of where the team is on the delivery pipeline. Again, the purpose of this is to provide quick feedback to developers and minimize the possibility that a change causes serious issues and requires the reversion of the application to an earlier state.

Continuous Delivery vs. Continuous Deployment

Continuous Delivery/Deployment (CD) is a process by which an application is delivered to various environments, such as testing or production, once someone (usually a product owner/manager) decides that it is ready to go. Though some people use continuous delivery and continuous deployment interchangeably, there are some differences that should be noted:

  • Continuous Delivery is the frequent shipping of code to a given environment (such as test or production) via manual release.
  • Continuous Deployment is the automated release of code to a production environment.

The Differences Between Continuous Integration, Continuous Deployment, and Continuous Delivery

Regardless of which term is used, the CD process is made up of the techniques, tools, and workflows that aid the above actions and allow CD to build on the benefits offered by CI.

Continuous Delivery

Instead of getting feedback only on whether a particular snippet integrates correctly into the development repository (which is the case when only CI is implemented), continuous delivery practices can provide additional details on things like:

  • Whether new features work in production-like environments
  • Whether packages install correctly after they’ve been changed
  • Whether the automated processes used throughout the delivery cycle work with the new changes

Additionally, CD can facilitate feedback when it comes to aspects that are not easily testable by automated processes. For example, a CI server can run unit and/or regression tests, but the CD process allows for end-user testing, which will provide information regarding business logic-related issues that may slip by automated tests that occurred during an earlier part of the development cycle.

Continuous Deployment

With continuous deployment, the goal is to be able to release code into production environments with short notice (typically using some type of automated process). This requires the maintenance of a branch that is production-ready at all times, so testing is done prior to merging changes into the primary branch. After deployment of code into a production environment, the application’s logs should be checked to determine if the update had a positive or negative impact on things, especially performance.
Keep in mind, however, that not every committed change goes immediately into production–it simply means that the product could be deployed after each validated change. This allows for software releases based on business requirements (such as releasing updates earlier than planned to keep up with competitors or avoiding delays caused by batching in the event that some features are ready earlier than others) instead of technical limitations.


Continuous integration, delivery, and deployment are hot terms in today’s DevOps world, so it’s important to define what they mean and understand their similarities and differences. In general, CI tends to focus on keeping software functional at the development level, while CD tends to focus on the state of the final product. However, depending on the needs of your company and the complexity of your application, you may utilize one or the other (or even both!) for a truly customized pipeline appropriate for your needs.

For customized information on how Rigor can help your company with it implementing continuous integration and/or continuous delivery/deployment,

Suggested Blog Posts

Mobile Banking a Top Priority for Financials

As mobile devices continue to play a more prominent role in our 21st century society, their usefulness has spread beyond the casual activities of technological enthusiasts. According to research conducted by FUNDtech, a rapidly growing number of ba...

Read More

The Perception Gap for Poor Web Performance

E-commerce is a growing source of revenue for many companies and businesses, as it continues to capture market-share from brick-and-mortar stores over recent years. However, many businesses are not prepared for this growth of online business becau...

Read More

Measuring Cross-Browser Performance

In recent years, client-side browsers have been more involved with processing code before it reaches the user's desktop, shifting away from a reliance on servers handling the bulk of this burden. Websites and applications now rely more on a user's br...

Read More

Using Browser Trends to Maintain a Better Site

Because of the multifarious nature of web clients today, it’s important to consider the usage statistics when designing, implementing, and managing your site. However, misconceptions often arise when determining what browsers to design for an...

Read More