> ## Documentation Index > Fetch the complete documentation index at: https://docs.bytebase.com/llms.txt > Use this file to discover all available pages before exploring further. # 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](/concepts/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. An HR Rollout groups the hr_test task in Test and the hr_prod task in Prod; both targets were selected in the Plan ## 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](/concepts/database#how-a-database-appears-in-bytebase). In [GitOps](/gitops/overview), 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. A completed plan shows Deployed, a successful Test stage, the database task, and the latest execution logs. ## 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](/change-database/change-history): 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](/change-database/environment-policy/rollout-policy) and [Scheduled Rollout](/change-database/scheduled-rollout) for configuration.