What should the reviewer check when a builder opens a pull request for framework migrations in a monorepo?

Tares has the reviewer review every pull request a builder opens and post a verdict, so the bar you want is the one you write into the milestone’s acceptance checks. For framework migrations in a monorepo, put checks for CI, existing data and each repo the project touches into those milestones. The reviewer can also raise issues outside the ticket, which become new tickets.

How it works

Each project you hand to the factory has milestones, and each milestone carries acceptance checks. Tickets sit under the milestones. The builder takes one ticket at a time, makes a branch, does the work and opens a pull request.

The reviewer reviews every pull request and posts its verdict. A ticket can take more than one round: the reviewer asks for changes, the builder makes them, and the next round can pass. In the end-to-end project, most tickets passed on the first round and two needed a second.

What happens after a pass depends on what you chose at crew up. In the project followed on A project, end to end, the crew merged on its own once the reviewer passed a pull request and CI was green. Another project there waited for the person’s yes before every merge.

The reviewer is not limited to the ticket in front of it. In that project it found smaller issues outside the ticket it was reviewing. The orchestrator turned them into a new ticket, T8, placed it in a milestone ahead of the integration tests, and a builder fixed them there.

Set it up

You set the bar when you plan the project, because the spec session writes the milestones and their acceptance checks. Use these steps for a migration.

1. Bring up the crew. If you are new to the factory, follow Get started first for the prerequisites and the order of the steps.
2. Run the spec session in the repo and describe the migration as the goal.
3. In the spec session, ask for acceptance checks that a reviewer can verify on a pull request. Useful ones for a migration in a monorepo:
   • Tests and a CI check run on every pull request, so a green CI means something. In the example project, milestone M1 was exactly this: a test setup, unit tests and a CI check.
   • Existing data and past behavior stay as they were. In the example project, milestone M2 required that deactivating a sitter or changing a rate left past weeks untouched.
   • The final milestone covers the pull request being documented, merged and running.
4. Name every repo the project changes. The project page lists them under GitHub, with where each is checked out and its open and merged pull requests, so the reviewer and you can see the scope.
5. Pay attention to the assumptions. When the plan does not cover something, such as a config file that fails to load on the repo’s Node version, the builder picks an answer and records it as an assumption. In the example, the builder switched to a config file that loads, and ran the database CI job on the same Node version as the unit tests. You decide at the end of each milestone whether to keep them.

tares factory crew up
tares factory spec "what you want to build"

Watch the review queue and the Tickets fold on the project page to see each ticket’s pull request and review rounds.

What you get

• Every pull request gets a reviewer verdict before it merges, and the review rounds are recorded with the ticket.
• Acceptance checks you wrote into the milestone give the reviewer a concrete bar for the migration.
• Issues the reviewer finds outside a ticket become new tickets, so the plan can grow by itself.
• Choices the builder makes on its own appear as assumptions. In the example, a builder left existing production data alone and flagged it in the pull request, leaving any production fix to the person.
• A project page that holds the whole record: the tickets, the pull requests, your decisions and the assumptions.

When something else fits

• If you want to approve each merge yourself, choose that at crew up. The example project that waited for a yes before every merge shows how it works.
• For a change small enough that you review the diff yourself, you do not need milestones with acceptance checks. Keep the factory for work you want split into tickets and reviewed on every pull request.

Related