现代软件开发的一个非常大的挑战就是在复杂的协作环境下，还能保持各部分工作产品的完整性和正确性。按时的发布一个正确版本，对软件配置管理员来说，成为一个越来越严峻的挑战。经常是：一个版本已经到发布时间了，该版本是否有存在错误，导致各部分无法集成而使得版本发布失败；该版本是否已经正确实现了版本功能。这些可能影响版本发布的异常情况都还无从知道，导致版本发布失败。
为了解决大项目的集成问题，现在的开发方法趋向于通过每日构建甚至持续集成，来快速获得软件系统中的错误反馈，迅速消除，使得一些小错误不至于到了版本集成时，因为系统的庞大而难于排查，严重拖延版本发布时间。
而要保证版本正确实现了实现规划的所有功能，则需要靠各种流程进行辅助，比如项目计划的安排，变更控制。为了正确的发布版本，需要配置管理员能轻松的从这些流程中获得信息，并做出决策。

DSTP做为一个项目协作平台，为版本发布和集成提供了相应的解决方案：一个是基线和版本发布支持流程，帮助配置管理员正确发布版本；一个是集成服务器，帮助实施每日构建或者持续集成，尽早发现项目中的错误。

基线和版本发布支持
文件状态
DSTP以文件目录方式统一管理所有项目工作产品，包括SVN文件和需求测试计划等。所有工作产品都有一个相同的属性：状态。
DSTP的文件状态支持以下几种：新建、评审、基线、变更中、变更跟踪、变更结束。
新建：工作产品的初始状态。
评审：工作产品在评审后，系统把状态修改为已评审(暂未处理)。
基线：不处于变更中的工作产品，经过确定，配置管理员可以设置为基线状态。
变更中：所有已经基线过的工作产品，如果有修改，则系统修改文件状态为变更中。
变更跟踪：某个工作产品已经修改完成，但相关的同步变更还没完成，则系统修改文件状态为变更跟踪。如修改需求文档完成，但和需求相关的代码或者测试计划还没修改完成。
变更结束：当作用于某个工作产品的变更流程结束后，系统修改文件状态为变更结束。如果有多个变更同时作用于没个工作产品，则只有产生变化的所有变更流程都结束后，文件状态才会变为变更结束。

配置项管理
配置项就好像是软件的物料清单，规定了一个完整的软件系统必须包含哪些部分，需求设计文档，用户文档，用户手册......
DSTP的工作产品管理以文件目录方式统一管理项目中的所有工作产品，包括SVN中的文件或者是需求测试计划等条目类信息。DSTP允许项目管理员直接把某个文件目录设置为配置项。当一个目录被设置为配置项时，该目录下的所有文件自动归属于该配置项。系统能导出当前项目中设置的所有配置项。
从配置项的作用来考虑，DSTP鼓励配置管理员在项目开始时就直接创建出所有工作产品的目录结构。这些初始的目录结构，就是项目配置计划中要规定的项目输出。是的，当项目管理员在一个文档中辛辛苦苦的定义各种各样配置项，为什么不更简单点，把这些配置项直接表现出来，在需要时再让系统自动生成相应的文档呢。只要对版本文件的创建和删除权限进行适当的控制，完全可以保证最后的项目结构和初始的计划一致。在通过流程修改了相应的目录文件信息后，也相当于直接修改了配置计划。

基线发布
在合适的时候，配置管理员可以对部分工作产品进行基线。基线时，系统自动列出指定项目的所有配置项，配置管理员可以选择部分配置项来进行基线。系统将会修改相应的文件状态。
但在基线化时，系统会先进行检查。只有所选配置项包含的所有工作产品状态都没有处于变更中才允许基线，保证基线产品是一个稳定和正确的版本。

创建版本
和基线一样，配置管理员可以选择项目中指定的配置项组成一个版本。配置项是直接针对项目中的目录，如果存在多版本分支的项目，则每个分支版本都应有相应的目录分支。一般版本管理工具都允许建立分支。
配置管理员可以在集成服务器中设置相应的版本发布流程，并在创建版本时选择相应的发布流程。版本发布时系统会通过集成服务器自动运行该流程。
版本创建后，变更管理模块就可以看到并使用该版本标记。

发布版本
在合适的时候，配置管理员可以发布版本。
发布版本时候，DSTP将自动进行一系列检查，以保证版本中各配置项的正确。
1. 系统首先锁定版本管理工具，避免有人在发布过程中修改。
2. 检查版本中指定的各配置项，只有各配置项的状态都是基线或者变更结束的才允许发布。也就是说，当相应配置项还未基线或者还处于变更中，则版本是不允许发布的。和基线的差异是，版本可以看作一个大基线，它要求指定的工作产品都要保持一致，而基线则待基线部分正确。因此基线时，允许工作产品处于变更跟踪状态，而版本发布时，不允许工作产品还处于这种状态。
3. 根本版本发布流程，DSTP的集成服务器启动版本发布：自动从版本管理工具获取版本，构建版本，集成和测试，打包，上传或者部署到指定位置再自动解除对版本管理工具的锁定。
4. 利用DSTP的查询功能，配置管理可以从任务或者变更系统中生成获得该版本的changelog。

集成服务器
目前可用的集成服务器有很多种， DSTP也对持续集成提供了支持。和一般的集成服务器相比，DSTP的集成服务器具有如下特点：
1．通过图形界面设置集成命令，简单清楚。一次集成允许设置多条命令，命令运行顺序允许为并行或先后串行，组成一个完成的集成流程。
2.  能够同时管理多台集成客户端，把命令按顺序发到指定机器进行执行。简单的说，同时兼有CruiseControl和STAF的功能，为复杂环境下的编译和测试自动化提供了完善支持！
3. 下发命令时选择的客户端，允许在命令中直接设置，也允许服务器根据在线客户端自动选择！为超大项目的集成和构建提供了极好的支持！
4．允许设置在集成结束/失败/成功/部分失败中某种情况发生时，自动向指定人员发送集成报告。在集成报告中，失败的环节，自动以显眼的红色给予提示；自动显示错误信息，甚至包括哪行代码出错。
5．可以设置集成周期，如每日/周/月/，或者每隔固定分钟后自动启动集成。周期集成的最小周期为分钟！
6．为持续集成提供支持。系统和SVN集成，可以自动感知SVN库的变化。可以设置当SVN每次修改后，就自动启动集成。在集成失败，自动向代码提交人和指定的项目人员发送报告，催促迅速更正，保证代码随时可用

集成报告格式如下

在报告中，列出了本次集成各命令的运行时间，以及运行结果. 对于失败的命令，会以红色显目提醒。
点错误信息查看，系统会自动显示本次集成的错误信息。

从错误信息可以看出，在test.c的第四行出现了错误。