Engineering
Ship code with engineering tickets
Take a ticket from Analyze to Release: approve the plan, follow the pull request and release the change.
An engineering ticket is a bug, a feature or a change to the code of your product. The Engineer takes each ticket through five steps, and stops for you only where your word counts. This page tells you how to make a ticket, approve its plan, follow its pull request and release the change.
Before you begin
- An Engineer in the troop. Owners and admins hire one. See Hire and manage teammates.
- GitHub, connected, with a test command for each repo. See GitHub.
- A Claude plan. The Engineer reads and writes code with Claude Code, so it needs a Claude subscription or an Anthropic API key. See Choose AI plans and models.
- A QA tester, if you want a second review and a test of each change. See Test your product with the QA tester.
The five steps
| Step | Who does it | What happens |
|---|---|---|
| Analyze | The Engineer | It reads the ticket and the code. It writes the analysis: the problem, and the checks under Done when. |
| Plan | The Engineer | It writes the plan: the approach, the decisions, the steps, the files and a test for each check. |
| Build | The Engineer | It changes the code on a branch of its own, runs the tests of the repo and opens a pull request. |
| Test | GitHub and the QA tester | GitHub's checks run, reviewers read the change, and the QA tester tests it. |
| Release | A person, or auto-release | Troopy merges the commit that passed every gate into the default branch. |
The status of a ticket still says who has it now. A ticket that waits for its release is at Release and In review. A released ticket is Done.
On Tasks, the Engineering tab shows the statuses of all its tasks. Select Steps to see the steps as columns: Backlog, Analyze, Plan, Build, Test, Ready to release and Released. Released shows the tickets of the last 14 days, and only tickets show there. A card shows the state of GitHub's checks, such as Waiting for checks, and the try of the change, such as Try 2 of 4.
Make a ticket
- Open Tasks, and select the Engineering tab.
- Select New task.
- Under What is it?, select Bug, Feature or Change.
- Write a title. Answer the questions that the brief box shows.
- Select Create task.
The ticket goes to the Engineer that has the fewest tickets at work, and starts at Analyze. If you set its status to Backlog, it waits there until you move it to Analyze. With no Engineer in the troop, the Chief of Staff proposes to hire one.
Tickets also come from these places:
- An engineering task that you give to an Engineer. A sub-task, a task with sub-tasks, and the task of a routine or of a chat stay out of the steps.
- Fix it on an incident. See Catch the errors of your apps.
- Make a bug ticket on a problem of a test run, and the bug ticket of a place whose checks begin to fail. See Test your product with the QA tester.
Answer questions and approve the plan
At Analyze, the Engineer asks all of its questions at one time. The ticket then waits in Needs you. When you answer all of them, the Engineer goes on.
When the plan is ready, the ticket shows Approve the plan, and Needs you shows Plan to approve.
- Open the ticket from Needs you, or from the board.
- Read the Analysis and the Plan.
- If the plan is correct, select Approve the plan.
- If it is not correct, select Ask for changes. Write what must change, then select Ask for these changes.
After your yes, the Engineer starts to change the code. The analysis and the plan lock. To change them again, move the ticket back to Plan.
You can edit the analysis and the plan where they stand. Each change saves by itself. While the Engineer works on the ticket, the two are read-only. A yes approves the version that you read. If the plan changed while you read it, Troopy refuses the yes. Read the plan again, then approve it.
Follow the build
At Build, the Engineer changes the code in a copy of the repo, on the computer of the workspace. Each ticket
has its own branch, like troopy/vir-12-fix-the-signup-bug. Troopy pushes only branches under troopy/. A build can
take up to 40 minutes.
Troopy runs the test command of the repo on each change. Only a change that passes those tests becomes a pull request. The pull request opens as a draft. Troopy marks it ready for review when every gate passed.
The Code section of the ticket shows the repo and the branch, the result of the tests, the files that changed and
the pull request. Troopy refuses a commit that holds something with the shape of a secret, or that changes
.github/workflows.
Follow the gates at Test
At Test, gates read the change. Troopy reads the pull request every 2 minutes.
- GitHub's checks. With GitHub's checks must pass on, the ticket waits for the checks of the repo. A failed check sends it back to Build with what failed. A repo that shows no checks for 3 minutes after a push has none.
- Reviews on GitHub. A review that asks for changes sends the ticket back to Build with the words of the reviewer. Only the reviews of the owner of the repo, the members of its organization and its collaborators count.
- The QA tester. With a QA tester in the troop, it tests the change after the checks. A pass moves the ticket on. A fail sends the ticket back to Build with the report.
- A new commit. A push to the pull request sends the ticket back to Test. The gates then read the new commit.
The Checks panel of the ticket lists each check of GitHub, with a link to it. The Test section shows the latest test run of the QA tester, with Open the report.
Each send-back to Build counts one try. After the number of tries in Tries before it asks you, the Engineer stops, and the ticket waits for you. Without a QA tester, the ticket goes on when GitHub's checks pass.
Release the change
When every gate passed, the ticket moves to Ready to release. How it goes live depends on How changes go live:
- A person presses Release, the default. On the ticket or in Needs you, select Release. A merge on GitHub releases the ticket too.
- People merge on GitHub. Merge the pull request on GitHub. Troopy marks the ticket Released when GitHub merges it.
Before Release merges, Troopy reads the gates again. It merges only the commit that passed them, with the method of How Release merges. GitHub's rules for the repo still apply, such as a required review. After the merge, Troopy deletes the branch of the ticket.
To close a ticket with no merge, set its status to Done. Only the people who can release do this.
Move a ticket between steps
Only a person moves a ticket between steps. Use the Step property of the ticket, or drag its card on the board. A move to the step where a stopped ticket is starts that step again.
| Move | What happens | Who |
|---|---|---|
| Back to Analyze or Plan | The analysis and the plan unlock. The plan needs a new yes. | Members, owners and admins |
| Back to Build | The Engineer works on the change again. Your move is the reason that it reads. | Members, owners and admins |
| Forward to Build | It approves the current plan in your name. | The people who approve plans |
| To Test | The gates read the change again. It needs an open pull request whose tests passed. | Members, owners and admins |
| To Ready to release | It skips the gates at Test. Auto-release never releases such a ticket. | The people who can release |
| Take it out of the steps | The ticket becomes a plain task. You cannot do it while a teammate works on it. | Members, owners and admins |
Nothing drops on Released. A ticket goes there with Release, with a merge on GitHub, or with auto-release.
Settings > Engineering
Owners and admins change these settings in Settings > Engineering. Each change ends an auto-release grant.
| Setting | Choices | Default |
|---|---|---|
| Ask a person to approve the plan | For every ticket, For medium and large changes or Never | For every ticket |
| Who approves plans | Everyone in the workspace or Owners and admins | Everyone in the workspace |
| How changes go live | A person presses Release or People merge on GitHub | A person presses Release |
| Who can release | Owners and admins or Everyone in the workspace | Owners and admins |
| How Release merges | Squash, merge commit or rebase | Squash |
| GitHub's checks must pass | On or off | On |
| Tries before it asks you | 1 to 5 send-backs | 3 |
Turn on auto-release
Under auto-release, Troopy releases each ticket that passed every gate, with no person, for a time that you pick. Owners and admins turn it on. Before the grant, these must be true:
- How changes go live is A person presses Release.
- GitHub's checks must pass is on.
- GitHub is connected, and its owner accepted the new permissions of Troopy's app.
- People released 3 changes in the last 30 days.
- Open Settings > Engineering, and go to Auto-release.
- Under For, pick 1, 3, 7, 14 or 30 days.
- Under Changes a day, at most, pick a number from 1 to 10.
- Under Which changes, pick the largest size that it releases.
- Select Turn on auto-release.
Auto-release merges only a commit that went through Test and that GitHub's checks passed. It never releases these tickets:
- a ticket with no size, or larger than the size of the grant
- a ticket that a person moved past Test
- a ticket of an incident, or of work that an event from outside Troopy started
The grant stops when its date comes, when someone changes the engineering settings, or when its granter is no longer an owner or admin. It also stops when GitHub refuses a merge for a reason that a person must handle. A new incident whose possible cause auto-release shipped stops it too. The Engineer says why in the troop chat. To stop it yourself, select Turn off auto-release.
Problems
| Message | Why | What to do |
|---|---|---|
| The pull request was closed on GitHub. | Someone closed it with no merge. | Reopen it on GitHub, or move the ticket back to Build. |
| Only an Engineer analyzes, plans and builds a ticket. | Another teammate holds the ticket. | Give the ticket to an Engineer. |
| The Engineer finished without a pull request that passed the repo's tests. | The tests of the repo failed on each try. | Write to the Engineer on the ticket, then select Try again. |
| Testing sent it back 3 times, and it failed again. | The tries ran out. | Read the last report, then move the ticket to Build. |
| It conflicts with the latest code on the default branch. | The default branch changed under the pull request. | Resolve the conflict on GitHub, then try again. |
| Troopy can't read GitHub's checks yet. | The GitHub account did not accept the Checks and Commit statuses permissions. | An owner of the GitHub account accepts them on GitHub. See GitHub. |
| GitHub wants an approving review first. | The repo asks for a review before a merge. | Approve the pull request on GitHub, then select Release again. |
| The repo doesn't allow squash merges. | The method of How Release merges is off in the repo. | Change How Release merges in Settings > Engineering. |
| It was behind the default branch. | The repo asks for an up-to-date branch. | Wait. GitHub updates the branch, and the new commit goes to Test. |
| The Engineer writes code with Claude Code. | The organization has no Claude plan that can take the work. | Add a Claude plan in Settings > AI. |
Who can do what
| Action | Who |
|---|---|
| Make a ticket, answer questions, move a ticket between steps | Members, owners and admins |
| Approve a plan | Everyone in the workspace, or only owners and admins, as Who approves plans says. Approvers too, when everyone approves. |
| Release a ticket, or close it by hand | Owners and admins, or everyone, as Who can release says. Approvers too, when everyone releases. |
| Change Settings > Engineering, and turn auto-release on or off | Owners and admins |
| Read tickets, plans and gates | Everyone in the workspace, viewers too |
Teammates never move a ticket between steps, and never release one.