CI gates merges. On every push/PR, run: install → lint → build → test. The pipeline is the source of truth for "is this mergeable" — keep it green and treat a red build as stop-the-line.
Make it fast and deterministic. Cache dependencies; parallelize independent jobs; pin tool versions so runs are reproducible. A slow or flaky pipeline gets ignored.
No flaky gates. A test that fails intermittently erodes trust in the whole pipeline — fix or quarantine it (see condition-based-waiting for the usual cause).
CD ships the artifact CI built — don't rebuild for deploy. Promote the exact tested artifact through environments (e.g. staging → prod).
Secrets via the CI secret store, never in the config or logs. Scope them to the jobs that need them.
Match the project. Use its existing CI system and config conventions; add a job, don't introduce a second CI tool.
Surface results where people see them (status checks, required checks on the default branch) so the gate actually gates.

Pair with deploying-safely for what happens after the pipeline goes green.

Más de este repositorio

mismo repositorio

Catch bad React in your changes — run react-doctor's deterministic scan and fix what it flags

Run a verifiable security scan (vulns, secrets, misconfig) over code you wrote or deps you added, before calling the work done

Drive a real browser verifiably — navigate, snapshot, act BY INDEX, extract; every step provable

Run multi-agent work as ONE provable causal DAG — parallel subagents, an Orchestrate graph, an immutable spec-seed

Author or connect a Model Context Protocol server so an agent gains new tools

Build reliable, resumable data connectors and transforms (ETL)

name	ci-cd-pipelines
description	Build automated pipelines that gate merges and ship reliably
version	1
trust	built-in

CI/CD makes quality automatic: every change is built, tested, and (when trusted) shipped the same way, every time.

CI gates merges. On every push/PR, run: install → lint → build → test. The pipeline is the source of truth for "is this mergeable" — keep it green and treat a red build as stop-the-line.
Make it fast and deterministic. Cache dependencies; parallelize independent jobs; pin tool versions so runs are reproducible. A slow or flaky pipeline gets ignored.
No flaky gates. A test that fails intermittently erodes trust in the whole pipeline — fix or quarantine it (see condition-based-waiting for the usual cause).
CD ships the artifact CI built — don't rebuild for deploy. Promote the exact tested artifact through environments (e.g. staging → prod).
Secrets via the CI secret store, never in the config or logs. Scope them to the jobs that need them.
Match the project. Use its existing CI system and config conventions; add a job, don't introduce a second CI tool.
Surface results where people see them (status checks, required checks on the default branch) so the gate actually gates.

Pair with deploying-safely for what happens after the pipeline goes green.