CI/CD pipelines

Key takeaways CI (continuous integration) automatically builds and tests every change so the code is always working. CD (continuous delivery) automatically packages and releases changes that pass. Together they run as a pipeline triggered by pushes and tags. GopherTrunk uses GitHub Actions: every PR is built, vetted, and tested, and a version tag builds and publishes release artifacts.

Doing build-test-release by hand every time is slow and error-prone. CI/CD automates it, so shipping is reliable and boring — exactly what you want.

CI: keep the code always working

Continuous integration runs your checks automatically on every change. Push a branch or open a pull request and a fresh machine builds the code and runs the tests — no “it passed on my machine,” because it’s an independent, identical run every time. (The Git module introduces GitHub Actions, the service GopherTrunk uses.)

GopherTrunk’s CI runs on every pull request and does the same gate a developer runs locally, plus more:

# from GopherTrunk's CI workflow
- run: go vet ./...
- name: gofmt
  run: |
    unformatted=$(gofmt -l .)
    if [ -n "$unformatted" ]; then exit 1; fi
- run: go build ./...
- run: go test -race -count=1 ./...
- run: make integration

Vet, formatting, build, race-tested unit tests, and integration tests — all automatically, on every change, before it can merge. It even runs the USB backends on Windows and macOS runners so cross-platform code can’t quietly break.

CD: automate the release

Continuous delivery extends the pipeline past testing into shipping. When GopherTrunk gets a version tag, a separate release pipeline runs:

on:
  push:
    tags:
      - "v*.*.*"        # e.g. v1.4.2
  workflow_dispatch:     # or trigger manually

That release job builds artifacts for every platform (Linux, macOS, Windows — all CGO_ENABLED=0 pure-Go builds), stamps in the version from the tag, generates SHA256SUMS checksums, and uploads everything to a GitHub Release. Tag v1.4.2, and minutes later the downloadable binaries and installer exist — no manual build steps to forget.

The shape of a pipeline

A pipeline: an event triggers build and checks; only if the gate passes are artifacts published.

Why it matters

CI/CD turns shipping from a careful manual ritual into an automatic, repeatable process. The tests always run, the artifacts are always built the same way, and a bad change is caught before it reaches users. It’s the automation layer that ties together everything in this module — artifacts, images, and versioning — into a hands-off flow.

Quick check: what does the CI half of CI/CD do?

Recap

CI automatically builds and tests every change; CD automatically packages and releases what passes.
A pipeline is triggered by events (push, tag) and runs the same steps every time.
GopherTrunk’s CI gates PRs on vet, gofmt, build, race tests, and integration tests; a version tag builds and publishes release artifacts with checksums.
CI/CD makes shipping reliable and repeatable.

Next up: where to actually run your deployment — cloud and VPS options.

Frequently asked questions

What is the difference between CI and CD?

Continuous integration (CI) automatically builds and tests every change as it’s pushed, catching problems early. Continuous delivery/deployment (CD) takes a change that passed CI and automatically packages and releases it — to a registry, a release page, or straight to production. CI keeps the code always-working; CD makes shipping it automatic.

What is a CI/CD pipeline?

A pipeline is an automated sequence of steps triggered by an event like a push or a tag — typically build, then run tests and checks, then (if all pass) produce and publish artifacts. It runs on a service like GitHub Actions, so the same steps happen identically every time, with no manual effort or forgotten steps.