Back to path
BeginnerBeacon · Project 3 of 12 ~4h· 6 milestones

Adopt trunk-based development and PR automation

Continues from the last build: Rung 2 gave you CI that runs on every pull request, but the team still keeps long-lived feature branches, merges are chaotic, and reviews are inconsistent.

CI now runs on every pull request for the notifications service, so you finally trust the green check.

Trunk-based developmentConventional CommitsGitHub branch protection and required reviewsCODEOWNERS-based code ownershipGitHub Actions for PR automationPull request review hygiene
Build this freeBrowse all projectsNo credit card. Already a member?

What you'll build

By the end you will have turned the service's chaotic, long-lived-branch workflow into a disciplined trunk-based one. Short-lived branches merge into main through pull requests that carry a real description, are labeled by which service they touch, are blocked when they grow too large, require review from the directory owners via CODEOWNERS, and auto-merge the moment CI is green and approvals are in. The result is fewer merge conflicts, consistent reviews, machine-readable commit history, and a trunk that is always releasable, all without touching a single piece of infrastructure.

See how we teach, before you sign up

You don't just get code dumped on you. Every starter file and every solution is explained line-by-line, in plain English. Here's one real file from this project:

.github/CODEOWNERStext
# Default owners for everything not matched below.
*                 @beacon-org/platform

# Service owners. These teams are auto-requested and required
# as reviewers when a PR changes files under these paths.
/api/             @beacon-org/api-team
/worker/          @beacon-org/worker-team

# Shared libraries are sensitive: both teams must be aware.
/libs/            @beacon-org/api-team @beacon-org/worker-team

# Delivery config is owned by platform only.
/.github/         @beacon-org/platform
/deploy/          @beacon-org/platform

Reading this file

  • * @beacon-org/platformThe wildcard is the fallback owner for any path no later rule matches; later, more specific rules win.
  • /api/ @beacon-org/api-teamA leading and trailing slash scopes the rule to that directory and everything under it.
  • /libs/ @beacon-org/api-team @beacon-org/worker-teamTwo owners on one line means both teams are requested; shared libs need both services' awareness.
  • /.github/ @beacon-org/platformThe delivery config itself is owned, so process changes get reviewed like code.

Maps directories to required reviewers. With branch protection requiring CODEOWNERS review, a PR touching worker/ cannot merge without an owner of worker/ approving. Every team listed must have write access to the repo or GitHub silently ignores the line.

That's 1 of 8 explained code blocks in this single project.

The build, milestone by milestone

  1. 1

    Write the trunk workflow contract in CONTRIBUTING.md

    5 guided steps

    Trunk-based development is a discipline first and tooling second. If the rules are not written down, the branch protection and Actions you add later will feel arbitrary and people will route around them. A short CONTRIBUTING.md turns the workflow from tribal knowledge into an onboarding doc.

  2. 2

    Add the PR template and CODEOWNERS

    5 guided steps

    A template makes every PR self-describing, which kills the wip and more stuff titles and feeds the release notes. CODEOWNERS encodes who is accountable for each part of the service so reviews stop being a lottery and the right expert is always pulled in, especially for the shared libs.

  3. 3

    Turn on branch protection and required CODEOWNERS review

    5 guided steps

    A template and CODEOWNERS only suggest good behavior until branch protection makes them required. Requiring CODEOWNERS review plus passing CI plus up-to-date branches plus stale-approval dismissal is what guarantees trunk stays releasable and that the Friday-merge class of breakage cannot reach main.

  4. 4

    Auto-label PRs by the service they touch

    5 guided steps

    Labels turn a wall of open PRs into something scannable. A reviewer seeing libs on a PR knows it is the sensitive cross-cutting kind that needs both teams, exactly the change that hurt in the scenario. Automated labeling is consistent where human labeling is not.

  5. 5

    Flag oversized PRs with a size check

    5 guided steps

    The root cause of the rung-2 pain was large, long-lived branches. A size signal makes that visible at PR time and trains the team to split work, which is the single biggest lever on review quality and merge safety. Small PRs review faster and conflict less.

  6. 6

    Enable auto-merge so green, approved PRs land themselves

    5 guided steps

    Auto-merge removes the human babysitting that made merges chaotic and slow. Combined with branch protection it means nothing reaches main unless it is green and owner-approved, and it lands immediately when it is, so trunk moves fast and stays releasable. Squash keeps history one-commit-per-change for clean release notes.

What's inside when you start

4 starter files, ready to clone
6 guided milestones
4 full reference solutions
8 code blocks explained line-by-line
6 "is it working?" checks
5 interview questions it prepares you for

You'll walk away with

A CONTRIBUTING.md at the repo root defining trunk-based development, short-lived branches, and the Conventional Commits convention with service-specific examples.
A .github/pull_request_template.md and a .github/CODEOWNERS that maps api/, worker/, and libs/ to owning teams, with libs/ requiring both service teams.
Branch protection on main requiring a PR, passing CI status checks, up-to-date branches, CODEOWNERS review, and stale-approval dismissal, all confirmed by the verify command.
A scripts/create-labels.sh that pre-creates the api, worker, libs, and delivery labels, plus a .github/workflows/pr-labeler.yml and .github/labeler.yml that auto-label PRs by the service they touch.
A .github/workflows/pr-size.yml that warns on oversized PRs to keep branches small.
Repo settings with Allow auto-merge and squash merging enabled, plus a documented auto-merge workflow.

This is portfolio-grade. Build it free.

Sign up to unlock every milestone step-by-step, the code skeletons, full reference solutions, and checkable tasks, with your progress saved as you build.

Start building