CI/CD & GitOps Practical By Samson Tanimawo, PhD Published Jul 21, 2025 4 min read

Pre-Merge Checklist

Before merging: ensure these.

What goes in the checklist

Tests: unit, integration, end-to-end where applicable. CI green.

Code review: at least one approver, ideally two for tier-1 services.

Documentation: comments on non-obvious code, runbook updates if behavior changed.

Observability: new metrics, alerts, dashboards added for the new feature.

Automate what you can

Branch protection rules in GitHub or GitLab block merges without review and CI.

PR templates require checking boxes for documentation, tests, observability.

Bots check that linked tickets are in the right state, that PR description meets the standard.

What humans must check

Logical correctness. Tests pass; the code may still be wrong.

API design. Breaking changes to public APIs need explicit acknowledgement.

Performance and security implications that automated tools miss.

Blockers vs nits

Blocker: must fix before merge. Test failures, security findings, breaking API changes without versioning.

Nit: nice-to-have, can be follow-up. Style preferences, naming, refactoring opportunities.

Distinguish them in review. "This is a blocker" vs "This is a nit" reduces friction.

How to roll out the checklist

Start with 3 items. Adding 20 items overwhelms reviewers and gets ignored.

Bake into PR template. Visible at PR creation, hard to skip.

Audit quarterly: pick 10 random merges, check the checklist quality. Adjust based on what slipped through.