Before hiring more developers or buying another delivery platform, look at how long completed work waits to reach customers. When database changes require a separate process and someone to run them by hand, more development capacity may not bring launch dates forward.
The business has already paid for the development. While the feature waits, its expected revenue or operational savings wait too.
Where the cost shows up
Consider a customer portal update involving four applications and their databases. Development is finished, but the database changes need coordinating across specialists and maintenance windows. Some preparation is necessary. The question is how much time goes into assessing risk, and how much goes into arranging handovers.
When every release takes that much effort, teams have a reason to bundle changes. Completed features wait for unrelated work, and problems become harder to isolate. Smaller releases make it easier to identify and correct failures.
Meanwhile, experienced database specialists spend time executing approved scripts instead of improving performance and reliability.
This affects delivery forecasts too. A project can look on schedule in development reports while the database work has a separate queue. Business launch dates need to account for both.
Bring the database into the release process
Redgate Flyway allows database changes to follow the same automated process as application changes. Teams store changes as versioned scripts in source control. Flyway applies pending migrations in order and records what has run against each database.
Database specialists can review changes during development, with approved execution handled by the pipeline. Problems can be addressed earlier, and deployment no longer depends on someone manually working through a set of instructions.
Teams using GitHub should also look at Redgate's Flyway Actions, released earlier this year, which provide reusable steps for checking and deploying database changes.
Keep control over production
Flyway Enterprise can detect unexpected structural changes in production, such as an emergency fix never recorded in the release process. A properly configured pipeline can stop for investigation before deploying.
Flyway also offers previews of planned changes and automated code checks, depending on the edition and database platform. These give reviewers evidence to assess before approving a deployment.
Required approvals and access restrictions should remain in place. Agree who can approve changes, how emergency work is recorded and where the approval and deployment records are kept.
Large data conversions still need rehearsal, and some operations will need downtime. Automation does not remove the need for specialist judgement or a recovery plan.
Make the case with one application
Start with an application where database work regularly delays delivery. Bring the application and database teams together to establish the starting point, resolve differences between environments and automate the next changes.
Measure waiting time, manual effort and deployment failures over several releases. Include licence and implementation costs when assessing the return. Look for shorter waits and less manual work without an increase in incidents.
A useful first result might be a routine change reaching customers this week rather than waiting for next month's maintenance window.
Masterminds is a longstanding Redgate Gold Partner. Our DevOps and Data teams work together on the initial assessment, automation and first deployments, including the review and exception processes production teams need.
Book a conversation to review a recent delayed release and assess whether database automation would have changed the outcome.
