2.1.2.2. Running Builds/Tests on Pull Requests & Merges
First Principle: Validating every proposed change before it's integrated into the main codebase ensures a clean and stable main branch.
Automating builds and tests on Pull Requests (PRs) and merges is a critical practice for maintaining code quality and preventing regressions. When a developer submits a Pull Request with new code, the CI/CD pipeline automatically runs tests against the proposed changes.
Key Benefits of PR/Merge Builds & Tests:
- Early Feedback: Developers receive immediate feedback on the quality and correctness of their changes.
- Prevents Regressions: Catches bugs before they are merged into the main branch, preventing them from impacting other developers or production.
- Enforces Standards: Ensures code adheres to quality, style, and security standards.
- Facilitates Collaboration: Provides a clear signal for code reviewers on the health of the proposed changes.
Implementation:
- Configure webhooks in your source control system (e.g., AWS CodeCommit, GitHub) to trigger AWS CodeBuild or AWS CodePipeline on PR creation or updates.
- Define a buildspec that runs relevant tests (unit, linting, static analysis) for the PR.
- Require successful build and test status checks before a PR can be merged.
Scenario: A development team frequently introduces breaking changes when merging code into the main branch, leading to a "broken" main branch and frustrating other developers.
Reflection Question: How does running automated builds and tests on Pull Requests and requiring successful status checks before merging fundamentally prevent regressions and ensure a stable, continuously working main codebase?
This practice is a cornerstone of a robust and high-quality development workflow.
š” Tip: Keep PR builds and tests fast. Long-running tests can slow down development velocity. Focus on critical, quick-to-execute validations at this stage.