Continuous Integration vs Continuous Delivery vs Continuous Deployment

The content here is under the Attribution 4.0 International (CC BY 4.0) license

For a long time I wanted to have a place for me to go for when my questions arrive in my heade regarding continuous integration, continuous delivery and more recently continuous deployment. As the software development industry evolved, the adoption of agile practices became wide spread and new ones emerged. The context that follows is a collection of my thoughts on what I have been able to collect for myself and share that with you, if you prefer a shorter version:

Part I

In this part we will go over a few aspects that I believe are important to understand before diving into the differences between Continuous Integration, Continuous Delivery, and Continuous Deployment. Those will help to contextualize the practices and the evolution of the software development industry.

Software configuration at the hard of it

The software development industry has evolved significantly over the past few decades, with a strong focus on automation, collaboration, and continuous improvement. At the heart of this evolution lies the concept of software configuration management, which plays a crucial role in ensuring that software systems are built, tested, and deployed in a consistent and reliable manner. This happens through the use of version control systems, and use it for everything: source code, infrastructure code and for template management.

Introduction

Continuous practices, i.e., continuous integration (CI), delivery (CDE), and deployment (CD), are the software development industry practices that enable organizations to frequently and reliably release new features and products (Shahin et al., 2017). While they’re all part of a broader software life cycle philosophy, understanding the nuances between them is important for building an agile development process. Today, we’re breaking down the differences between the many “continuous out there”. However, before we start I would like to contextualize the practices that compose the DevOps philosophy.

Automation is at the heart of the DevOps philosophy, serving as the foundation for achieving speed, consistency, and reliability in software delivery. By automating repetitive tasks such as building, testing, and deploying code, teams can eliminate manual errors, reduce bottlenecks, and accelerate feedback loops. This not only frees up developers to focus on value work but also ensures that processes are repeatable and scalable as the organization grows. Automation enables rapid iteration and provides the confidence needed to release changes frequently, it also breaking down silos, fostering collaboration, and delivering value to users quickly and safely in a modern DevOps environment (this comes explained in the DevOps Culture and Mindset - Coursera).

---
title: Evolution of CI/CD through Key Books
---

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#c2f0f7', 'edgeLabelBackground':'#ffffff'}}}%%
timeline
    title Evolution of CI/CD through Key Books

    2006 : Continuous Integration — CI concepts and practices
    2010 : Continuous Delivery — CDE principles and pipelines
    2013 : The Phoenix Project — DevOps culture, CI/CD in narrative
    2016 : The DevOps Handbook — DevOps, CI, CD, deployment
    2018 : Accelerate — Research on CI/CD & DevOps
    2021 : Modern Continuous Delivery — Cloud-native CD & deployment

In the following sections we will dive into each one of them.

Continuous Integration

Before we dive into the delivery and deployment aspects, let’s acknowledge that Continuous Integration (CI) is the bedrock. CI involves frequently merging code changes from multiple developers into a central repository. Automated builds and tests are triggered with each merge, ensuring early detection of integration issues. Despite using a book from 2006 to reference the CI mark (Duvall et al., 2006), in eXtreme Program the concept was already used in 1999 (Beck, 1999).

A team without CI often works in long-lived feature branches. Developers might go days or even weeks without integrating their changes. When it’s finally time to merge, they face a painful and time-consuming integration process, with conflicts and unexpected bugs surfacing late in the cycle. In fact, those teams do not perceive this as a problem in the flow, it is perceived just as “part of the work”. Testing is often manual or ad hoc, so issues may go unnoticed until late in development or even after release. This leads to stressful “integration hell,” delayed releases, and a lack of confidence in the codebase. In non-extreme cases, it also is the cause that teams decide to create deployment windows, which are often a source of stress.

In contrast, a team embracing CI merges their work into the main branch multiple times a day. Each integration triggers automated builds and a suite of tests, providing immediate feedback. Integration issues are caught early, while changes are still fresh in developers’ minds and easier to fix, automation is the key (Martin Fowler, 2012). The team spends less time resolving conflicts and more time delivering value. Releases become routine, not risky events, and the team can respond quickly to new requirements or bug reports.

CI stops and CDE kicks in after the code has been integrated, built, and tested automatically. CI focuses on frequently merging code changes into a shared repository and running automated builds and tests to catch integration issues early. Once the code passes these automated checks, Continuous Delivery takes over by automating the process of preparing the code for release to production.

Continuous Delivery

Continuous Delivery takes the concept of CI a step further. It’s about automating the entire process of getting your code ready for release to production. Here’s what that typically involves:

• Automated Builds (Same as CI)
• Automated Testing: Unit tests, integration tests, performance tests – everything is automated (Same as CI)
• Release Artifact Creation: Packages (Docker images, WAR files, etc.) are automatically built and stored
• Approval Gates (Often Manual): A human decision is still required before deploying to production. The code is ready but someone needs to explicitly trigger the deployment

Continuous Delivery is a practice that involves automating the entire process of getting code ready for release to production. This includes automated builds, automated testing, and release artifact creation, as well as approval gates where a human decision is required before deploying to production.

The foundation of Continuous Delivery is Configuration Management. This involves managing all configurations needed for an application, including dependencies, which are essential for writing software that interacts with the outside world (Humble & Farley, 2010).

The deployment pipeline is a key aspect of CDE, as it enables organizations to automate the process of getting software from version control into production. The pipeline involves a series of steps, including unit testing, integration testing, and acceptance testing, which help ensure that the software meets the required quality standards before deployment.

However, adopting CDE in a traditional team requires a cultural shift and a structured approach, CI and CDE in my experiece have a blurried line in professional projects, some teams might state they are usng CI when it is CDE and others the opposite. Here are some steps to help your team transition to CD:

1. Start with the basics: Educate your team on the principles of CD, including automated builds, automated testing, and release artifact creation. You can use the resources provided by Jez Humble and David Farley (2010) as a starting point.
2. Identify the stakeholders: Determine who will be impacted by the adoption of CD in your organization. This may include developers, testers, product managers, and IT operations teams. Involve these stakeholders in the planning process to ensure their buy-in and support.
3. Assess the current state: Evaluate your team’s current processes, tools, and culture. Identify areas that need improvement and opportunities for automation. Use this assessment to create a plan for implementing CD.
4. Establish a pilot project: Choose a small project or feature to serve as a pilot for CD implementation. This will allow your team to test the waters, learn from mistakes, and refine their processes before scaling up to larger projects.
5. Develop a deployment pipeline: Create a deployment pipeline that includes automated builds, automated testing, and release artifact creation. Use tools like Jenkins, Travis CI, or GitLab CI to automate the build and testing process.
6. Implement continuous integration: Set up a continuous integration flow that integrates with your version control system. This will allow developers to commit code changes and have them automatically built, tested, and deployed to a staging environment.
7. Train and support team members: Provide training and support for team members on the new CD processes and tools. This may include workshops, online courses, or one-on-one mentoring.
8. Monitor progress and feedback: Continuously monitor your team’s progress and gather feedback from stakeholders. Use this information to refine your processes and make adjustments as needed.

Go through each step and honestly assess whether it is fully, partially, or not yet implemented in your team, using a spreadsheet or a simple table can help you track your progress. This will help you identify areas that need improvement and opportunities for automation. Remember that adopting CDE is a journey, not a destination, and it requires continuous improvement and adaptation to changing circumstances.

Continuous Deployment

While CDE ensures that your software is always in a deployable state and ready for release at any time, CD takes this concept a step further. In CD, every change that passes the automated tests is automatically deployed to production, there are no manual approval gates. This represents the highest level of automation in the software delivery lifecycle.

The motivation for adopting CD is based on the desire for agility, and rapid feedback. In today’s fast-paced digital landscape, businesses need to respond quickly to market changes, customer feedback, and emerging opportunities. By automating the final step of deployment, organizations can deliver new features, bug fixes, and improvements to users almost instantly, reducing time-to-market. Adopting CD requires to take a few important steps beyond what you have in place:

Strengthen Automated Testing: Ensure your automated test suite is comprehensive, fast, and reliable. This includes unit, integration, end-to-end, and performance tests. Your tests must catch issues before code reaches production, since there will be no manual approval step.

• Automate Production Deployment: Remove manual approval gates so that every change that passes all automated checks is deployed directly to production. This requires confidence in your pipeline and tooling - Trunk-Based development comes in.
• Monitoring and Alerting: Set up real-time monitoring, logging, and alerting for your production environment. You need to detect issues quickly after deployment and respond immediately. This is were the DevOps Culture and Mindset comes into play, using business metrics, Service Level Objectives (SLO), and Service Level Indicators (SLI) together with the 4 key metrics to measure the impact of changes (Forsgren et al., 2018)
• Rollback and Recovery Mechanisms: Make sure you can quickly roll back or disable problematic changes (e.g., with automated rollbacks or feature flags) if something goes wrong in production. Changes in the database are the most complex to handle, so plan for that, Migrating to microservices databases suggests a strategy to handle that and keep it in a compatible version at all times
• Adopt Feature Toggles: to control the exposure of new features, allowing you to deploy code safely and enable or disable features without redeploying.
• Foster a Culture of Ownership and Rapid Response: Your team should be ready to respond to incidents at any time, with clear on-call rotations and a blameless postmortem culture.

At least for me, CD seems a golden standard, but it’s not without its challenges. It requires a high level of confidence and ownership at a team level and commitment to the companies goals. Which in my experience is not easy to achieve, especially in organizations with a history of manual deployment processes and fear of change and brealing production. However, developers in a team practicing CD, should expect:

• Immediate from production monitoring, allowing them to catch and fix issues quickly.
• High Code Standards there is a strong emphasis on comprehensive, reliable, and fast automated tests (unit, integration, end-to-end, performance).
• Developers are expected to take ownership of their code in production, respond to incidents, and participate in on-call rotations or rapid response when issues arise.
• Collaboration with quality assurance, operations, and development work closely together, often as a single cross-functional team.
• There is a culture of blameless postmortems and continuous improvement, where failures are seen as learning opportunities.

If you are not willing to take responsibility in CD environment, you may find the experience challenging and even uncomfortable. CD fundamentally relies on a culture of ownership, where developers are accountable not just for writing code, but for its behavior and impact in production. Without this sense of responsibility, the benefits of CD is difficult to realize. Teams that lack ownership may struggle with unresolved incidents, slow responses to production issues, and a lack of trust in the deployment process. If you or your team are not ready to take on this level of accountability, it may be better to focus on strengthening your practices and culture before adopting CD.

Part II

When to Choose Which Approach?

CI is the foundation of modern software delivery. It focuses on frequently merging code changes into a shared repository, where automated builds and tests are triggered with every integration. The primary goal of CI is to catch integration issues early, reduce merge conflicts, and ensure that the codebase is always in a healthy state.

CDE builds on the practices of CI by automating the entire process of getting code ready for release to production. This includes automated builds, comprehensive automated testing, and the creation of release artifacts. The key distinction is that, with CDE, the code is always in a deployable state, but a human decision is still required before deploying to production.

CD takes automation to its highest level. Every change that passes all automated tests is deployed directly to production, with no manual approval gates. This approach is ideal for mature teams with robust automated testing, monitoring, and rollback capabilities. CD enables rapid feedback, faster delivery of value to users, and the ability to respond quickly to market changes. However, it also demands a high level of confidence in your pipeline, a strong culture of ownership, and a willingness to take responsibility for production outcomes.

flowchart TD
    A[Code Commit] --> B[Continuous Integration]
    B -->|Automated Build & Test| C[Build/Test Passed?]
    C -- No --> D[Fix Issues & Recommit]
    D --> B
    C -- Yes --> E[Continuous Delivery]
    E -->|Automated Staging/Pre-prod Deployment| F[Manual Approval?]
    F -- Yes --> G[Human Triggers Production Release]
    F -- No --> H[Continuous Deployment]
    H -->|Auto Deploy to Production| I[Production Release]

    %% Visual boundaries
    subgraph CI [Continuous Integration]
        B
        C
        D
    end

    subgraph CDE [Continuous Delivery]
        E
        F
        G
    end

    subgraph CD [Continuous Deployment]
        H
        I
    end

In short:

• Choose CI if you’re starting your automation journey and want to improve code quality and team collaboration
• Choose CDE if you want to automate releases but still need manual control over production deployments
• CD is ideal for mature teams with robust automated testing, monitoring, and rollback capabilities

Part III

My empirical journey in professional projects

For a few years now (since 2015) I have been practicing Continuous Integration, Continuous Delivery, and Continuous Deployment, the latest being the one that I have been practicing the most in the last 4 years. I have seen teams struggle with the transition from manual deployments to automated ones, and I have also seen teams that have embraced the culture of ownership and responsibility that comes with CD. In my experience, the key to success in adopting CD is to have a strong culture of ownership, where developers take responsibility for their code in production and are willing to respond to incidents quickly. This requires a high level of confidence in the pipeline and tooling, as well as a robust monitoring and alerting system to detect issues quickly after deployment.

It is time for the industry to start normalizing deploying at any time, and not just during a deployment window. This is where the DevOps culture and mindset come into play, as it allows teams to work together to deliver value to users. At the sime time, this is the part that block teams to adopt, mainly guided by fear. Organizations face hurdles such as lack of awareness, resistance to change, team dependencies, and integration with legacy systems (Shahin et al., 2017).

In my opinion, most of the problems that I mentioned comes from the lack of craftspeople that are proud of they work and are hands-on (Mancuso, 2014). Having people that buy-in the culture ease the integration of continuous learning and taking risks.

A practical example of a CI/CD pipeline

In this section I am showing an example of a CI/CD pipeline that I have used in a few projects, it is a simple pipeline that can be used as a starting point for your own projects, we will evolve the pipeline to match the different stages that we discussed, CI, CDE and CD.

The sample project

The sample project we will use is json-tool a open-source project that offers a set of tools for working with JSON data. I have shared this project in the past and the technical decisions I have made to make it a reality.

The tool is built on the open and uses GitHub infrastructure to run and deploy it. It started with a simple CI and today it evolved to a full CI/CD approach. Production for this project is considered to be the snapcraft platform, where the tool is available for download and installation.

The CI example

To fullfill the CI requirements, we will use GitHub Actions to run the tests and build the project, the following workflow is a simple example of a CI pipeline that runs on every push to the main branch, it installs the dependencies, runs the tests, and builds the project. It also uploads the build artifacts to GitHub for later use.

File on GitHub

name: Node CI

on:
  push:
    branches: main

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [16.x]
    steps:
      - uses: actions/checkout@v1
      - name: Use Node.js $
        uses: actions/setup-node@v1
        with:
          node-version: $
      - name: export display
        run: |
          /usr/bin/Xvfb :99 -screen 0 1024x768x24 > /dev/null 2>&1 &
          echo ">>> Started xvfb"
      - name: install
        run: npm install
      - name: test
        run: npm run test
        env:
          CI: true
          DISPLAY: ':99.0'
      - name: Run cypress (acceptance tests)
        uses: cypress-io/github-action@v2
        env:
          CYPRESS_BASE_URL: 'http://localhost:3000'
        with:
          wait-on: 'http://localhost:3000'
          start: npm start
      - name: package
        run: npm run package
        env:
          GH_TOKEN: $
        - name: distribute for linux 64
          uses: actions/upload-artifact@v2
          with:
            name: archive-electron-platform
            path: dist/json-tool-0.1.0.AppImage

This workflow is a simple example of a CI pipeline that runs on every push to the main branch, it installs the dependencies, runs the tests, builds the project, and packages it for distribution. It also uploads the build artifacts to GitHub for later use. This allows for a quick feedback loop, where developers can see if their changes are breaking the build or not. The workflow also uses Cypress to run acceptance tests, which are end-to-end tests that simulate user interactions with the application.

However, this workflow does not deploy the code to production, it only builds and tests it. This is where the team dynamics is important, in addition to the CI pipeline, the team needs to have a process in place to keep the code in a deployable state at all times. For example, avoid breaking changes, and ensure that the new functionalities are released under feature toggles so that they can be

The CDE example

As an iteration on the previous workflow the following one does the same, however, it requires a manual approval step before deploying to production. This is a common practice in CDE, where the code is always in a deployable state, but a human decision is still required before deploying to production.

name: Push snap

on:
  workflow_dispatch:
    inputs:
      version:
        description: 'Which version to publish to snapstore'
        required: true

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v1

      - name: Set Environment Variables
        uses: tw3lveparsecs/[email protected]
        with:
          envFilePath: ./envvars.for.actions

      - name: Use Node.js
        uses: actions/setup-node@v3
        with:
          node-version: $
          cache: 'npm'

      - name: install
        run: npm install 

      - name: lint
        run: npm run lint

      - name: build
        env:
          NODE_OPTIONS: --openssl-legacy-provider
        run: npm run build

      - name: package
        run: npm run package

      - name: publish snap
        uses: snapcore/action-publish@v1
        env:
          SNAPCRAFT_STORE_CREDENTIALS: $
        with:
          store_login: $
          snap: "dist/json-tool_$_amd64.snap"
          release: beta,candidate,stable

The workflow above is a simple example of a CDE pipeline that runs on every push to the main branch, it installs the dependencies, runs the tests, builds the project, and packages it for distribution. It also requires a manual approval step before deploying to production, which is a common practice in CDE. The approval step is done through the GitHub Actions UI, where a user can approve or reject the deployment to production. This allows for a controlled and reviewed deployment process, ensuring that the code is ready for production and meets the quality standards.

CD example

As the last iteration, this workflow, automatically deploys the code to production, once all previous steps are fullfilled.

name: Node CI

concurrency:
  group: ci-$-$
  cancel-in-progress: true

on:
  pull_request:
  workflow_dispatch:
  push:
    branches: main
  schedule:
    - cron: "0 0 * * *"

env:
  CI: true
  COVERALLS_REPO_TOKEN: $
  COVERALLS_GIT_BRANCH: main

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4
      - name: Set Environment Variables
        uses: tw3lveparsecs/[email protected]
        with:
          envFilePath: ./envvars.for.actions

      - name: Use Node.js
        uses: actions/setup-node@v3
        with:
          node-version: $

      - name: Attempt to restore the cache
        uses: actions/cache@v3
        id: cache
        with:
          path: |
            ./node_modules
            ~/.cache/Cypress
          key: $
          restore-keys: $

      - name: install
        if: steps.cache.outputs.cache-hit != 'true'
        run: npm install 

  test:
    runs-on: ubuntu-latest
    needs: [build]
    steps:
      - uses: actions/checkout@v4
      - name: Set Environment Variables
        uses: tw3lveparsecs/[email protected]
        with:
          envFilePath: ./envvars.for.actions

      - name: Use Node.js
        uses: actions/setup-node@v3
        with:
          node-version: $

      - name: Attempt to restore the cache
        uses: actions/cache@v3
        id: cache_restore
        with:
          fail-on-cache-miss: true
          path: |
            ./node_modules
            ~/.cache/Cypress
          key: $

      - name: coverage
        if: github.ref == 'refs/heads/main'
        run: npm run coverage

      - uses: actions/upload-artifact@v4
        if: github.ref == 'refs/heads/main'
        with:
          name: jest-lcov
          path: coverage/lcov.info

      - name: coverage (no coveralls)
        if: github.ref != 'refs/heads/main'
        run: npm run coverage

  acceptance:
    runs-on: ubuntu-latest
    needs: [build]
    steps:
      - uses: actions/checkout@v4
      - name: Set Environment Variables
        uses: tw3lveparsecs/[email protected]
        with:
          envFilePath: ./envvars.for.actions

      - name: Use Node.js
        uses: actions/setup-node@v3
        with:
          node-version: $

      - name: Attempt to restore the cache
        uses: actions/cache@v3
        id: cache_restore
        with:
          fail-on-cache-miss: true
          path: |
            ./node_modules
            ~/.cache/Cypress
          key: $

      - name: export display
        run: |
          /usr/bin/Xvfb :99 -screen 0 1024x768x24 > /dev/null 2>&1 &
          echo ">>> Started xvfb"
      - name: delete coverage folder
        run: rm -rf coverage/

      - name: lint
        run: npm run lint

      - name: build application
        run: npm run build

      - name: instrument application
        run: |
          npx nyc instrument src/ instrumented
          cp -R instrumented/ src/
          rm -rf instrumented

      - name: Run cypress (acceptance tests)
        uses: cypress-io/github-action@v6
        env:
          CYPRESS_INSTRUMENT_PRODUCTION: false
          DISABLE_ESLINT_PLUGIN: true
          CYPRESS_BASE_URL: 'http://localhost:3000'
          CYPRESS_RECORD_KEY: $
        with:
          record: true
          wait-on: 'http://localhost:3000'
          start: npm run start-instrumented
          browser: chrome
          headed: true
          install-command: npm install 
      - name: Generate lcov
        run: npx nyc report --reporter=lcov
      - uses: actions/upload-artifact@v4
        if: github.ref == 'refs/heads/main'
        with:
          name: cypress-lcov
          path: coverage/lcov.info

  coverage:
    if: github.ref == 'refs/heads/main'
    runs-on: ubuntu-latest
    needs: [build, test, acceptance]
    steps:
      - uses: actions/checkout@v4
      - name: Set Environment Variables
        uses: tw3lveparsecs/[email protected]
        with:
          envFilePath: ./envvars.for.actions

      - name: Use Node.js
        uses: actions/setup-node@v3
        with:
          node-version: $

      - name: Attempt to restore the cache
        uses: actions/cache@v3
        with:
          fail-on-cache-miss: true
          path: |
            ./node_modules
            ~/.cache/Cypress
          key: $
      
      - uses: actions/download-artifact@v4
        with:
          path: coverage/
          pattern: "*-lcov"
          merge-multiple: false
      - run: |
          mkdir merged_coverage
          mv coverage/cypress-lcov/lcov.info merged_coverage/cypress.info
          mv coverage/jest-lcov/lcov.info merged_coverage/jest.info
          ./node_modules/.bin/lcov-result-merger './merged_coverage/*' merged_coverage.info
          npm run coveralls
      - uses: actions/upload-artifact@v4
        with:
          name: merged-lcov
          path: merged_coverage.info

  delivery:
    runs-on: ubuntu-latest
    needs: [test, acceptance]
    if: github.ref == 'refs/heads/main' && contains(github.event.head_commit.message, 'tagged version')

    steps:
      - uses: actions/checkout@v4
      - name: Set Environment Variables
        uses: tw3lveparsecs/[email protected]
        with:
          envFilePath: ./envvars.for.actions

      - name: Use Node.js
        uses: actions/setup-node@v3
        with:
          node-version: $

      - name: Attempt to restore the cache
        uses: actions/cache@v3
        id: cache_restore
        with:
          fail-on-cache-miss: true
          path: |
            ./node_modules
            ~/.cache/Cypress
          key: $

      - name: package
        run: npm run package
        env:
          GH_TOKEN: $

      - name: fetch snap file
        id: snap_file
        run: echo "::set-output name=name::$(ls dist/*.snap | sed "s/dist\///g" | sed "s/\.snap//g")"

      - name: publish snap edge channel
        uses: snapcore/action-publish@v1
        env:
          SNAPCRAFT_STORE_CREDENTIALS: $
        with:
          store_login: $
          snap: "dist/$.snap"
          release: edge

This workflow is a simple example of a CD pipeline that runs on every push to the main branch, it installs the dependencies, runs the tests, builds the project, and packages it for distribution. It also automatically deploys the code to production, once all previous steps are fulfilled.

How complex can a pipeline be?

Among other questions, the size and complexity of pipelines depends on its context and what it is for, however, taking into example the example used here, the pipeline can expand beyond what has been shown, a few examples:

• Adding a step for mutation testing might be a good idea, to ensure that the tests are covering the code properly, this can be done using Stryker.
• Adding a step to check the code quality, this can be done using SonarQube or Code Climate.

Conlusion

Understanding the differences between Continuous Integration, Continuous Delivery, and Continuous Deployment is crucial for building a modern, resilient software delivery process. Each approach offers unique benefits and challenges, and the right choice depends on your team’s maturity, risk tolerance, and business needs. My professional experience has shown that while automation and tooling are essential, the real transformation happens when teams embrace a culture of ownership, collaboration, and continuous improvement.

As you consider which approach to adopt, remember that there is no silver bullet. Start by assessing your current practices, technical capabilities, and team culture. Invest in strengthening your automation, testing, and monitoring foundations before moving to more advanced stages like Continuous Deployment. Most importantly, foster an environment where developers feel empowered and accountable for the code they deliver to production.

Resources

• Continuous delivery vs. continuous deployment — Thoughtworks Technology Podcast

References

1. Shahin, M., Ali Babar, M., & Zhu, L. (2017). Continuous Integration, Delivery and Deployment: A Systematic Review on Approaches, Tools, Challenges and Practices. IEEE Access, 5, 3909–3943. https://doi.org/10.1109/ACCESS.2017.2685629
2. Duvall, P. M., Matyas, S., & Glover, A. (2006). Continuous Integration: Improving Software Quality and Reducing Risk. Addison-Wesley Professional.
3. Beck, K. (1999). Extreme Programming Explained: Embrace Change. Addison-Wesley Publishing Company.
4. Martin Fowler. (2012). Continuous Integration. http://www.martinfowler.com/articles/continuousIntegration.html
5. Humble, J., & Farley, D. (2010). Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley Professional.
6. Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. IT Revolution Press.
7. Mancuso, S. (2014). The software craftsman: professionalism, Pragmatism, Pride. Pearson Education.