CI/CD Pipeline Builder
GitHub Actions, GitLab CI, and pipeline-as-code patterns. Build, test, deploy - automatically.
“A CI/CD pipeline is the difference between 'deploying is terrifying' and 'Friday afternoon at 4:45 is a great time to release.'”
What you'll learn
A pipeline is a gate, not a vibe
CI/CD is a sequence that refuses to promote a change that failed a check you claimed to care about. Lint, test, build, scan, deploy. Each stage is allowed to stop the line. A pipeline that always deploys is a script with a logo.
Write the pipeline as code in the repo. GitHub Actions lives in .github/workflows/. GitLab CI lives in .gitlab-ci.yml. If the pipeline only exists in a GUI click-path, it will drift the week the person who clicked it is on leave.
GitHub Actions without the marketplace folklore
A workflow is jobs. A job is steps on a runner. Pin third-party actions by commit SHA if you have learned anything from supply-chain week. actions/checkout@v4 is convenient. A random setup-magic@main is how you outsource trust to a stranger's branch.
Reusable workflows exist so twenty repos do not invent twenty slightly wrong deploy jobs. Matrix builds exist so you test the versions you claim to support. Do not matrix the universe. You will wait for it.
GitLab CI is the same idea with different YAML
Stages, jobs, artifacts, environments. rules: will eat an afternoon. Start with branch pipelines on main and merge requests. Add environment: when you want GitLab to remember that staging exists.
Artifacts are how you stop rebuilding the same tarball in every job. Expire them. An artifact store that never forgets is a very slow museum.
Environments are a promotion path, not a folder named prod
Dev gets every passing main build, or every passing MR if you like living loudly. Staging gets what you intend to ship. Production gets a human or a change ticket, depending on how expensive a mistake is.
Manual approval gates are not cowardice. They are how you keep a green pipeline from becoming a green outage. Automate the boring path. Pause the irreversible one.
The Friday test
If you would not merge it at 16:45 on Friday, the pipeline is not the problem. The rollback is. A deploy job without a documented rollback is a one-way door. Prefer deploys you can revert by shipping the previous artifact, not by 'quickly fixing forward' under adrenaline.
Pipeline speed matters because slow feedback trains people to skip it. Cache dependencies. Do not cache test results you would not bet the release on.