The Case for All Quality Checks Before Merge: A Streamlined Workflow
In modern software development, workflows are as much about minimizing friction as they are about ensuring quality. One controversial but increasingly relevant approach is to enforce that all quality checks happen before code is merged. While this might sound overly stringent at first, the benefits far outweigh the drawbacks, and the approach fundamentally changes how we think about integration, deployment, and bug fixes.
Why Pre-Merge Quality Checks?
The idea is simple: merge code only when it’s production-ready. Here’s why this makes sense:
1. Avoiding Batching Work
Merging untested or partially tested code leads to batching. Developers rely on shared environments like QA, UAT, or Staging to perform integration tests, meaning changes pile up. This creates dependencies and introduces integration risks. Instead, if every piece of code passes quality checks before merging, you eliminate this problem entirely. Each merge represents a clean, deployable state.
2. Eliminating Release Overhead
Traditional workflows require:
- A release cadence.
- Coordination between teams.
- Cutoff dates for code freezes.
All of this introduces overhead and stress. Developers often rush to meet release deadlines, cutting corners or pushing less-than-stable code. Worse, unresolved issues require developers to revisit their work days later, which disrupts focus and workflow. In a pre-merge quality check model, code merges directly to production after passing all checks, removing the need for these rituals.
3. Streamlining Bug Fixes
In traditional workflows, hotfixes often follow ad-hoc processes, complicating deployment. With pre-merge checks:
- Bug fixes are treated like any other feature.
- Write a failing test.
- Fix the bug so the test passes.
- Merge to main, and the fix is auto-deployed.
This ensures consistency and reduces the chaos of hotfixes.
Additional Benefits
Beyond the immediate advantages above, this workflow offers:
4. Shorter Feedback Loops
Pre-merge checks provide instant feedback. Issues are caught early, making them cheaper and easier to fix. Long-lived branches, which are often a source of integration headaches, become unnecessary. Developers work in smaller increments, making changes more manageable and less risky.
5. Improved Developer Experience
When developers know that passing tests mean their code is live, it creates clarity and confidence. There’s no ambiguous “Will this work after it’s deployed?” moment. Instead, the merge becomes a seamless part of their workflow.
6. Encouraging Better Practices
To succeed with this model, teams naturally adopt practices like:
- Comprehensive test coverage.
- Automated testing pipelines.
- Clear code reviews and documentation.
Considerations and Challenges
Of course, this approach isn’t without its challenges. Here are some considerations:
1. Investment in Automation
Automated testing, static code analysis, and deployment pipelines are prerequisites. The upfront investment can be significant, but the long-term ROI in reduced overhead and fewer production issues is undeniable.
2. Handling Edge Cases
Not all issues can be caught pre-merge. For instance:
- Rare production-only bugs.
- Performance bottlenecks that only appear under real-world load.
These need separate monitoring and quick-response systems in place.
3. Cultural Change
Switching to a pre-merge quality check model can be a significant shift for teams used to traditional workflows. It requires buy-in from everyone, especially leadership, to prioritize upfront quality over post-merge troubleshooting.
4. Incremental Adoption
For large teams, adopting this model gradually may be the best approach. Start with critical services or smaller teams to pilot the workflow. Iterate based on feedback before rolling out organization-wide.
What About Rollbacks?
One concern with auto-deployment is what happens if something goes wrong. The answer: make rollbacks part of the pipeline. Tools like Kubernetes and feature flags allow for quick, controlled rollbacks, minimizing downtime.
Finally: Less Overhead, More Impact
When you enforce all quality checks before merge, you’re not just improving code quality—you’re transforming how your team works. No batching, no release overhead, no chaotic hotfixes. Just a clear, streamlined process where merging equals deployment. While it requires upfront effort and cultural alignment, the long-term benefits of efficiency, reliability, and developer satisfaction make it a compelling case for modern teams.
By adopting this approach, you’re not just shipping code; you’re shipping confidence. And isn’t that what great engineering is all about?
Comments ()