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

If there are any warnings or errors, as long as you check Rollout anyway, you can still schedule the time.

After you schedule the rollout, it will be in the pending state. You can’t manually run it nor edit the SQL unless you click Cancel.

After clicking Cancel, you may edit the SQL and restart the rollout process either immediately or schedule it to a later time.

​

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.