背景

软件发布过程中最困难的就是数据库变更的发布。Datical 是专注于数据库变更发布产品的公司，Datical 可以帮助企业快速上线数据库的变更，软件软件发布更加自动化。

痛点

在 DevOps 的时代，软件发布的速度可以很快，而数据库的变更速度却跟不上软件发布的速度。

当前的数据库变更方式已经过时，数据库的变更存在以下问题：

1.依赖人工修改。


2.速度慢。

3.风险大。

上图是一个研发人员需要提交数据库变更到生产环境时，DBA 们的表情。

如果你邀请团队的 DBA 参加 Scrum 会议，那么画面会是这样的：

从各个公司的实际情况来看，也是基本符合这个情况，数据库的变更依赖人工操作，且风险大。我甚至不止一次的听说某公司程序员将生产环境数据库 Drop 掉的案例。

亚马逊公司在评估团队效率的时候，只看重一个数据，就是软件功能从需求变成线上服务的响应时间。很多公司包括互联网公司，在提交数据库变更时，都会提交一个 Ticket 给 DBA 团队，其实应用已经写好很久，但就是非得等到 DBA 处理这个 Ticket 之后，才能上线。这种情况其实是延长了业务需求到功能上线的响应时间，延长了软件研发投入变成公司利润的时间。

给程序员灌输一个理念，开发不仅仅是在本地和测试环境完成了测试，开发的职责就完成了，而是要负责到将数据库的变更正确上线，应用部署被顺利到生产环境，且用户访问不发生异常，才能算是一次成功的代码提交。

将数据库的脚本版本化存储起来，和应用程序一起管理。

Datical 带来了他们的最佳实践：

1.应用程序所有的依赖（包括数据库变更）都提交到通一个代码管理库里进行管理-例如 Artifactory 的 VSC 仓库。


2.使用 CI 工具上传构建信息



a.选择 Jenkins，TeamCity，TFS，Bamboo 作为 CI 服务器。



b.将制品上传到 Artifactory。



c.通过浏览器可以直观的看到所有制品。



d.版本化所有脚本。


3.为所有制品添加 Key-Value 的元数据进行版本化。

每次构建，必须将数据库的变更脚本也和应用一起发布，这样才能做到完全自动化的上线应用。

上图是 Datical 软件发布包的截图，它们的用户可以直接下载，安装。发布包里包含了该软件所对应的所有配置文件和数据库脚本。

Datical 认为软件开发团队必须建立良好的数据库标准，在提交数据库变更时要设立较高的门槛，落地一些数据库的最佳实践。

好的数据库标准包括：

1.在一个索引里不能增加太多列。

2.在一个表里不能增加太多索引。



3.外键都应该有索引。



4.不滥用数据库字段空间。例如 VarChar2（100000）


5.不滥用数据库的某些关键字，例如 Trancate，Drop，Grant。

在微服务的时代，我们可以实现灰度发布，将新服务上线的同时，保留老的服务。

在新服务运行一段时间之后，如果用户反馈监控没有异常，再将后端的老版本服务下线。

如何在数据库层面支持灰度发布？来看一个例子：程序员设计了一个丑陋的列，Name 里面包含了用户的名和姓（Giacomo Guilizzoni）。

上线之后产品经理提了一个需求，需要按照用户的 LastName 排序，程序员蒙圈。于是决定将 Name 列拆分为两列 FirstName 和 LastName。但这样并不可行，因为数据库变更上线之后，老版本的服务没法用了。于是程序员决定在前面加两列，FirstName 和 LastName。

这种方法实现了老版本 APP 的兼容，同时也可以上线新的服务，不间断的为用户提供服务。

等待新 APP 上线之后，处于稳定的状态，即可将老的服务下线，然后进行数据库的变更，将 Name 字段去掉。

实现 DevOps 需要整个研发团队进行思想上和行为上的转变，包括开发人员有义务参与端到端的部署，提交代码就走人的模式已经被淘汰。数据库的变更不能依赖于给 DBA 提交 Ticket，而需要在提交数据库变更时多参考 DBA 的建议，为整个研发团队建立数据库变更的标准，同时将配置文件，数据库脚本和应用程序一起打包，版本化，实现自动化部署。这样数据库的变更才不会成为软件发布的瓶颈。

原创：王青

背景

软件发布过程中最困难的就是数据库变更的发布。Datical 是专注于数据库变更发布产品的公司，Datical 可以帮助企业快速上线数据库的变更，软件软件发布更加自动化。

痛点

在 DevOps 的时代，软件发布的速度可以很快，而数据库的变更速度却跟不上软件发布的速度。

当前的数据库变更方式已经过时，数据库的变更存在以下问题：

1.依赖人工修改。


2.速度慢。

3.风险大。

上图是一个研发人员需要提交数据库变更到生产环境时，DBA 们的表情。

如果你邀请团队的 DBA 参加 Scrum 会议，那么画面会是这样的：

从各个公司的实际情况来看，也是基本符合这个情况，数据库的变更依赖人工操作，且风险大。我甚至不止一次的听说某公司程序员将生产环境数据库 Drop 掉的案例。

亚马逊公司在评估团队效率的时候，只看重一个数据，就是软件功能从需求变成线上服务的响应时间。很多公司包括互联网公司，在提交数据库变更时，都会提交一个 Ticket 给 DBA 团队，其实应用已经写好很久，但就是非得等到 DBA 处理这个 Ticket 之后，才能上线。这种情况其实是延长了业务需求到功能上线的响应时间，延长了软件研发投入变成公司利润的时间。

给程序员灌输一个理念，开发不仅仅是在本地和测试环境完成了测试，开发的职责就完成了，而是要负责到将数据库的变更正确上线，应用部署被顺利到生产环境，且用户访问不发生异常，才能算是一次成功的代码提交。

将数据库的脚本版本化存储起来，和应用程序一起管理。

Datical 带来了他们的最佳实践：

1.应用程序所有的依赖（包括数据库变更）都提交到通一个代码管理库里进行管理-例如 Artifactory 的 VSC 仓库。


2.使用 CI 工具上传构建信息



a.选择 Jenkins，TeamCity，TFS，Bamboo 作为 CI 服务器。



b.将制品上传到 Artifactory。



c.通过浏览器可以直观的看到所有制品。



d.版本化所有脚本。


3.为所有制品添加 Key-Value 的元数据进行版本化。

每次构建，必须将数据库的变更脚本也和应用一起发布，这样才能做到完全自动化的上线应用。

上图是 Datical 软件发布包的截图，它们的用户可以直接下载，安装。发布包里包含了该软件所对应的所有配置文件和数据库脚本。

Datical 认为软件开发团队必须建立良好的数据库标准，在提交数据库变更时要设立较高的门槛，落地一些数据库的最佳实践。

好的数据库标准包括：

1.在一个索引里不能增加太多列。

2.在一个表里不能增加太多索引。



3.外键都应该有索引。



4.不滥用数据库字段空间。例如 VarChar2（100000）


5.不滥用数据库的某些关键字，例如 Trancate，Drop，Grant。

在微服务的时代，我们可以实现灰度发布，将新服务上线的同时，保留老的服务。

在新服务运行一段时间之后，如果用户反馈监控没有异常，再将后端的老版本服务下线。

如何在数据库层面支持灰度发布？来看一个例子：程序员设计了一个丑陋的列，Name 里面包含了用户的名和姓（Giacomo Guilizzoni）。

上线之后产品经理提了一个需求，需要按照用户的 LastName 排序，程序员蒙圈。于是决定将 Name 列拆分为两列 FirstName 和 LastName。但这样并不可行，因为数据库变更上线之后，老版本的服务没法用了。于是程序员决定在前面加两列，FirstName 和 LastName。

这种方法实现了老版本 APP 的兼容，同时也可以上线新的服务，不间断的为用户提供服务。

等待新 APP 上线之后，处于稳定的状态，即可将老的服务下线，然后进行数据库的变更，将 Name 字段去掉。

实现 DevOps 需要整个研发团队进行思想上和行为上的转变，包括开发人员有义务参与端到端的部署，提交代码就走人的模式已经被淘汰。数据库的变更不能依赖于给 DBA 提交 Ticket，而需要在提交数据库变更时多参考 DBA 的建议，为整个研发团队建立数据库变更的标准，同时将配置文件，数据库脚本和应用程序一起打包，版本化，实现自动化部署。这样数据库的变更才不会成为软件发布的瓶颈。

原创：王青