Flyway

One area hasn’t benefited from the DevOps movement as much: The database change process. It’s time to bring CI/CD to the database. Application release technology has come a long way in the past several years. It used to take weeks or even months to release new software. Now that organizations have adopted new workflows and processes, the time it takes to complete a release has been reduced to days and even hours. Database schema migrations are an essential task for every software project. There are several different reasons why updates to the database are required. New features require new attributes in existing tables or entirely new tables. Bug fixes may lead to changes in names or data types in the database. Performance issues that require additional indexes in the database. Even in organizations that have adopted DevOps, manual rework is the norm when it comes to database schema and stored procedure changes.

Sensible database-native change management for framework-free development and dependable deployment. What makes Sqitch unique among database migration frameworks. Binary and source code downloads and installation instructions. Command references, tutorials, best practice guides, and more. Get help, get involved. Issues, mail list, and source repository. Sqitch is not tied to any framework, ORM, or platform. Rather, it is a standalone change management system with no opinions about your database engine, application framework, or development environment. Database changes may declare dependencies on other changes — even changes from other Sqitch projects. This ensures proper order of execution, even when you’ve committed changes to your VCS out-of-order. Sqitch manages changes and dependencies via a plan file, and employs a Merkle tree pattern similar to Git and Blockchain to ensure deployment integrity. As such, there is no need to number your changes, although you can if you want.