Rollout

Follow a plan’s execution through environments, database tasks, and recorded attempts.

A Rollout is the set of execution stages and tasks created for a Plan. Each stage groups tasks for one environment; each task performs work against a database or instance. A task run records an execution attempt, including its status and logs.

For example, a Rollout can add a column in a Test stage targeting hr_test, then a Prod stage targeting hr_prod. Each stage has its own execution results.

Open Deploy on the Plan page to follow execution.

How stages, tasks, and task runs fit together

Term	Meaning	Example
Stage	A group of tasks for one environment	Test
Task	An executable unit targeting a database or instance	Apply the change to hr_test
Task run	A recorded attempt to execute a task	An attempt with a status, duration, and logs

An environment classifies a target; a stage groups work for that environment. Retrying a task creates another task run with its own logs.

How a rollout is created

For a submitted UI change to existing databases, Bytebase creates the Rollout when approval is satisfied and checks finish without errors.

Create Database requests prepare and run their work through a separate Issue workflow; see Database.

In GitOps, CI creates the Rollout from a Release-based Plan after repository review and checks.

Creation prepares tasks. Manual environments wait for an authorized person or CI job to run them; automatic environments execute according to rollout policy.

Inspect and run tasks

1. Open the Plan and expand Deploy.
2. Select a stage and confirm its environment and target databases.
3. Inspect the task’s statement and current status. If the task already ran, expand its latest attempt to read the logs.
4. If you have rollout permission, use Run to start a stage that requires manual execution. Verify its results before continuing to the next environment.

For CI deployments, use the promotion job to continue the existing Plan. The example below shows a completed Rollout with one task in Test.

What result to expect

Not started means the task is waiting to run. Running tasks have active attempts; completed and failed attempts retain their results and logs. Check the task history when retrying work.

The Plan shows Deployed when its Rollout completes. Inspect task runs and Changelog: a Skipped task counts toward completion, but its SQL may not have executed.

Investigate an execution failure

Open the failed task run to read its error and logs. A failed attempt can leave partial changes, depending on the database engine and transaction settings. Confirm what ran before retrying or planning a rollback. A retry creates a new task run and preserves the earlier attempt’s logs.

Checks can pass while execution fails. For example, a database account may lack permission to alter a table; the database operator must resolve the reported privilege error before retrying.

Waiting tasks have not necessarily failed: rollout permissions, schedules, prior stages, or CI promotion may still be pending. See Rollout Policy and Scheduled Rollout for configuration.