My pipeline used to run linting, end-to-end tests, image building, Kubernetes validation, and deployment mostly in sequence, taking about 10 minutes. After reorganizing it to run independent checks in parallel and test the built image before pushing and deploying it, runtime fell to just under four minutes. What CI/CD changes have had the biggest impact for you?
What changes made the biggest difference to your CI pipeline?
Asked by
r0cketmoss
Answers
The key improvement here is not just speed. Build the image once, validate that image, and promote the same artifact through deployment. If tests run against source code or a separately built image, they may not cover exactly what you ship.
Independent checks such as linting and Kubernetes manifest validation can run in parallel. Then build the image, scan it, run end-to-end tests against a container made from it, and only push or deploy after those gates pass.
Reply to this answer
Parallel jobs are often the quickest win when the pipeline has a lot of unrelated checks chained together. Dependency caching, smaller build contexts, and multi-stage image builds can help too, but measure each change. A cache that is unreliable or costs more time to maintain may not be worth it.
Splitting a long test suite across workers can reduce wall-clock time, though it uses more runner capacity. Compare the extra cost with how much faster feedback matters for your team.
Reply to this answer
Keep the build and deployment concerns separate. A successful build should produce a versioned artifact that can be promoted to another environment, rather than rebuilding separately for each destination. That makes it easier to trace what was tested and what is running.
Standardized pipeline templates can also make these practices easier to apply consistently across projects, instead of relying on every team to invent its own workflow.
Reply to this answer
One detail to think through is test configuration. If the app needs mock services or environment-specific settings, provide those to the test environment without baking them into the production artifact. The exact setup depends on how the app talks to its dependencies.
Also make sure readiness checks wait for the app to actually be usable before the browser tests begin. Otherwise, a faster pipeline can just mean more flaky failures.
Reply to this answer
Image scanning and deployment validation are useful gates, but be clear about what each one checks. A vulnerability scan can flag issues that need a defined policy, and a Kubernetes validation job does not replace checking that the deployed service starts and behaves correctly.
Restricting credentials and only granting publishing or deployment permissions to the jobs that need them is a worthwhile security improvement alongside runtime tuning.
Reply to this answer
Add your answer
Answers are reviewed before publication.
BIRCH:
How do you run the browser tests without adding test tooling to the production image?
r0cketmoss:
The test runner stays outside the production image. The workflow starts a container from the built image, then runs Playwright against the running app.