Continuous Integration vs. Continuous Deployment

Continuous integration (CI) and continuous deployment (CD) are interrelated development practices used by software teams to ensure that code changes go through various quality checks and transition smoothly from development to production environments. To achieve this objective with minimal effort, developers use a CI/CD pipeline, which consists of a series of automated stages that code changes pass through before they get deployed to a production application environment. Platforms like Github and open source tools like Jenkins are popular choices for implementing CI/CD pipelines.

‍

Continuous integration (CI) is the practice of developers regularly integrating code changes into a shared codebase that is used to build the software. CI makes use of automated testing to keep a check on these integrations.

‍

Continuous deployment (CD) is the practice of delivering software changes into the hands of users as soon as they get implemented. CD uses automation tools to test, build, and deploy code changes to a production environment. CI and CD can help teams develop software effectively and deliver reliable outcomes.

‍

In this article, we will discuss the basics of CI/CD, explore the goals of these practices, distinguish between CI and CD, and find out how to practice them effectively.

‍

Key differences between CI and CD

‍

‍

What is continuous integration?

Continuous integration is the practice of developers in a team regularly integrating code changes into a shared codebase used to build software. This practice became popular as part of the DevOps movement and has become effective with the advent of rich development tools.

‍

In a typical software team, multiple developers work on a piece of software and merge their code changes into a shared codebase multiple times a day. A good version control system, an automated pipeline, and communication systems are put in place to make this collaborative effort seamless and productive.

‍

Traditionally, development and integration were different phases in the development cycle. Developers would often work on a set of features assigned to them without knowing what changes their colleagues were making to the codebase. After the development phase ended, in the integration phase, developers would collaborate, bringing together all their code and integrating their changes into a single codebase, which was then tested. This process took a long time. Sometimes the changes made by different developers wouldn’t work well together and caused errors, adding more challenges to the team. This kind of development cycle was typically less effective than a team practicing continuous integration.

‍

The field of software development has come a long way over the years, identifying many pain points in the overall process. One best practice that has emerged from these observations is to achieve the desired outcomes by making small changes at a time and merging them. This allows teams to frequently leverage better collaboration and ease of rollback to increase confidence in the software produced and enable easier maintenance.

‍

Advantages of continuous integration

Teams that practice CI effectively experience the following benefits:

‍

• Risk reduction: These are generally agile teams that make small changes at a time and frequently integrate these changes. This allows bugs to be caught early and conflicting code changes to be resolved quickly, often leading to higher software quality.
• Enhanced reliability: Code changes going through a CI pipeline inevitably go through an automated testing stage. When tests are written with large code coverage, the software’s reliability improves.
• Less context switching: Within the context of building a feature or fixing a bug, developers learn to switch among roles as needed to progress code changes through the development cycle. Some of these roles include writing tests, setting up CI workflows, responding to CI notifications, providing hotfixes, and so on. Working with such a broad context means that these developers don’t feel the cognitive resistance that more traditional developers experience when switching roles to accomplish tasks.
• Faster delivery cycles: CI, when done right, leads to faster development.
• Better monitoring and feedback: CI pipelines can automatically track code performance and notify developers to take action when a failure occurs.
• Richer collaboration: CI, along with agile practices, naturally promotes collaboration among team members.

‍

Disadvantages of continuous integration

Continuous integration also has some challenges:

‍

• Difficulty in implementation: Success in practicing CI requires a good DevOps culture to be instilled in the team. This demands experienced leadership and developers willing to learn to be comfortable juggling multiple roles in the development process.
• Testing overhead: The key to a good CI pipeline is the quality of the testing stage. It is essential that the test cases are of high quality, which takes a lot of time and effort to achieve.
• Team dependencies: For some teams, collaboration could become challenging; this is especially true for remote teams with members in different timezones, where CI practices could create dependencies among members. For example, a developer might have to wait for another member’s approval before integrating code changes.

Environments as a Service (EaaS)

Platform

Qovery

Release Hub

Uffizzi

Lightweight and Fast (All-Container Solution)

✔

Easy Setup
(Based on Docker Compose)

✔

Reusable Github Actions Workflow

✔

Cost
‍

$$$

$$$$

$

See Comparison Table

Platform

Lightweight and Fast (All-Container Solution)

Easy Setup
(Based on Docker Compose)

Reusable Github Actions Workflow

Cost

Qovery

$$$

Release Hub

$$$$

Uffizzi

✔

✔

✔

$

See Comparison Table

What is continuous deployment?

Continuous deployment is the practice of having code changes made in the shared codebase be automatically deployed to a production environment and made available to end users without any delay.

‍

It is worth pointing out that continuous delivery is a closely related practice and is also sometimes abbreviated as “CD.” Continuous delivery uses automated testing and infrastructure as code (IaC) to provision the infrastructure needed to bring software into a releasable state that is ready to be delivered. The key difference between the two is that in the case of continuous delivery, the release of software can be scheduled and goes through a review by humans.

‍

Teams often have to choose between CI and CD; CD can be seen as an extension of CI. While CI stops with automated build and test stages, CD has additional stages in its pipeline, including deployment to a production environment.

‍

CD is achievable due to the advent of the cloud services, containerization, and modern tooling that are available to define infrastructure as code. For example, consider the docker-compose.yml file below; it defines the resources needed to serve an API service in an isolated environment.

‍

 
	version: "3.7"
services:
    app:
        build: .    # build app based on Dockerfile in project directory
        ports: 
            - "5000:5000"
        environment: 
            - MONGO_USER=${MONGO_USER}
            - MONGO_PASSWORD=${MONGO_PASSWORD}
            - MONGO_DATABASE=${MONGO_DATABASE}
            - MONGO_CONNECTION_URL=${MONGO_CONNECTION_URL}
        volumes:
            - "./:/usr/src/app"
    
    database:
        image: "mongo"
        environment:
            - MONGO_INITDB_DATABASE=${MONGO_DATABASE}
            - MONGO_INITDB_ROOT_USERNAME=${MONGO_USER}
            - MONGO_INITDB_ROOT_PASSWORD=${MONGO_PASSWORD}
        volumes:
            - ./init-mongo.js:/docker-entrypoint-initdb.d/init-mongo.js:ro
            - ./data:/data/db
        ports:
            - "27017-27019:27017-27019"    
    
    # connect to mongodb://<username>:<pass>@127.0.0.1:27017/<db-name>
    rabbitmq:
        image: "rabbitmq:3-management"    # rabbitmq with management plugin
        environment:
            - RABBITMQ_DEFAULT_USER=${RABBITMQ_USER}
            - RABBITMQ_DEFAULT_PASS=${RABBITMQ_PASSWORD}
        ports:
            - "5672:5672"
            - "15672:15672"    # go to http://localhost:15672 to manage messaging with UI

‍‍

‍This kind of infrastructure specification is maintained in version control and can be used at any stage of CD to create an environment and provision various infrastructure resources, like a server instance, database instance, queue service, etc.

‍

Failure at any stage in this pipeline notifies developers via various channels, such as Slack or email. Developers rely on these automated notifications as a call to action. This kind of system also saves time and cognitive effort for developers because they don’t have to partake in rituals like manually checking for faults: They can rely on CI/CD to pick up any weaknesses in the software.

‍

Advantages of continuous deployment

In addition to the advantages of CI, teams practicing CD experience the following advantages:

‍

• Shorter delivery cycles: Frequent delivery is a goal of CD, and an effective CD pipeline shortens the time between development and deployment.
• Frequent value addition for users: Users get faster updates, leading to more frequent value enhancement as well as faster security fixes.
• Shorter feedback cycles: Feedback at various stages is improved, providing developers and decision-makers with timely access to relevant information.
• Easier rollbacks: With frequent small changes deployed, it also becomes easier to roll back problematic changes.

‍

Disadvantages of continuous deployment

Apart from the disadvantages of CI, teams practicing CD find the following disadvantages:

‍

• Complexity: CD pipelines can be complex because they make use of many technologies. They demand developers to combine various skills involved in creating and maintaining them.
• Technical debt: If CD pipelines are not updated regularly, technical debt can build up, making it harder to improve the software.
• Reliability of dependencies: CD relies heavily on automation tools. If these tools fail or produce incorrect results, this can have a major impact on the software deployment process.
• Reduced security: If the required automated tests are not put in place, code changes with security risks might pass through the pipeline, delivering software with security vulnerabilities.

Continuous integration and continuous deployment

‍

Relationship with DevOps

CI/CD is one of the shining outcomes of the DevOps movement, which aimed to change the culture and skill levels in teams across the software industry. DevOps aims to merge the archetypal roles in development and operation teams and to automate key processes in software development, including the process of software delivery, which CI/CD helps achieve.

‍

Relationship with agile methodology

CI/CD practices are fundamentally aligned with the agile methods of making software. Take a look at the first principle of the 12 listed in the Agile Manifesto:

‍

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

‍

This highlights the importance of continuous delivery of software, which CI/CD enables teams to do. Agile practices have shaped today’s CI/CD best practices, and it would be difficult to discuss one concept without mentioning the other.

‍

Recommendations

Here are some tips and facts to consider if you are trying to decide between CI and CD for your next project:

‍

• Teams practicing CI focus on improving code quality while keeping control over software releases. In contrast, teams practicing CD most often are interested in making multiple releases each month.
• Set clear goals for your team’s CI/CD practices. Measure success using metrics such as time to market, deployment frequency, number of bugs, and time to resolution.
• Keep in mind the nature of your software. If security lapses are intolerable, then CI is probably the way to go, as code with security issues might get deployed when using CD.
• CI and CD can be avoided while building prototypes to allow energy to be focused on building features. The value of CI/CD increases as the complexity of the project goes up.
• Testing is important to make CI or CD successful, but it comes with an increased investment in terms of the time, effort, and money involved. Without effective testing, software quality will suffer, so it is a balancing act: CI/CD practices must evolve as the complexity of the project changes.
• Choosing the right set of tools and services in a CI/CD pipeline will lead to a quantum leap in software quality. For example, using a tool like Uffizzi, developers can effortlessly create preview environments for each pull request, allowing them to showcase code changes before integrating them into the software.

The principle behind DevOps practices is to automate any process that can be automated and focus on the essentials. Using ephemeral environments takes CI/CD one step further than most teams currently practice, enabling them to preview code changes in live environments and make quicker decisions. This gives teams more time to focus on what truly matters: developing innovative and exciting features that will push the boundaries of what your software can do.

‍

Summary of key concepts

The following are the most important concepts discussed in this article:

‍

• Continuous integration is the practice of regularly integrating code changes into a shared codebase, which is then built and tested. This helps capture issues early in development.
• Continuous deployment is the practice of regularly deploying features, improvements, and bugfixes to a production environment. This helps teams deliver software quickly and gain immediate feedback, helping them improve software faster.
• Automation: CI/CD makes use of a rich set of automation tools, from building code and testing to deploying builds to a production environment. This reduces the time and effort needed to deliver software.
• Ephemeral environments: These are temporary, isolated environments that can be effortlessly created and disposed of after use. They are helpful in previewing code changes before merging them with the main code branch.
• ‍CI/CD pipeline: This pipeline is a series of stages that code changes pass through before they get deployed. Whenever code changes are unable to pass through a stage, notifications are sent out through messaging channels like Slack to help developers respond to the issue.