CI/CD overview

CI/CD is an acronym for Continuous Integration and Continuous Delivery. Also referred to as CI/CD pipeline, it is a common term in the world of DevOps.

DevOps is another acronym of sorts that stands for Development and Operations, a combination of software development (typically encompassing planning, building, coding, and testing) and operations (including software releases, deployment, and status monitoring).

What is CI/CD?

CI/CD describes the set of tools and practices that allow development teams to automate the process of building, testing, and deploying code. Automating testing and deployment enables developers to find and address defects earlier in the development process; therefore, software applications can be delivered more quickly.

From your first tiny commit to deploying your code to production, your code passes through various validation steps, some or all of which are performed automatically. This is the deployment pipeline in action.

Continuous Integration

To break it down further, Continuous Integration refers to the building and testing side of the process, and can include things like the following:

  • integrating code commits into your main repository branch
  • automatically running static (linting), unit, integration, regression, or acceptance tests on each commit; these are typically configured using a provider.
  • automatically kicking off builds after code is successfully merged

An underlying philosophy of Continuous Integration is that by merging, testing, and validating code frequently, you can identify defects, conflicts, and other issues more quickly and fix them more easily.


CI providers are tools for automating the code changes that are part of your pipeline. CI/CD processes are set up at the repository level, and since these setups are specific to each provider, yours will be slightly different depending on which one you choose.

Some popular providers are as follows:

Continuous Delivery

Continuous Delivery refers to the deployment side of the process, and can include things like the following:

  • automatically provisioning infrastructure; for example, user provisioning (granting users permissions to services or applications) or service provisioning (setting up credentials and system privileges)
  • manually deploying code to testing or production environments
  • automatically deploying code to testing or production environments (also referred to as continuous deployment)
  • leveraging feature toggles for code not yet slated for release to production

An underlying philosophy of Continuous Delivery is that once code is tested as part of the CI process, your code can be packaged with everything it needs and released to production at any time β€” so everything should be in order and ready to go at a moment's notice.


Ready to learn how we do CI/CD on the next-generation Slack platform? Read on!

✨ Just want to write some unit tests? Refer to Testing custom functions.

Have 2 minutes to provide some feedback?

We'd love to hear about your experience building modular Slack apps. Please complete our short survey so we can use your feedback to improve.