Scheduled Rollout

When rolling out a change in Bytebase, you can choose to run it immediately or schedule it to a later time.

Best Practices

Role Responsibilities

Developers/Issue Creators:

• Create issues with migration scripts but do not handle rollouts directly
• If timing requirements exist, specify them in one or more of these locations:
  • Issue title (e.g., “DB Migration - Deploy during maintenance window”)
  • Issue description with detailed timing constraints
  • Labels (e.g., rollout:night, rollout:maintenance-window)
  • Comments explaining why specific timing is needed

Approvers/Releasers:

• Review rollout timing requirements provided by issue creators
• Determine the actual rollout schedule based on:
  • Business impact assessment
  • System maintenance windows
  • Traffic patterns and downtime considerations
  • Dependencies on other deployments
• Execute the scheduled rollout at the determined time

This separation of concerns ensures that developers focus on creating quality migration scripts while experienced operators handle the critical timing decisions for production rollouts.

Scheduling a Rollout

When you roll out a task, choose Schedule for later and pick a date and time — the task starts automatically at that time. Choose Run immediately to start it right away.

Whether a rollout can proceed when plan checks fail is governed by the rollout policy, not by scheduling.

After you schedule the rollout, the task enters the pending state and waits for the scheduled time — you can’t run it earlier. To stop a scheduled rollout, click Cancel.

After clicking Cancel, you can Restart the rollout and run it immediately or reschedule it for a later time.

The SQL statement is fixed once a rollout is created. Cancelling only stops the scheduled run — it doesn’t unlock the statement for editing. To change the SQL, create a new change.

Workflow Summary

1. Issue Creation:

   • Developer creates issue with complete migration script
   • Optionally specifies timing requirements in title, description, or labels
   • If timing is critical, provides justification for specific timing needs (e.g., maintenance window, low traffic period)

2. Review & Approval:

   • Approver reviews the migration script for correctness and safety
   • Validates timing constraints and business impact
   • Approves the issue once technical and timing requirements are satisfied

3. Task Execution:

   • By default, executes task immediately upon action
   • Releaser can choose to schedule the task for a specific time based on:
     • Issue creator’s timing requirements
     • Operational constraints (maintenance windows, traffic patterns)
     • Business impact considerations

This workflow ensures proper separation of responsibilities: developers focus on creating quality migration scripts, while approvers and releasers handle the rollout timing and execution decisions for production deployments.