CI/CD Patterns and Antipatterns - Things your Pipeline Should (Not) Do - Daniel Raniz Raneland

Split pipelines into parallel flows instead of having one long sequential pipeline - this reduces wait times and provides faster feedback

Cache dependencies, build artifacts, and tooling images to avoid downloading/rebuilding everything from scratch each time

Only run tests and steps that are actually needed based on what changed - use conditional logic and path filters to determine what needs to run

Treat pipeline code as a software project - extract complex logic into scripts/Makefiles, create reusable components, avoid over-engineering in pipeline definitions

Clean up artifacts regularly and don’t hoard old builds/artifacts indefinitely - this prevents disk space issues and improves maintainability

Build agents should be at least as powerful as developer machines to ensure builds run efficiently

Avoid wrapper tasks that add complexity - call tools directly when possible

Use tooling images to package dependencies and tools instead of installing everything from scratch

Structure pipelines logically based on what needs to run together, not just in sequential order

Consider cost/maintenance tradeoffs between self-hosted runners vs cloud CI services, and appropriately size build infrastructure

Design pipelines to minimize context switching and interruptions for developers

Run integration/end-to-end tests early if they tend to fail first to get faster feedback

Use caching mechanisms like Docker BuildKit to speed up container image builds

Break up monolithic pipelines into smaller focused ones that can run in parallel

Remove unnecessary steps and only run what’s needed for each specific pipeline purpose