一个配置管理员的困惑

  作配置管理快两年了，最近遇到了件很郁闷的事。前一段时间老总跟我说马上制作一个××项目当前成熟的版本给客户去试用，然后就走掉了。每次当我制作一套版本的时候都会遵循代码提交－收集－系统构建－安装－测试这样的基本流程去做。
  但是当我们费了九牛二虎之力终于出了一个系统软件版本的时候。有些开发人员跑过来跟我说：在你出版本的这段时间我们又增加了不少新的功能，你现在的版本是旧了，必须要把我们新加的功能加到这个版本中去。我当时就有些火了：“不是说好了在出版本的这段时期内除了修改测试发现的问题外不能再做其他的修改了，尤其不能再增加新的功能了，你们这样搞那我这个版本不是白出了吗？”。他们听我说完白眼一翻：“有意见找我们领导去，是他让我们加的。”，说完就走了。我去找负责该项目的经理，他却说没办法任务太紧张了，不可能停止开发的。
    我又跑去找老总：“能不能先把做好的这个版本交给客户先用到，有些功能下个版本再说”。他说：“不行啊，有些功能客户指明要的，你再重新出个版本吧”。我说：“出版本是要花时间的，就算我重新出一套版本，开发人员在我出版本的这段时间同时在开发，那我的版本怎么出啊？能不能等开发完了再出啊 ？”。老总说：“那不行，时间太紧了，我是想你们同步在做，你出版本的同时他们在开发，等开发一结束你的版本马上就出来了”。我说：“同步做可以，建两个分支，一条分支开发，一条分支查错。但是两个分支合并也不是那么容易的事，即使合并了也不代表这个版本就出来了，还是要进行代码收集、系统构建、安装、测试这样的基本操作的”。老总说：“不要给我讲什么术语，我不关心，总之你给我想办法，现在任务那么紧张，你要即不影响进度又要保证软件质量，做不到就扣你奖金”。说完就走了，只留下呆呆的我。
    当天晚上我来加班，抽了整整一包香烟。我不停的问自己：到底是我水平太低，还是领导的水平太低......？？？

配置管理员是不是管理人员，这个是一个问题。究竟什么人可以做配置管理员，这个也是一个问题。需要不需要一个专职的配置管理人员这还是一个问题。这三个问题构成的基础的企业配置管理策略，其他的任何手段都是受这三个基础原则约束的。就目前情况看，国内大多数运转良好的方式是这样的——配置管理员是技术人员，他主要负责配置管理系统工具的维护，提供配置管理系统的运行支持。配置管理人员一般都会选择经过培训的专职人员担任，其性质其实和网管类似。而项目内有自己的配置管理人员负责自己项目的配置管理工作，这个人绝大多数情况下是兼职的，多数情况是有技术负责人担负。
针对本贴的具体情况我认为，很多问题是制度上的，当然也有人的素质上的。首先我坚持每日构建是最低线，而这个帖子中说的情况看是没有做到的。
其次他们老总明确的说出一个xx项目成熟版本，那么究竟什么是成熟这个标准是谁制定的。按照这个帖子的情况看，貌似是配置管理员制定的。这是一个巨大的错误——任何版本的都需要经过开发者和质量管理者会同管理者共同评估，以制定究竟这个版本不是成熟的，还是需要测试的，还是可发布的，还是提供适用的。而当真正需要输出这个版本的时候，所需要做的仅仅就是一个make而已。
任何时候都不可能停止开发，除非这个项目要终结了。调节功能，添加或者修改以至于删除都是很正常的。关键在于用户的需要必须与之对应。因此对照上面的情况，除非是管理层经过同开发和QC会商之后已经确定某个版本将被冻结，并以此为基础构建一个发布版本，否则在此基础上的开发不会被终止。而一旦确定冻结，则需要有专门的开发人员负责维护此版本，以达到最终发布的标准。
持续集成，可以解决开发和除错的不同步问题，关键在于企业是否能够真心实意的采用这个敏捷的做法，而抛弃旧有的迟缓和不协同。

大约是你水平低。。。
因为领导是不会错的。
增加功能我们也作过
由于是正在运行的服务
（5*8的东西还不让停机）
只好把原来版本与新版本用company比较
所有的变化的class文件拷出来
拷到对应的目录之下。。。。
一宿作下来吐的心都有了。。。

现在的企业好像都存在这个问题,想处理好好像并不容易, 反正你上天班就是钱,如果觉得做的不爽,抓紧业余时间学习,然后看准跳槽

你的项目中，这个流程需要多长时间？

这样是不是太繁琐了？
系统构建可以让开发人员进行
来个每日自动构建好了

这样每天都是最新版本

我们的流程如果没有错误大约要二十分钟（）

不好意思，我是在问楼主。如果楼主也只要二十分钟，那就没有问题了。

项目经理那边的问题多一些。

我猜你们的项目应该是没有自动系统测试工具的，不然你也不会这么头痛了，否则通过简单rebuild就可以生成版本。

当然造成你最头疼原因o6z已经说明了。

在稍大一点的软件公司都有CM这一职位，它的基本职责就是对版本控制工具(CVS,VSS,CC/CQ等）日常维护，以及发布软件版本（main/patch)到测试环境和用户生产环境。
理论上讲，CM没有开发经验是没有关系的，但最好具备写自动化打包脚本的经验，如Ant，以及一些项目发布/管理等常识性问题。

LZ所说的只不过是重新打一个主干发布版本到测试环境，在我们公司，这一过程最多也就10分钟时间，你说所的安装是TS的职责，测试，那更是ST的职责了。
所以，LZ只要保证一个能够自动构建的脚本能够在很短的时间内将系统打成一个发布包就可以了

另外，这种频繁发布在实际开发中经常会遇到，这个与项目管理，需求变更，bug修复已经版本控制计划都有很紧密的联系，很难完美的解决，所以，还是在具体问题具体分析，但在工具层面，要做到尽可能的敏捷

PS:我不是很清楚LZ所谓的配置管理所涉及到哪些职责，我假设楼主只是单纯做配置管理，而不涉及到其他发布到服务器，以及软件测试的职责