×

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

CI

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.

Takeaways

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

The Perception Gap for Poor Web Performance

E-commerce revenue continues to grow,as consumers turn away from shopping in brick-and-mortar stores to shopping online.  However, many businesses are not prepared for this growth because they do not fully understand the market and how to invest in...

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

Finding Causes of Intermittent Errors from Google Webmaster Tools

Google Webmaster Tools is a web service that allows webmasters to view the status of their sites as seen by Google and the Googlebot crawlers. In addition to indexing your site structure and content, the Googlebot crawlers also record data on perform...

Read More

Optimization Options not Always Optimal

Web designers and developers are always looking for ways to speed up their page load times. Yahoo has an excellent article written on the best practices for speeding up your page. How do you know if implementing one of their suggested practices will...

Read More
  • Hey Victoria, good job on explaining the difference. However, I think the biggest challenge is convincing developers to introduce any form of automation to their workflows. Many of them think it’s too complicated and the effect is simply not worth the effort.

    We made a tool that simplifies this process by letting developers build, test and deploy web projects on a simple push to Git: https://buddy.works

    The whole thing is very easy to use, with initial configuration cut down to 15-20 minutes (try doing that on Jenkins), and uses isolated Docker containers for builds (i.e. every developer works in the same environment).

    If you’re interested, we’ll be happy to make a dedicated integration with Rigor that would, for example, send a notification to your service on every deployment. Let me know if you’re interested, and keep up the great work!