# What is CI/CD? Setting it up for Lovable

Source: https://www.plutonapps.com/resources/what-is-ci-cd

Published 2026-09-30, updated 2026-10-24, sources checked 2026-10-24. By Irfan Habib (https://www.plutonapps.com/authors/irfan-habib).

**CI/CD:** CI/CD, short for continuous integration and continuous delivery or deployment, is the automated pipeline that builds and tests every change to an app, then releases each change that passes, either at the push of a button or automatically. It makes releasing routine instead of risky.

Also known as: Continuous integration, Continuous delivery, Continuous deployment, CI/CD pipeline.

The pipeline between "it works on my machine" and "it is live". Here is what each letter means.

## What does a CI/CD pipeline change about releasing an app?

In a prototype, publishing is a button and nothing checks what it publishes. With real users, every release is a chance to break something that worked yesterday. A CI/CD pipeline makes each release boring: the same build, the same tests and the same steps, every time, with a record of what shipped when.

| Stage | What happens | What it catches |
| --- | --- | --- |
| Continuous integration | Build and run the tests on every change | Broken code before it merges |
| Continuous delivery | Package and release to staging, ready for production | Problems in a production-like setting |
| Continuous deployment | Release to production automatically when checks pass | Nothing extra; it removes the wait |

## What practices make continuous integration work?

Continuous integration works when changes are small, merged often and checked automatically. Martin Fowler's description asks everyone to push to the shared mainline at least daily, has every push trigger a build that runs the tests, and treats a broken build as the team's first priority, often fixed by reverting the faulty commit.

- Everything needed to build and run the app lives in version control.
- One command builds the app and runs the whole test suite.
- The build stays fast, roughly ten minutes, so feedback arrives while the change is fresh.
- Unfinished work is hidden behind [feature flags](https://www.plutonapps.com/resources/what-is-a-feature-flag) rather than kept on long-lived branches.
- Tests run in an environment that mirrors production, such as a [staging environment](https://www.plutonapps.com/resources/what-is-a-staging-environment).

## How do you add CI/CD to an app built in Lovable?

Start from the GitHub repository Lovable syncs to. Lovable's integration is two-way: its edits are pushed to the active branch, and commits pushed to that branch flow back into the editor. A pipeline can then run on every push, for example with GitHub Actions, whose workflows are YAML files stored in the repository's .github/workflows folder.

1. **Connect the repository** Turn on Lovable's GitHub integration so every version lands as a commit you can build and test.
2. **Add a workflow** A GitHub Actions workflow starts on an event, such as a push or a pull request, and runs jobs on a runner that installs, type-checks, tests and builds the app.
3. **Gate the release** Deploy to staging when the checks pass, and promote to production only from there, including any [schema migrations](https://www.plutonapps.com/resources/what-is-a-schema-migration).

A common mistake is a pipeline with no tests in it: it builds and deploys, so it looks like CI/CD, but nothing stops a broken change. The value is in the checks, not the automation. Our [production readiness check](https://www.plutonapps.com/tools/production-readiness-check) asks whether your app has them.

## How often should an app be deployed?

How often to deploy is a business choice. Our Starter plan includes two production deployments a week; Growth includes continuous deployment; see [pricing](https://www.plutonapps.com/pricing). Either way, every release goes through the same pipeline, so the build, the tests and the steps are the same every time.

> **What we see in practice** On [Looph](https://www.plutonapps.com/work/looph), 10,387 automated tests pass in CI before anything ships.

## Frequently asked questions

### What is the difference between continuous delivery and continuous deployment?

With continuous delivery, every change that passes the pipeline is ready to release, and a person decides when to press the button. With continuous deployment, it goes to production automatically once the checks pass. Both run the same builds and tests; only the final release step differs.

### Is GitHub Actions a CI/CD tool?

Yes. GitHub Actions runs workflows, defined in YAML files in a repository's .github/workflows folder, when events such as a push or a pull request happen. Each workflow runs jobs on runners, which GitHub provides for Linux, Windows and macOS, or which you can host yourself.

### How long should a CI build take?

Martin Fowler's guide to continuous integration suggests aiming for around ten minutes, so developers learn about a failure while the change is still fresh in their minds. A slow build means people push less often, so keeping it quick matters as much as keeping it green.

### How do you measure a CI/CD pipeline?

DORA's research uses five software delivery metrics. DORA groups them as throughput (change lead time, deployment frequency, failed deployment recovery time) and instability (change fail rate, deployment rework rate). Tracking both groups together shows whether shipping faster is costing the app its stability, not speed alone.

## Read next

- [The Looph case study: 10,387 tests passing in CI](https://www.plutonapps.com/work/looph)
- [Deployments included in each plan](https://www.plutonapps.com/pricing)

## Sources

- [Martin Fowler: Continuous Integration](https://martinfowler.com/articles/continuousIntegration.html)
- [DORA: software delivery performance metrics](https://dora.dev/guides/dora-metrics/)
- [GitHub Docs: Understanding GitHub Actions](https://docs.github.com/en/actions/about-github-actions/understanding-github-actions)
- [Lovable documentation: GitHub integration](https://docs.lovable.dev/integrations/github)