工作快满一年了，立即着手准备第二次出差去升级我们的系统，可是突然想到一件事情，让我颇有感触，是关于系统现场升级的。

我们迭代开发的系统隔一段时间就会须要到用户的现场去为其进行系统升级，当中升级包含client，服务端，以及数据库。

眼下我们的做法是什么？

升级服务的方法是，将带过去的新的服务全然替换掉旧的服务，然后人工改动全部服务的相关配置。

升级数据库的方法是。在自己的笔记本上面部署一套我们须要升级的版本号的数据库。然后到现场之后利用TOAD的schema的对照功能（我们用的是Oracle数据库）。逐个Schema进行对照，然后找出这些区别。手动将这些区别一个个在用户现场的数据库上进行改动，直到两个数据库一样为止。

并且非常多时候数据库的改动是针对一个功能的，可能建立触发器，job，序列，改动表什么的会存在一些先后顺序，假设不知道这些顺序就通过对照来升级。出错的概率非常大。

顺便提一句，我们的是CS系统。数据库中须要更新的改动包含表结构改动。元数据表的内容的改动，以及其它如序列，存储过程，触发器，Job等的改动。

好吧。我想说的是，服务数量和数据库涉及的Schema以及表的数量少一点的话还好，我们这样做还能应付，要是服务和数据库的Schema多了呢？

那就谁也不想出差了。出错的概率我感觉起码是90%以上，难道你还要搞完了以后现场驻扎測试3天？

个人觉得，我们为什么不这样做呢？

1、关于数据库升级

（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。能够作为集群来执行配置中心。

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

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

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

！！