Laravel 12 Playbook: Shipping Weekly Without Regressions

Five rituals that kept three squads in sync while scaling to 50 deployments a month.

Scaling a development team is a double-edged sword. Growth brings more resources and the ability to tackle bigger challenges, but it also introduces complexity. When our organization grew from a single development team to three distinct squads, our deployment frequency skyrocketed. We were on track to hit 50 deployments a month, but a new problem emerged: regressions. Small bugs and unexpected side effects started slipping through the cracks, eroding user trust and pulling our developers into a cycle of reactive firefighting.

We knew that to ship weekly—or even daily—without breaking things, we needed more than just good intentions. We needed a playbook. This article shares the five core rituals we established to keep our squads aligned, our code quality high, and our deployments smooth. These practices, built around Laravel 12's powerful features, allowed us to maintain momentum and ship with confidence.

Whether you're a team lead, a product manager, or a Laravel developer, this playbook offers practical strategies to help you scale your own development process and leave regressions behind.

The Scaling Challenge: More Teams, More Risk

With three squads working in parallel on the same monolith, the risk of stepping on each other's toes was high. A change made by Squad A could unknowingly break a feature owned by Squad C. Traditional CI/CD pipelines and standard pull request reviews were no longer enough. The cost of a regression wasn't just the time spent on a hotfix; it was the broken trust with our customers and the demoralizing effect on our teams.

We needed a system that promoted both speed and stability. Our solution focused on creating shared rituals—non-negotiable practices that would become second nature to every developer on every team.

Ritual 1: The Bulletproof Pull Request Template

A pull request (PR) is the most critical checkpoint in the development lifecycle. To make them effective across teams, we had to standardize what a "ready" PR looked like. We moved away from empty descriptions and created a mandatory template that forced developers to think through the impact of their changes.

Our PR template became a contract, ensuring every change was documented, tested, and understood.

Key Components of Our PR Template:

• The "Why": A clear explanation of the problem being solved. This section links to the original ticket or user story, providing context for the reviewer. It answers the question, "Why is this change necessary?"
• The "What": A high-level summary of the changes made. This is not a line-by-line code explanation but a description of the approach taken. For example, "Added a new service class to handle payment processing and integrated it into the checkout controller."
• Testing Checklist: This is the most crucial part. The developer must confirm they have:
  • Written new feature tests for the functionality.
  • Written new unit tests for any isolated logic.
  • Manually tested the changes in a staging environment.
  • Confirmed that existing tests pass (locally and in CI).
• Screenshots/GIFs: For any UI changes, a visual confirmation is required. This makes it easy for non-technical stakeholders (like product managers) to review and approve changes quickly.
• Potential Impact: A section to flag any potential side effects or areas of the application that might be indirectly affected. This encourages proactive communication between squads.

By making this template a requirement for all PRs, we eliminated ambiguity and ensured a consistent level of quality before any code was even considered for merging.

Ritual 2: Automated Canary Deployments

Even with perfect PRs, you can't catch everything. The real test is in production. To minimize the blast radius of any potential regression, we implemented automated canary deployments. Instead of releasing a new version to 100% of our users at once, we slowly rolled it out.

Laravel's ecosystem, combined with modern hosting platforms, makes this easier than you might think. We used Laravel Vapor, but similar setups are achievable with other tools like Envoyer or custom scripts.

Our Canary Deployment Workflow:

1. Initial Rollout (5%): When a new version is deployed, it's initially routed to just 5% of our user traffic.
2. Automated Health Checks: Our pipeline then triggers a series of automated health checks. This includes running a critical-path test suite against the production environment and monitoring key metrics. We use Laravel's built-in HttpClient to run smoke tests that simulate user actions like logging in, adding an item to a cart, and viewing the dashboard.
3. Error Monitoring: We closely watch our error tracking platform (we use Sentry) for any new or increased error rates from the canary deployment. Laravel 12’s improved error handling and logging capabilities provide rich context for debugging.
4. Incremental Increase: If all health checks pass and no new errors are reported for 15 minutes, the traffic is automatically increased to 25%, then 50%, and finally 100%.
5. Automatic Rollback: If at any point the health checks fail or a spike in errors is detected, the deployment is automatically rolled back to the previous stable version, and the team is notified immediately.

This ritual acts as our ultimate safety net. It allows us to ship multiple times a day with the confidence that if something does go wrong, the impact will be minimal and short-lived.

Ritual 3: The "Owner" Code Annotation

In a large, shared codebase, it can be unclear who to ask about a specific piece of functionality. To solve this, we introduced a simple but powerful convention: code ownership annotations.

Every new class, service, or major component had to be "owned" by a squad. We used simple docblock annotations to declare this ownership.

/**
 * Handles the logic for generating user invoices.
 *
 * @owner Squad B (Billing)
 */
class InvoiceGeneratorService
{
    // ...
}

This simple annotation had several profound effects:

• Clear Communication Channels: When a developer from Squad A needed to modify code owned by Squad B, they knew exactly who to talk to. This prevented "drive-by" changes that could have unintended consequences.
• Accountability: Squads took pride in the quality and stability of the code they owned. It fostered a sense of responsibility that went beyond just shipping features.
• Targeted Code Reviews: When a change was made to code owned by Squad B, a member of that squad was automatically required as a reviewer on the PR. This ensured that the people with the most context were always in the loop.

We even built a small script that would parse these annotations and automatically assign reviewers in GitHub, further streamlining the process.

Ritual 4: Pessimistic Testing with Pest

To prevent regressions, your test suite needs to be robust. We adopted a "pessimistic testing" mindset, meaning we assume things will break in the most unexpected ways. Pest, with its expressive and readable syntax, became our tool of choice for writing tests that were easy to understand and maintain.

We mandated that every new feature must be accompanied by tests that cover not just the "happy path" but also common failure scenarios.

Our Testing Philosophy:

• Feature Tests for User Flows: We use feature tests to simulate full user journeys. For example, instead of just testing that a form submits, we test the entire flow: a user visits the page, fills out the form with invalid data, sees the validation errors, corrects the data, and successfully submits.
• Unit Tests for Complex Logic: Any complex business logic, especially in service classes or action classes, is isolated and covered by unit tests. This ensures that the core logic is sound, independent of the surrounding framework.
• Cross-Squad "Contract" Tests: When one squad's feature depended on an API or service from another squad, we wrote contract tests. These tests ensured that the "contract" (the expected input and output) between the two services was never broken. If Squad B changed their API, Squad A's tests would fail, forcing a conversation before the change was deployed.

Laravel 12's streamlined testing features, like simplified factory definitions and improved assertions, made it easier for our teams to write comprehensive and meaningful tests without slowing down development.

Ritual 5: The Blameless Post-Mortem

No system is perfect. Regressions will still occasionally happen. What matters is how you respond. We made the blameless post-mortem a mandatory ritual for any bug that reached production.

The goal of a post-mortem is not to point fingers but to understand the "how" and "why" behind a failure.

Our Post-Mortem Process:

1. Incident Timeline: Document the exact timeline of events: when the bug was deployed, when it was detected, when it was fixed, and what the user impact was.
2. Root Cause Analysis: Dig deep to find the root cause. It's never just "a developer made a mistake." Why was the mistake possible? Was the PR template insufficient? Did the tests have a gap? Was the canary deployment health check not sensitive enough?
3. Actionable Takeaways: Every post-mortem must result in at least one concrete, actionable takeaway. This is not a vague promise to "be more careful." It's a specific change to our process, such as "Add a new health check to the canary deployment to verify PDF generation" or "Update the PR template to require a database migration review."
4. Shared Knowledge: The findings from every post-mortem are shared with all three squads. This ensures that the entire organization learns from each failure, making our collective process stronger.

This ritual transformed our failures from demoralizing events into valuable learning opportunities, helping us continuously fortify our development playbook.

Conclusion: Shipping with Confidence

Scaling from one team to three and increasing our deployment frequency to over 50 times a month was a journey. The key to our success was not a single magic tool but a set of shared rituals that fostered alignment, quality, and accountability.

By implementing a bulletproof PR template, automated canary deployments, code ownership, pessimistic testing, and blameless post-mortems, we built a system that allowed us to move fast without breaking things. These five rituals, powered by the robust foundation of Laravel 12, can help your team optimize its development process and ship with the confidence that your application will remain stable and reliable.