Share your experience with Database DevOps by taking part in the 2021 State of Database DevOps survey Take the survey
First, let's start from the beginning and assume we have a project called Shiny and its primary deliverable is a piece of software called Shiny Soft that connects to a database called Shiny DB.
The simplest diagram to represent this could look something like this:
We have our software and our database. Great. And this could very well be all you need.
But on most projects, this simple view of the world very quickly translates into this:
We now not only have to deal with one copy of our environment, but with several. This presents a number of challenges.
We have been pretty good at solving them on the code side.
But what about the database?
Well unfortunately we have not been doing so well there. Many projects still rely on manually applied sql scripts. And sometimes not even that (a quick sql statement here or there to fix a problem). And soon many questions arise:
More often than not the answer to these questions is: We don't know.
Database migrations are a great way to regain control of this mess.
They allow you to:
© 2010-2020 Redgate. Made with in Cambridge.
Flyway is a registered trademark of Red Gate Software Ltd.
All other trademarks, trade names, logos or service marks mentioned on this site belong to their respective owners.
This site collects anonymous usage information through Google Analytics.