简单而言，构建和发布管理的目的有三个：确保软件构建是可重现的、高效的、和可维护的。在小型的软件开发项目中达到以上三个目标并不困难，但随着开发团队、软件规模、软件复杂性的增长，以上的三个目标已经成为一种挑战。

典型的构建和发布管理包括以下几个步骤：

步骤一：确定参与构建的全部资源（如源代码、库文件、配置文件等）的正确版本；

步骤二：基于步骤一中选定的正确版本创建一个干净的仅仅用于构建目的专用工作空间，这里“干净”意味着该工作空间中没有多余的文件/目录，不存在旧的中间文件，所有文件应该是只读的，不允许进行检出和修改；

步骤三：执行构建过程，并对构建过程进行审计。审计信息包括但不限于：谁执行的构建？什么时候执行的构建？构建生成的可执行文件或库包含哪些内容？执行构建的机器是什么？机器上运行的操作系统版本是什么？执行构建使用的是什么编译器？使用了编译器的哪些选项？等等。构建审计是确保构建重现性和可维护性的有力保证。

步骤四：对构建和审计过程中产生的导出文件（Derived objects）进行版本控制。这一点很重要，正是这些导出文件构成了软件发布的重要组成部分。

步骤五：为业已受控的导出文件建立基线。

步骤六：生成软件发布介质。

构建的高效依赖于对导出文件在多次构建中的共享，通过避免反复生成同样的导出对象来大大缩短构建的时间。

不错， 值得学习， 感谢楼主

四个字：
言简意赅！

构建应该在什么阶段实行,开发阶段做每日构建有必要么?

请问CC里面是如何实现构建管理的?能否大概描述一下具体的工具或者命令,有步骤就更好了呢

对，迫切想知道cc这类工具里面是怎么实现构建管理的。

值得学习

IBM 软件配置管理 白皮书 中有讲到，建议大家都看看：
http://www-900.ibm.com/cn/softwa ... software_manage.pdf

引用:

原帖由 懂你 于 2007-2-10 23:26 发表

步骤四：对构建和审计过程中产生的导出文件（Derived objects）进行版本控制。这一点很重要，正是这些导出文件构成了软件发布的重要组成部分。

那么请问，构建后发布的软件版本应该如何标识和控制．

对于发布的构建版本，我们需要进行有序的管理，用版本号来唯一标识每一个发布版本。一般可以把用于开发团队内部系统测试的称之为内部发布版本，把提交给客户的称之为外部发布版本。
内部发布版本：在版本号前加Build；如Build 1.00.00；
外部发布版本：在版本号前加Release，如Release 1.00.00。

我是如上标识的．但是有同事问测试有好几个阶段，如集成测试--》系统测试-->α测试--》β测试这几个测试阶段，版本标识应该如何标识？？

我定义的规则内部发布就用：Build 1.00.00，之后每改一次就累加。所以集成测试和系统测试的版本标识就是从Build 1.00.00开始的，对于α测试、β测试都是在客户现场完成的，要对外发布，所以版本号应该从Release 1.00.00开始。

对于我的这种理解和解释，大家有什么高见。因为另外一个配置管理员始终搞不明白这两者的区别，我怎么解释她都认为没必要这么复杂，只要正式发布版本好即可。

请各位谈谈你们的高见，帮助指导，谢谢。

请问构建和发布管理在CC中具体是如何实现的?是基线和分支的方式吗?