Developers have been running schema changes directly against the production database at midday, causing lock waits and two brief outages this quarter. Management asks the DBA for a process fix. What should the DBA implement?

Release schedules are a change management control that defines when changes may be deployed to production, typically in maintenance windows chosen for low activity and adequate staff coverage. Schema changes often take locks on tables or rebuild structures, so running them at midday collides with user transactions and causes lock waits or outages. Requiring approved changes to be bundled into scheduled releases, tested beforehand and deployed in a window reduces impact and gives operations staff time to prepare rollback plans and monitoring. Granting developers DBA rights expands privileges contrary to least privilege and lets the same unscheduled changes cause more damage, since stopping other sessions to push a change through simply moves the outage onto other users. Testing a script on a laptop is better than not testing, but it does not reflect production data volumes, concurrency or configuration, and it leaves timing uncontrolled. Deliberately deploying during peak hours maximizes the number of affected users; having staff present does not reduce the locking impact on the business. Exam caveat: release schedules work alongside change approval, CI/CD pipelines and version control; emergency changes follow a separate expedited path rather than bypassing control. Operational check: publish the release calendar and window times, require change tickets for schema changes, restrict production DDL rights to the deployment process, and review lock waits after the next release.