我们都知道，开发系统最好是建立在一个稳定的平台上进行，这样既可以提高开发的效率，又可以把大量的共性问题集中在平台上解决，降低系统的BUG，提高稳定性。

由于系统的发布不仅仅是系统的可执行程序，还包括一些系统的配置数据。但是我们在系统发布的时候，通常会遇到这样的情况，在完成系统的发布后，系统也许还会持续的开发，因为持续开发后可能会继续在平台中部署新数据，所以，开发人员就直接在发布的平台上新增数据，久而久之开发平台逐渐和发布平台合在一起，开发环境不能和发布环境完全分开。

为了能使开发环境和发布环境分开，使开发人员可以和发布的环境脱离，我们可以采取几种方式：

分别发布：保证发布环境为最新环境，系统发布后，如果需要开发，则将最新的发布版本（程序和数据）重新部署到开发环境中，开发完成后，在正式环境中再部署一次。此方法目前较为通用，但是遇到的问题也不少，因为正式发布完成后可能需要进行再测试来保证发布到正式环境中的系统不会有BUG。

增量发布：大多成品软件会采用这样的方式来进行发布，发布将程序和数据分别进行，程序的增量发布相对简单，只需要对程序进行版本控制，就可以实现。数据的增量发布相对就复杂许多。我们将重点分析数据发布的问题。

表设计保障增量数据

数据发布必然会设计数据库表，单表比较简单，多级表就相对复杂一些。对于数据表，重点在于表的主键的设计，有几种表主键的设计方式，可能大家在设计的时候都曾经使用过：

业务编号作主键：比如说发票编号做主键的方式。

自动编号主键：sqlserver中典型的是自增长编号，oracle中为seq来自动添加；

Max加一：缺点较多，已经渐渐退出主键的范畴。

GUID主键：由GUID来担任主键。

GUID为主键的方式来建立数据表，这样的方式可以保持每条表记录的唯一标识别，在测试环境和发布环境的不同数据库中，增量数据可以通过GUID来识别增量的数据信息。

系统数据和业务数据分离

在平台设计时，还需要考虑将系统配置数据和业务应用数据分别开来，比如UnionONE中的T_APP的表，SDP中角色SDP_RULE中的数据，都是将平台配置数据和业务数据分开的方法。如果在平台设计的时候，对系统配置信息控制为只能新增和废除，保证增量数据能够很好的从以老版本中剥离出来。便于新数据的发布。

行记录的版本控制

当数据进行修改后，行记录进行版本登记，可以使用类似SVN的版本控制方式，把数据库中的每条记录都作为一个文件来看待，每次修改后，文件版本自动变动，以便正式和测试环境的数据库能够区分出哪些记录没有变动过，哪些变动过。例如可以使用时间戳来标记数据记录。

当然，这对于较为复杂的多级表结构的数据发布还需要研究更为有效的方法，在这里我只是提出一个话题，希望大家能够集思广益，最终有效的解决开发环境和发布环境的分离的问题。