Deploy board for every environment, with one-click redeploys

I want a deploy board my whole engineering team can open to see what shipped to each environment, and to ship again without leaving the screen. Build it as an app backed by Buildkite for the builds and GitHub for pull request context.

Start with a settings view where someone maps Buildkite pipelines to environments. Resolve the organization slug first with List Organizations, then populate a pipeline picker with List Pipelines. Each mapping row holds an environment name the team chooses (staging, production, canary), one or more pipelines that deploy to it, a flag for whether deploying there requires a confirmation step, and the GitHub owner and repository name used for pull request matching. Persist these mappings for the whole app so everyone opens the same board. Default the confirmation flag to on for any environment whose name contains production.

The main surface is a column per environment, in the configured order. Each column header shows the pipeline name plus two stats covering the last 30 days: the pass rate and the median build duration. Compute both in the handler by paging List Builds for a Pipeline with a created-from date 30 days back and reducing the returned build states and start and finish timestamps. Under the header, show the time since the last successful deploy, taken from the most recent passed build. Give the board a manual refresh control.

Below the header, list recent deploy builds for the mapped pipelines, newest first, using List Builds for a Pipeline. Each entry shows the commit message, branch, author, duration, state with a color, and relative time. Take the commit SHA, message, and author straight off the Buildkite build object. Important constraint: the GitHub catalog has no commit lookup operation, so do not design any view that fetches commit detail from GitHub. Clicking an entry opens a detail panel that calls Get a Build for the full record including per-job state. Note that builds are addressed by their per-pipeline sequential number, not by their UUID.

For each entry, match the build branch to its pull request. Call List Pull Requests on the mapped repository filtered by head branch, take the best match, then call Get a Pull Request for the title, the reviewers, and the diff size in additions, deletions, and changed files. Show that beside the deploy so the reviewer and the size of the change sit right next to what shipped, and link out to the pull request on GitHub. When no pull request matches the branch, show the branch name alone and skip the panel quietly rather than showing an error.

Deploy actions live in the board itself. A Deploy button opens a dialog where the user picks a pipeline mapped to that environment and a branch, then triggers Create a Build. Every past build in a passed state gets a Redeploy button that calls Rebuild a Build, so rolling back to a known-good build is one click. Builds still running get a Cancel button backed by Cancel a Build. When the target environment is flagged as requiring confirmation, add a confirmation step to the dialog that makes the user type the environment name before the deploy button enables.

Every deploy, redeploy, or cancel started from inside the app records who did it: the signed-in user, the environment, the pipeline, the branch or source build, the resulting build number, and the timestamp. Show that attribution inline on the matching board entry, reading something like "Redeployed by Priya from the board", and add a Deploy log view listing those records newest first so the board doubles as an informal deploy log. Builds triggered outside the app simply carry no attribution line.

In the setup and empty states, explain that viewing the board only needs read access to builds and pipelines, while the Deploy, Redeploy, and Cancel buttons need a Buildkite token with build write access. If the connected token cannot write, keep those buttons visible but disabled with a short inline explanation rather than hiding them.