Maintaining a version of a database opens a lot of possibilities, especially if an automated process can easily grab the current version, at runtime. You might, for example, have a routine that is only appropriate after a particular version. It is also very handy to be able to associate entries in an event log or bug report with the database version. The article describes various ways to get the current Flyway schema version from Flyway, and how to get it using SQL, in SQL Server, MySQL, PostgreSQL and SQLite. Read more
You can have Flyway up and running in minutes if you're a solo developer managing a single database. However, as you seek to 'scale up' Flyway to accommodate more complex database systems, team-based development, and stricter quality controls, you'll need to tackle some knottier questions. Without adequate answers, tasks such as multi-database management, automation and workflow, and Continuous Integration will be difficult. Hopefully, this article will help. Read more
This article explains how, by use of schemas and stub interfaces, we can use Flyway to manage the main development work smoothly alongside any changes or additions required to maintain production-only code. It also demonstrates how this mechanism enables Flyway to manage a 'mock' or 'dummy' variant of a production schema, in development, so that the team can still develop and test code that, when deployed, will access production-only features. Read more
A quick demonstration of using Flyway with Oracle, for those of a nervous disposition. We'll use Flyway to run some migrations on an Oracle Autonomous Database, building the initial version of the database then filling it with development data. Read more
Whatever development methodology you use, it is useful to have, and independently maintain, a separate schema within a database for utilities. These utilities are database objects that monitor the functioning and operation of the database, but aren't part of the database. This article demonstrates how to manage these utilities from Flyway so that we can maintain and migrate them separately from the database objects. Read more
If your database application requires 'static data' to function, then the best way to manage that data is using a view based on a derived table. This article demonstrates ways to create these views, depending on your RDBMS's capabilities, and how to build and manage them in development work, using Flyway and PowerShell. Read more
Flyway, especially Flyway Teams edition, can be used in several different ways to accommodate a database development that was originally based on builds rather than migrations. This article explores four different ways to use Flyway to build a particular version of a database, from the ground up, using a single migration script. It should help teams select the best way to incorporate Flyway into an existing database build system, during development, while benefitting from use of Flyway's versioned migration system for deployments and releases. Read more
How to get started with Flyway, as simply as possible, using PowerShell. This article provides a practice set of Flyway migration scripts that will build the original pubs database on either SQL Server, PostgreSQL, MySQL, MariaDB or SQLite and then migrate it from version to version, making a series of improvements to its schema design. Read more
Robert Sheldon helps you get started with Flyway Desktop by walking you through the process of creating a Flyway Desktop project for an existing database. It covers the basics of building a schema model, generating and running migration scripts, and saving changes to source control. Read more
Flyway provides a database-independent way for a team to track, manage and apply database changes, while maintaining strict control of database versions. It updates a database by running a series of versioned migration scripts, in order, and keeps track of all the changes in a special "schema history" table. It sounds simple, but it is easy to derail this team discipline if you don't find the right answers to the following questions… Read more
Flyway's approach to database migrations is based on strict versioning, but there is a limit to what a single process can do to prevent 'drift'. This article explains how drift can happen, and why you also need source control and external processes that log changes, to prevent it. Read more
Database versioning brings more control to team-based database development and helps avoid many of the errors that often creep into database delivery. This article explains all the requirements of a semantic versioning system for databases, from specifying the format of the version numbers, to deciding where to store them and how to process and compare them. Read more
This article describes a route to adopting Flyway in order to bring management and control to a chaotic database development process. It is based on use of Flyway migrations to update a database from version to version, while maintaining object-level source scripts for tracking changes between versions. Read more
Flyway uses a schema history table to track the version of each database, recording in it every versioned migration file applied to build that version. It's worth understanding exactly how Flyway uses this table, the possible dangers of moving it to a non-default location and how to do it safely, if required. Read more
How Flyway Enterprise will help you ensure that databases and applications can grow and develop in step, and to implement a workflow for delivery of database changes that is resilient, repeatable, fast and visible. Read more
Phil Factor explains how to get started with Flyway, as simply as possible, using PowerShell. This article provides a practice set of database automation scripts that will build a SQL Server database, and then update it, running a series of migrations scripts that make some schema alterations, and load the database with test data. Read more
This article describes the principles of using Flyway migrations to build a database from scripts, to a specified version, and to track, manage and apply all database changes. Read more