数据库版本管理工具Flyway(4.0.3)---介绍(译文)

时间:2022-01-26 18:18:02

Flyway

Evolve your Database Schema easily and

reliably across all your instances

简单的、可靠的升级(发展)你的数据库模式,通过所有你的实例。

Why database migrations?    为什么要进行数据库的迁移

First,let's start from the beginning and assume we have a project called Shiny and its primary deliverable is a piece of sofeware called Shiny Soft that connects to a database called Shiny DB.B

首先,假设我们我们有一个叫做Shiny的项目,这个项目最初的交付物是一系列的叫做Shiny的软件。这个软件连接到一个叫做Shiny DB的数据库。

The simplest diagram to represent this could look something like this:

最简单的去呈现这个关系的示意图是:

数据库版本管理工具Flyway(4.0.3)---介绍(译文)

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 translate into this:

但是在大多数的项目上,这个简单的场景很快转变成这种方式:

数据库版本管理工具Flyway(4.0.3)---介绍(译文)                                                       We now not only have to deal with one copy of our environment,but with serveral.This presents a number of challenges.

 我们现在不仅必须要处理一个我们环境的副本,更多的时候是处理好几个。这个将会是一个很大的挑战。

We have been pretty good at solving them on the code side.

我们已经有了相当好的解决办法在我们的代码上。

   ·Version control is now universal with better tools everyday.    版本现在普遍的被很好的工具每天控制着。

   ·We have reproducible builds and continuous integration.       我们有再生的创建机制和连续的综合机制。       

   ·We hava well defined release and deployment processes.       我们有很好的定义发布和开发的过程、

    数据库版本管理工具Flyway(4.0.3)---介绍(译文)

   But what about the database?                                         但是我们的数据库该如何控制呢?

    数据库版本管理工具Flyway(4.0.3)---介绍(译文)

Well unfortunately we have not been doing so well there.Many projects still rely on mannually applied sql scripts.

不幸的是我们这方面做的并不是很好。很多项目依然依靠人工去执行脚本。

And sometimes not even that(a quick sql statement here or there to fix a problem).And soon many questions arise:

并且有时候问题还不止这些(如何从这或者哪快速的收集脚本清单也将是个问题)。马上一些问题将会产生:

· What state is the database in on this machine?                                        数据库在这台机器上是什么状态?

` Has this script already been applied or not ?                                           这个脚本到底执行了没有呢?

`Has the quick fix in production been applied in test afterwards?                在测试环境中有快速解决生产中问题的吗?

`How do you set up a new database instance?                                           如何建立一个新的数据库实例呢?

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 :                                                                                   他们会让你:

`Recreate a database from scratch                                                            ·从错乱的情况下重新创建一个数据库

`Make it clear at all times what state a database is in                                  ·可以实时的清楚的目前数据库是个什么状态

`Migrate in a deterministic way from your current version of the database to a newer one       ·以一种确定性的方式迁移从当前版本的数据库更新