Your First CI Pipeline: From Git Push to Deployed

A CI pipeline takes every change your team pushes and puts it through the same gauntlet: check out the code, lint and format it, run the tests, build the artifact, and deploy it somewhere real. That sameness is the entire value. Without it, "works on my machine" ships to production on a Friday. With it, broken code fails loudly in minutes, on a machine nobody has to babysit. This guide builds your first pipeline from nothing, explains each stage, and ends with a staged rollout you can trust.

The principle is boring on purpose. Computers repeat procedures perfectly. Humans do not, especially under deadline. Every manual step in your path to production, the forgotten test run, the skipped lint, the deploy from a dirty working tree, is a future incident with a date still to be determined. CI moves those steps into a machine that never skips.

Here is where we are going:

1. What CI actually guarantees

2. The five stages in order

3. A minimal working pipeline

4. Caching so it stays fast

5. Secrets in CI without leaking them

6. First green build, then what to add second

7. Where the pipeline leads

What CI Actually Guarantees

Strip away the vendor marketing and continuous integration promises exactly one thing: every change is built and tested the same way, automatically, before it can advance. Not most changes, not changes on good days. Every push, every pull request, the same stages, the same environment, no exceptions for seniority or urgency.

Notice what that guarantee buys. It buys a shared definition of done that does not depend on memory: green pipeline means tested, and tested means reviewable. It buys bisectability: when main breaks, the culprit is one of a small set of recent green-checked changes, not "something someone did last week." And it buys speed paradoxically, because the team stops hand-verifying what the machine already proved and reserves human attention for design and edge cases.

It does not buy correctness by itself. A pipeline that runs no meaningful tests green-lights garbage at machine speed. The value lives in the stages you put in, which is why the next section matters more than any tool choice. Jenkins, GitLab CI, GitHub Actions, or a shell script on a spare server: pick whatever your team already pays for. The stages are identical everywhere, and stages are the skill that transfers.

The Five Stages in Order

Every pipeline, from side project to enterprise, runs the same five stages in the same order. Learn them once and you can read anyone's config on day one.

First, checkout. The runner grabs the exact commit being tested onto a clean machine. Clean matters: leftover files from previous runs are a classic source of works-here-fails-there mysteries, so each run starts fresh.

Second, lint and format checks. Fast, cheap, and oddly clarifying: style violations often correlate with careless logic, and a formatter ends bike-shedding forever. These run first because they fail in seconds, before you spend minutes on tests.

Third, the test suite. Unit tests, then integration tests, in that order, because fast feedback beats thorough feedback when both eventually run. The suite must be deterministic: a test that fails randomly trains everyone to re-run instead of investigate, which rots the whole system. Flaky tests get quarantined or fixed, never tolerated.

Fourth, build the artifact. Compile, bundle, containerize, whatever your deployable unit is, from the exact commit that passed tests. The artifact, not a fresh checkout, is what gets deployed onward. This closes the gap where "tested code" and "shipped code" quietly differ.

Fifth, deploy to staging automatically, and gate production behind approval. Staging proves the artifact runs in a production-like environment. Production waits for a human decision, ideally one click, after staging looks right. This split is the whole safety model: automation handles repetition, humans handle judgment.

A Minimal Working Pipeline

Theory sticks better with something runnable, so here is the smallest pipeline worth having, in the shape every major CI system recognizes: named jobs that run on each push, each job a short list of commands.

stages: [lint, test, build, deploy]

lint:
  stage: lint
  script:
    - npm run format:check
    - npm run lint

test:
  stage: test
  script:
    - npm test

build:
  stage: build
  script:
    - npm run build

deploy_staging:
  stage: deploy
  script:
    - ./scripts/deploy.sh staging
  environment: staging

Read it as the five stages made concrete, minus checkout, which the platform provides. Each job states its stage, stages run in dependency order, and later jobs wait for earlier ones to pass. A lint failure stops everything in seconds instead of burning twenty minutes of tests on code with a missing semicolon. Translate the commands to your stack and this runs almost anywhere: the nouns change, the verbs never do.

Start here and resist gold-plating. No matrix builds across twelve versions yet, no fancy caching, no deployment windows. A simple pipeline that runs on every push beats an ambitious one that exists only in a design doc. Complexity earns its place after the basics prove themselves, and the basics prove themselves within a week.

Caching So It Stays Fast

The number one killer of CI adoption is slowness. A suite that takes forty minutes teaches developers to push less often and batch bigger changes, which is exactly backwards. Speed is a feature of the pipeline, so engineer it from the start.

Cache dependencies first, since downloading the internet on every run is usually the biggest single cost. Cache keys should include the lockfile, so dependency changes invalidate correctly and everything else reuses. Measure before optimizing: most platforms show per-step timing, and the slowest step is the only one worth touching.

Parallelize what is independent. Lint while tests run. Split the suite across workers once it passes ten minutes. None of this requires cleverness, just noticing that sequential habits from local development do not apply to machines that run jobs concurrently for free.

Set a budget and defend it. Ten minutes end to end is a reasonable ceiling for most projects, and anything slower deserves a ticket, not acceptance. Fast pipelines get used on every push. Slow ones get bypassed with direct pushes to main, and then you have the worst of both worlds: the process overhead with none of the safety.

Secrets in CI Without Leaking Them

Pipelines need credentials to deploy, and credentials in pipeline logs are leaks waiting for an audience. Treat CI secrets with the full discipline from the secrets guide: platform secret stores, never hardcoded values, minimal scopes, and rotation on schedule.

Three rules cover nearly everything. First, secrets live in the CI platform's secret store and enter jobs as environment variables at runtime. Nothing sensitive sits in the pipeline definition, which is just code in your repo that everyone can read. Second, mask them in logs. Every major platform redacts stored secrets from output automatically, but only if the value came from the store. Echoing a secret you pasted inline bypasses the masking completely, so never inline them, even temporarily. Third, scope deployment keys to the environment they deploy: staging keys deploy staging, production keys deploy production, and the two never mix. A compromised staging token should be embarrassing, not catastrophic.

Audit who can see and change pipeline secrets quarterly, alongside code access. CI permissions quietly accumulate until half the company can read production credentials from a debug log. Least privilege applies to automation exactly as it applies to people.

First Green Build, Then What to Add Second

Ship the minimal pipeline this week and celebrate the first green build, because the habit matters more than the coverage. Then grow it in this order, one addition at a time.

Preview environments come first: every pull request gets its own disposable deployment with a link in the review. Reviewers stop imagining the change and start clicking it, which catches the bugs tests miss. Next, branch protection: main refuses merges without green checks and at least one human review, which closes the bypass loophole permanently. Then staged production rollouts: deploy to a slice, watch the metrics, expand automatically on green, halt on red. Each addition builds on the trust the previous one earned.

Resist the enterprise catalog until you feel real pain: complex matrices, manual approval chains for every environment, deployment calendars. Most teams need those never. What they need is the boring loop running on every push, getting slightly better each quarter.

Where the Pipeline Leads

A working pipeline changes what the team dares to attempt. Small releases become cheap, so batch sizes shrink. Reverts become safe, so experimentation rises. The deploy playbook assumes exactly this foundation: health checks, feature flags, and one-command rollbacks all plug into stages this pipeline already runs. And when something escapes anyway, the runbooks and the outage playbook catch it, fed by logs from builds that all look the same.

That sameness is the quiet superpower. Incident review gets easier when every deploy went through identical stages. Onboarding gets easier when the path to production is written down instead of tribal. Audits get easier when the evidence generates itself. Start with one pipeline, one repo, this week. Green builds compound like interest, and the team that ships boringly is the team that sleeps well.

Featured image: title card generated for this post.