What is CI/CD?

Without automation, deploying code looks like this: you finish a change, remember to run the tests (or not), zip the project, upload it and restart the app. Every step is a chance to forget something, and the person who knows the routine becomes a bottleneck.

CI/CD replaces that routine with a script that runs the same way on every change. It is standard practice in software teams, and it scales down well to a single developer with a bot or an API.

What does CI/CD stand for?#

CI/CD joins two ideas that are often mixed up:

• CI, continuous integration: developers merge their changes into a shared branch frequently, and each merge triggers an automatic build and test run. The goal is to find a broken change minutes after it is written, not weeks later.
• CD, continuous delivery or continuous deployment: the part after CI. The change that passed is packaged and moves on to production.

The "D" is where the confusion starts, because it means two different things.

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

Both automate everything up to the release. They differ in the last step:

Continuous deployment is not "better". It requires tests you trust, because nobody stops a bad change at the end. Many teams start with continuous delivery and a manual approval, then drop the approval once the tests have earned that trust.

How does a CI/CD pipeline work?#

A pipeline is the sequence of automated stages a change goes through. A typical one looks like this:

1. Trigger. An event starts the run: a push to a branch, a pull request, a published release, a schedule or a manual click.
2. Checkout. A clean machine gets a copy of the code at that commit.
3. Build. Dependencies are installed and the project is compiled or bundled.
4. Test. Unit tests, and sometimes linters, type checks and integration tests, run. If anything fails, the pipeline stops here.
5. Release. The result is sent to production, or to a staging environment first.
6. Verify. A smoke test or health check confirms the new version is alive.

The key point is that a failure stops the flow: a broken test means no deploy.

What does a CI/CD pipeline look like in practice?#

On GitHub, a workflow is a YAML file stored in .github/workflows/ in your repository. An event, such as a push, starts the workflow. It contains one or more jobs, and each job runs on a runner, the server that executes its steps. Jobs run in parallel by default, and needs makes one wait for another.

This workflow is the CI half for a Node.js project: it runs the tests on every push to main and every pull request.

name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: lts/*
      - run: npm ci
      - run: npm test

actions/checkout@v7 copies your code onto the runner (check the action's releases page for the current major version), and lts/* installs the active Node.js LTS. npm ci installs exactly what the lockfile says, which keeps CI reproducible. To turn this into CD, you add a second job with needs: test that sends the code to the server. The full version, with secrets and a deploy step, is in automatic deploys with GitHub Actions.

GitLab CI, CircleCI and Jenkins do the same job with different syntax, and the concepts above carry over.

Why do teams use CI/CD?#

• Fewer broken releases. Tests run on every change, including the ones you were sure were harmless.
• Smaller, safer changes. When deploying is cheap, you ship small pieces. A small change is easier to review and to undo.
• Repeatability. The pipeline does the same steps in the same order. "It works on my machine" matters less when a clean runner builds it.
• No single person holds the knowledge. The deploy procedure lives in a file in the repository, not in someone's head.
• Faster feedback. You learn about a failed build while the change is still fresh in your mind.

When is CI/CD not worth it?#

A pipeline has a cost too. It is code you have to maintain, secrets you have to protect, and a source of failures of its own (a flaky test blocks everyone).

• A solo hobby bot with no tests gains little from CI. A manual deploy takes a minute.
• Without tests, CI only proves the code compiles. Automatic deployment without tests simply ships bugs faster.
• A slow pipeline gets ignored. If the tests take 40 minutes, people stop waiting for them.

A reasonable path: start by running tests on pull requests (CI only), then add an automatic deploy to a staging environment, and only then automate the production deploy.

How do you roll back when a deploy goes wrong?#

CI/CD gets code to production fast, so you need a way back that is just as fast. The simplest is to redeploy the previous good commit. For apps with data, also keep copies of the data: code can be reverted, a corrupted database cannot. See rollbacks and zero-downtime deploys for the options.

How to do this on Square Cloud#

Square Cloud is self-service hosting, so you control the pipeline: your CI decides when something is ready, and the deploy step ships it. You can deploy from GitHub with the official GitHub Action, or call the open source CLI from any CI system. There it authenticates with the SQUARECLOUD_API_KEY variable instead of a browser login.

The official GitHub Action, squarecloudofc/github-action@v2, runs the CLI command in its command input, for example commit <appId> --restart, on every push, release or manual run. It only needs an API key, stored as a secret in your repository and passed in the token input. Put your tests in a job before it and use needs: a failing test stops the deploy.

Environment variables are set per application in the dashboard, API, CLI or VS Code, and a change applies on the next restart without a rebuild, so you do not have to put them in the pipeline. The squarecloud.app configuration file is optional: the dashboard generates it on deploy, or you can write it at the project root.

See the GitHub Action page for the setup.