【PM】关于系统数据库和服务现场升级的一些看法

（1）公司开发环境的SVN为每个系统都维护一个系统目录。目录里面为每个Schema也建立一个Schema目录。每个Schema目录中都包括这样一些文档：“基于版本号X的数据库改动”。当中所有以SQL脚本的形式维护，记录了数据库的改动步骤以及改动人。

（2）系统文件夹的根文件夹以下维护一个文档，是当前现场的数据库各个Schema的版本，以及当前是谁在什么时候为其定版的。

就像以下一样：

在这个基础之上。假设下次你要出差，你所要做的事情就是：

查看当前用户现场的Schema发现各自是版本号25,26,26,26。那么你就到各自的目录以下。将相应的“基于版本号25的数据库改动”，“基于版本号26的数据库改动”，“基于版本号26的数据库改动”。“基于版本号26的数据库改动”这几个文件带上，到现场仅仅须要把文档里面的SQL脚本依次跑一下就可以。

文件中面还有是谁做的改动，这样你跑SQL脚本的时候有什么问题还能够打电话回来问相应的责任人。

然后你出差回来之后，你已经将这几个Schema升级了，所以你须要改动根文件夹以下的文档，进行定版：将相应的版本+1，然后定版历史注明谁在什么时候定版的。

然后还要到各自Schema的目录以下，建立新的文档。命名为“基于版本号X+1的数据库改动”。用于以后开发者记录在新的版本号上面所做的数据库改动。

这样不是非常方便么？

这种方法有一个原则，不能让不论什么人都有改动数据库的权限，要么仅仅有项目负责人来改动数据库，并在这里进行相应的记录，要么让改动数据库的人把SQL脚本发给项目负责人或者别人准们管数据库的人。来在这里记录。

总之。不论什么数据库的改动。须要让清楚我这个机制的人来允许。

2、关于服务升级

个人认为部署和升级服务最烦的就是配置项了（我们后台实用的是WCF服务）。

假设每次升级服务都要手动改动每一个服务的配置项明显不行。

我认为须要有一个统一的地方来进行全部服务的配置，即将整个系统的全部配置进行集中管理！！！

这就须要一个配置中心。整个配置中心维护了整个系统的配置信息。

（1）全部的服务在启动的时候訪问配置中心获取所需的配置项。

（2）现场部署人员能够通过简易的UI界面来操作这个配置中心，增删查改整个系统的配置项。

C#系统的话可能须要自己实现这么一个配置中心，前期能够仅仅做简单的一个节点的配置中心。

JAVA系统的话。能够使用开源的Zookeeper。能够作为集群来执行配置中心。

以上全然是个人在这样一家公司工作了将近一年之后的感受，即感觉到一些不好的地方。然后提出了自己的一些想法。

我的想法可能不是非常合理，这须要与更加成熟的公司的人进行交流才知道。

希望各位假设看了之后有想法和类似经验的，指教。小弟在此谢过。！

！！

【PM】关于系统数据库和服务现场升级的一些看法

标签：人工   命名   enter   手动   集中   为什么   font   统一   实用