How Autobuild Works

Autobuild turns a software request into organized, reviewable work. It prepares code changes in an isolated repository sandbox and links the resulting pull requests so you can review them before anything reaches your main branch. This guide explains how Autobuild organizes that work, where to follow progress, and when your approval is required.

How work is organized

Autobuild organizes a software request into an initiative, one or more features, and the executables needed to complete them.

An initiative is the overall body of work for your request. A feature is a coherent part of that request. An executable is a specific unit of work that Autobuild can complete and track. For example, an initiative to improve sign-in might include a feature for session handling and another for error messages. Each feature can contain executable work such as a code change or a check of the resulting behavior.

Dependencies connect work that must happen in order. An executable that needs another result waits for its prerequisite. Independent executables can move forward at the same time. This lets you see why some work is active while other work is waiting.

Where to follow progress

The Autobuild dashboard gives you a few clear places to follow work. Overview summarizes recent activity. Initiatives shows the overall request and the work within it. Board gives you a focused view of executable work as it moves through the workflow. Pull Requests shows proposed code changes, their checks, and their review state.

To follow an Autobuild run, open its initiative. Use Board to track executable work and Pull Requests to review proposed code changes and their checks. Start with Initiatives for the overall request, then move to Board when you need the state of a specific executable.

How code changes are prepared

Code work happens in a sandbox: an isolated environment prepared from your connected repository. Autobuild can make and check changes there without changing your main branch.

When a proposed code change is ready for review, Autobuild links it as a pull request. A pull request lets you inspect the change before it is merged. Continuous integration (CI) means automated checks that run against a pull request before the change is ready to merge. These checks help surface problems while the change is still reviewable.

Where approval is required

Autobuild prepares work for review; it does not replace your judgment. Before a change reaches your main branch, review the pull request and confirm that it matches your request and your team’s standards. If the checks surface a problem or the change is not what you expected, keep it out of the main branch until it is corrected.

What to do next

Ready to put this model into practice? Follow Your First Initiative to start an initiative from a spec document and track its progress on the Board. For a broader orientation before you begin, read What is Autobuild?.