What is CI/CD? (why your site updates itself after a push)

What it actually is

CI/CD is two automated stages chained together, and both run without you touching anything after the initial push. CI (continuous integration) is the checkpoint: every time new code lands, a machine builds it and runs whatever tests exist, checking that nothing is obviously broken. CD (continuous deployment, sometimes continuous delivery) is what happens next: if that checkpoint passes, the new version gets published automatically, no one has to copy files to a server or click a “go live” button.

Think of a restaurant expediter. Every plate that leaves the kitchen gets checked before it goes out, wrong order, cold food, missing side, and if it fails that check it goes back, not to the table. If it passes, it goes straight out on its own, no one manually walks each plate over one by one. CI is the check. CD is the plate walking itself to the table.

Why your AI just did this

When you tell your agent “push this” or “ship it,” it runs git push, and from that point on CI/CD is your hosting platform’s job, not the agent’s. If your project is connected to Vercel or Netlify through GitHub, that push alone triggers the whole pipeline: pull the new commit, run npm run build (this is the CI step, it’s where TypeScript errors or missing imports get caught), and if that succeeds, publish it.

That’s also why an agent sometimes says “let’s wait for the build to finish” instead of immediately confirming your change is live, it’s waiting on the CI step to pass before CD can do anything. And it’s why a push to a branch (or a pull request) gets a preview link while a push to main updates your actual live site: same pipeline, different destination depending on which branch triggered it.

When you’ll run into it

• You push to GitHub, wait a couple of minutes, and your live site actually reflects the change, that’s CD finishing, not magic and not you forgetting you’d already deployed.
• A red X next to your commit on GitHub, or “Build failed” in the Vercel/Netlify dashboard, means CI caught a real problem and refused to let it ship.
• A bot comment on your pull request with a preview URL, that’s a preview deployment for that branch, not your production site. Merging the PR into main is what triggers the production deploy.
• Your agent says “checking deployment status” or “the build is still running”, it’s watching the pipeline, not inventing a delay.
• An email or dashboard notification saying “This deployment has failed” a few minutes after you expected your change to be live.

What to check

• Read the actual build log in your host’s dashboard (or the GitHub Actions tab if you’re using that), not just the pass/fail badge, the real error is almost always right there
• Confirm whether you’re looking at a preview deployment (from a branch or PR) or the production deployment (from main), they get different URLs and only one of them is what visitors see
• If nothing changed after a few minutes, check whether the build actually failed silently, don’t assume it’s just slow
• Any environment variable the build needs is set on the hosting platform itself, not only in your local .env, a missing one fails the build the same way every single time
• Whether your setup deploys main straight to production automatically, or requires a manual promote/approve step, teams differ on this and it changes what “push to deploy” actually means for you

Say it like a dev

Instead of: “did it upload yet” Say: “did the deployment finish, or is the build still running”

Instead of: “it says failed and I don’t know why” Say: “can you check the build log and tell me which step failed”

Instead of: “make my changes go live” Say: “push to main so CI/CD picks it up and deploys to production”