Тема: continuous-integration
-
Designing a continuous integration pipeline
A CI pipeline should be fast, self-testing and identical for every change: build from a clean checkout, run linters and tests in stages, fail loudly, and keep the total time short enough that people wait for it.
-
Keeping CI and local checks identical: one entry point, pinned tools, same container
A check that passes locally should pass in CI and vice versa: define every check once as a named task, pin the toolchain in a committed manifest that both the bootstrap and the pipeline install from, run CI in the same container image as the dev environment, fix locale and timezone, and treat any CI-only failure as a parity bug to eliminate before fixing the symptom.
-
Ephemeral databases in containers for integration tests
Start the real database engine in a throwaway container per test run, keep its data on memory, apply migrations once to a template database and copy it per test file; tests then exercise the real planner, constraints and isolation behaviour instead of an in-memory substitute.
-
Dependency order with graph traversal: BFS, DFS and topological sort
Model dependencies as a directed graph, use breadth-first or depth-first traversal to find everything affected by a change, and Kahn's algorithm or DFS post-order to produce a build or migration order that reports cycles instead of hiding them; graphlib and tsort implement the sort.
-
Running mutation testing without drowning in survivors
Run a mutation tool on one module, classify each surviving mutant as a missing assertion, a missing case or an equivalent mutant, fix the first two, exclude the third, and bound runtime with incremental or diff-scoped runs; use the score as a ratchet per module rather than a global target.
-
Which pre-deployment checks have actually stopped a bad release in the last year, and which have never fired?
Open question: pipelines accumulate gates (tests, scans, smoke checks, canary analysis, manual approvals, rollout deadlines), and the Kubernetes documentation notes that a stalled Deployment is only reported, not rolled back; which gates have a record of stopping a bad release, which never fired, and which fired only falsely?
-
Consumer-driven contract tests: verifying integrations without a shared environment
A consumer-driven contract records the requests a consumer makes and the minimal response it relies on; the consumer tests against a mock built from that record, and the provider replays it against its real code. Both sides run in their own pipelines, and a version matrix answers whether a release is compatible with what is deployed.
-
Build provenance attestations: what SLSA provenance records and how it is verified
SLSA's Build track rates how trustworthy an artifact's provenance is, from 'provenance exists' (L1) to a hardened build platform (L3); the provenance is an in-toto attestation naming the artifact digests, the builder, the build type and its external parameters, and a consumer checks it against a root of trust and expected values before use.
-
Preview environments per branch: one deployed copy per pull request, torn down on merge
Give every pull request a running copy of the application at its own URL, built once per commit, named by pull-request number, seeded with the local seed and wired to sandbox third parties; post the URL to the pull request, cap concurrency, and delete the copy and its data on merge, close or inactivity.
-
Trunk-based development and short-lived branches
Integrating everyone's work into one shared line at least daily, keeping branches short-lived and hiding unfinished work behind flags, reduces merge conflicts and makes continuous integration real.
-
Git hooks for fast local checks
Client-side hooks such as pre-commit run formatters and quick linters before a commit exists; they save review time but must stay fast, must not be the only gate, and are not versioned by Git itself.
-
Diagnosing and removing flaky tests
A flaky test passes and fails without code changes; the usual causes are shared state, timing assumptions, order dependence and real external services. Quarantine, reproduce, fix the cause, never just retry.
Машиночитаемо: JSON