Share →

Over the past few years Continuous Integration (CI) and Continuous Delivery (CD) have been a part of daily software vocabulary.  As we all work on implementing these practices into our Application Lifecycle Management (ALM) workflows, we have intertwined the definitions of CI and CD . This leads to confusion as to what areas within the ALM workflow we are referring too.

I see the confusion everyday when customers ask for a CI solution that will solve their delivery problems. When I hear this type of request, I need to first ask them what they mean by a CI solution.  As we discuss and dive into the details, I find that the majority of the time the customer refers to CI when they really mean CD.

So what is CI?  In short, it is an integration of code into a known or working code base.  One could argue that a deployment into an environment is an integration of code. This is where I want to limit CI to only source control and to provide a clear definition that teams can use to simply identify the practices and actions.

To drill down into the practices of CI a bit more, we need to understand the benefits of CI practices to the team.  The top benefits are to provide fast feed back to the members of the team and to ensure any new changes don’t break the working branch.  By having fast results – less than 5 min – team members can fix small mistakes that are made during any development process.

One example of this was when I worked with a global team (located in the United States, India, and Ireland). I was able to see firsthand how large of an impact a simple broken build can cause.

A developer in the U.S. checked in the code at the end of the day as they completed a task.  The CI build kicked off and took over 30 to 45 min to complete (this was due to a number of problems that I will not go into).  The developer leaves to go home, to make it in time to pick the kids up from soccer practice, and is unaware that their code change did not integrate with the other daily changes.  Yes, it worked on their machine, but the local changes broke the build when integrated with the latest changes.

As the other teams started their day, they needed to spend extra time to fix the issue, move around the broken build, or (what I’ve seen) ignored the problem and passed it along to the next team.  The India and Ireland team members mutter, “if the U.S. broke it, then they need to fix it,” which causes the “us vs. them” dynamic within teams.

If the CI build had been fast, then the developer would have received the feedback sooner and fixed the small change before they left. The next team would have been able to start the day with a clean build and baseline – avoiding frustration, delays, and hidden problems.

Now that I explained the CI part, I want to dive into the CD definition.  As above, let me first define CD.  In short, it is an automated process to deliver a software package to a environment.   In that short definition, there is a number of tools, techniques, and workflows that make up the CD process.

As above I will describe the top benefits of CD. There are a great  number of benefits to CD, and to explain them all would require another blog post.

Using the example from above, we have created fast feedback to and from teams. With CD we can now extend the fast feedback loops and reduction of constraints with packaging techniques, automation workflows, and integrated tools that keep track of the software versions in different environments.

You can easily envision that the CD practices also provides a different set of data to the teams.

  1. Does the new feature work correctly on a production like server environment?
  2. Do the packages install correctly?
  3. Does the automated process that will be used throughout the delivery pipeline work? (one package, same delivery, many times, to all environments)

To wrap this all up, CI and CD are two completely separated practices that are tightly interlocked to create a unified ALM workflow. It is very easy to blur the two practices and call it one thing to cover a vast and complex set of processes to deliver software faster, and with higher quality.  By defining CI and CD practices, and understanding the areas and benefits of both, teams can create, prioritize, and complete tasks in a more efficient manner.


Print Friendly
  • Excellent one, Thank you

  • Dzsoni Filpó

    I still do not understand the difference between CI and CD.
    “In short, it is an automated process to deliver a software package to a environment.” – this seems to be too general for me to clearly see what you mean by software package and environment here.

    Does it mean that CD kicks in after CI is done? So whenever the code is tested in the development branch, and is checked in into master branch, then the package can be compiled and delivered to an environment where further tests can be made? How does this package created to this separate environment differs from where the master branch is tested and used (apart from the processes and tools used for deploying the build to another environment)?

    Sorry, just trying to understand all steps.

  • Rafael Alves

    I think that what he was trying to say is that CI is for development concerns only. You don’t necessarily are worried with delivering yet. So you don’t need to make all the tests, just those which guarantee that the build doesn’t get broken.

  • Ashish Srivastava

    very helpful !! thanks a lot

  • Kanthu

    Wow. this is exactly what I am looking for. Thanks a lot for the example which made me experience how CD will be helpful.

  • Kanthu

    In CI developer is only worried about the build part the code and you no need to test the actual effective functionality of the new code.

    As you said CD kicks in after CI where actual testing and other procedures to make the changes available to clients at the earliest.