> ## 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. # Plan > Define database work and follow its checks, review, and deployment in one place. A **Plan** is the main record of database work in a project, from preparation through deployment. It defines the work and its targets and links the review and execution records. For schema or data changes, it stores SQL or a reference to a Release. The Plan keeps its identity throughout the change. For example, a Plan can add a column to an application's Test and Prod databases and track deployment to each. Changes to existing databases target those databases; a Plan that creates a database targets its instance. ## Plan, Issue, Release, and Rollout These resources describe different parts of the same change: | Resource | Responsibility | | ----------- | ------------------------------------------------------------- | | **Plan** | Defines the work and targets, and tracks the whole change. | | **Issue** | Records a request's review, discussion, and approval. | | **Release** | Supplies a saved, immutable package of SQL files. | | **Rollout** | Groups execution tasks into stages and records their results. | A UI Plan usually stores SQL entered in Bytebase and has a linked Issue for review. The GitOps workflow creates a Plan from a Release after pull-request review and CI checks, without a Bytebase Issue review step. Both workflows use Rollouts to track execution. UI changes use a Plan with SQL checks and a linked Issue; GitOps reviews files in Git and CI before creating a Release-based Plan; both use Rollouts ## Create a Plan For a schema or data change, open your project's **CI/CD → Plans → New Plan**. With change-creation permission, select the target databases, enter SQL or use **Schema editor**, and give the Plan a descriptive title. Click **Create** to save the Plan, start automated checks, and create its linked draft Issue. In this example, a saved Plan proposes adding `employee.nickname` in `hr_test`. The checks have finished, but the SQL has not run. A saved HR Plan shows its SQL, target database, successful checks, and Ready for Review button For GitOps, the deployment job creates a Plan referencing a [Release](/concepts/release) and the selected targets. Follow the [GitOps tutorial](/gitops/migration-based-workflow/tutorial) for that workflow. Database creation uses **Create Database**; see [Database](/concepts/database#how-a-database-appears-in-bytebase). ## Follow review and deployment Open the Plan from **CI/CD → Plans**. **Changes** shows the proposed work and, for UI changes, automated checks. **Review**, when present, shows the linked Issue's approval flow and discussion. **Deploy** shows the Rollout and its task results. For a UI change to existing databases: 1. Inspect the SQL, targets, and check findings. After an edit, read the updated results. 2. Click **Ready for Review** to submit the draft Issue. Approval rules determine whether a reviewer decision is required. 3. Once approval is satisfied and checks finish without errors, Bytebase automatically creates the Rollout. 4. Follow execution in **Deploy**. Manual environments wait for **Run**; automatic environments execute according to rollout policy. The Plan shows **Deployed** when the Rollout completes. Inspect the task results to confirm what executed; a skipped task can also count toward completion. See [Rollout](/concepts/rollout) for task states and retries. For authoring, submission blockers, and deployment steps, see [Plan authoring](/change-database/plan) or the [UI tutorial](/tutorials/first-schema-change).