09.结构化数据库如何持续交付笔记

 

--------------------------------------------------------------------------------------------------

应用程序VS数据库

 

 

 

数据可以理解为一个应用代码。

 

解决思路：

架构解耦：在应用程序和数据库对象之间形成单一可控的依赖路径

团队解耦：应用程序微服务化带来2 pizza team,团队/应用/数据库成为独立单元

自动化：形成所有环境上的数据库自动化持续部署能力；形成应用于数据统一的版本控制能力

 

------------------------------------------------------------------------

团队协作模式和架构演进

 

 

 团队解耦(微服务)

 

 

 DBA的职能和团队演化

 

 

 

应用DBA ：

l  负责特定应用程序的数据结构，数据库应用代码，初始数据应用代码，初始数据，业务数据的维护

l  协作开发，测试团队完成所需要的环境持续部署

l  敏捷/微服务演进过程逐步加入应用开发团队，成为职能团队的一部分

系统DBA:

l  负责数据服务器级别的系统稳定运行

l  需要具备各类数据库的高可用，宅被，备份恢复，打补丁，系统升级的能力

l  维护生产坏境数据的持续部署

l  云计算和PaaS平台演进过程中主键被平台能力替代

 

----------------------------------------------------------------------------------------------------------------

数据库持续交付流水线设计

*数据库制品分层

*数据库即——数据库配置管理

 

01.数据库的制品分层

 

 

 

02.示例：

 

 

 

示例：

 

 

 

 

数据库持续交付流水线

 

 

 

代码->持续集成->开发环境->测试环境->UAT/预生产->生产环境

代码：

l  数据库脚本入库

l  与应用采用同样的版本管理机制

l  通过分支策略，拉去请求控制数据库版本的统一和对其

l  为开发人员提供本地数据库独立部署能力

l  为开发人员提供Daily Build生成共享数据库

持续集成

l  持续集成(CI):

n  数据库脚本与应用代码一同打包

n  自动完成持续集成环境临时数据库的部署：数据结构、应用代码、初始数据，测试数据

n  自动完成数据库集成测试，使用持续集成环境临时数据库(数据会被污染)

n  理应Docher对数据库状态进行快照

 

l  持续集成(Daily build)

n  使用单日最终版代码

n  数据库脚本与应用代码一同打包

n  自动完成开发环境数据库部署：数据结构，应用代码，基础数据，测试数据

开发环境：提供Daily Build所部署的数据库提供开发团队作为数据库基线版本

测试环境：使用开发测试团队认可的制品版本进行部署

UAT/预生产：

l  在当前数据库版本基础上使用迁移脚本完成数据库升级

l  利用工具自动完成差异脚本的生成

l  必要时人工介入手工编写迁移脚本，比如：拆表，拆行

l  数据验证脚本编写和入库

l  回滚脚本并验证回滚过程

l  数据迁移脚本入库

生产环境：

l  在当前数据库版本基础上使用经过验证的迁移脚本完成数据库升级

l  数据验证

 

 

 

 

 

外部资源--->开发级--->测试级--->生产级--->制品库

PR触发的预构建->获取代码->编译->静态代码扫描->L1单元测试->发布包准备->Docker Build&Push

 

-----------------------------------------------------------------------------------

持续交付实施框架：