• :L 监督 SQA、项目组的工作,文档入基线的情况,全部都与绩效考核能联系起来。功利性很强的数据。

  • 切!都不愿给点建议,我自己甩泥引路人。

  • 配置管理员工资 at 2010年03月04日

    SCM 刚干半年,现工资 2K 北京

  • 配置管理构建统计报告 at 2010年03月03日

    我发表下总结报告:进过 lz—15 楼的讨论,《构建统计报告》所能影响的范围,基本都介绍了,对公司的意义,也粗略的说明了。所以,一个研发型的公司,针对自己的项目构建,能有一张《构建统计报告》,对公司来说,能调动研发、测试、质量、以及管理部门的积极性(当然是将数据与绩效工资挂钩),对于公司长远的发展是个有利的因素。

  • 配置管理构建统计报告 at 2010年03月02日

    :lol 研发测试再分开,也有一个统一的领导,说明需求,利益。领导不同意,那就只能说 领导是个废物

  • 配置管理构建统计报告 at 2010年03月02日

    这个测试人员信息其实很好解决,只需要研发领导发话,测试人员对产品冒烟测试,并将冒烟测试结果,发给质量管理员,抄送给 SCM,这样信息就能统计了

  • 配置管理构建统计报告 at 2010年03月02日

    对了,我这里的统计对象,还包括,产品测试接手人员、测试结果、以及产品发布部署运维人员(针对的是持续维护的产品)以及 部署后的客户验证结果(一般由 公司内部测试人员充当客户,验证新的产品功能)。

    [[i] 本帖最后由 rexuekonglong 于 2010-3-2 13:44 编辑 ]

  • 配置管理构建统计报告 at 2010年03月02日

    9、10 项,对于公司统计,构建时间成本可能有用,不过对于研发人员<=100 人,感觉不必要。 11 项,其实没有必要,这个只需要在另一份《配置管理操作指导手册》中,针对项目标明就 OK。除非,项目相当多,build 超过 3 台的情况时,才适合标出。 12 项,涉及到公司无形财产安全问题,我感觉去掉不写为好。 17 项,可以填写 测试库\产品库 路径。

    目前,可以想到的就这些了,希望大家得出适合自己的统计表。

  • 配置管理构建统计报告 at 2010年03月02日

    目前的感觉,你的项目基本上全面了,大家可以根据自己公司规模,及上级要求严格程度,制作符合自己需求的统计报告,适量删减,对工作室一种理解与挑战

  • 切,你这就是 1 个大库,下分 2 个小库。实际上你随便在一个库下继续加小库(仅仅是增加文件目录层次而已)。不过这样下来,你的读写权限分配时就要更加谨慎了。

  • Subversion 备份 at 2010年03月01日

    :( 不是哇,你们这备份的不是用来防备系统崩溃的吗?难道可以,时不时还原一次?

  • "根本的是减少了客户的花费,让客户少花了钱" 纯粹扯淡, 只能说节约了公司成本,你不可能阶段性的和客户要求加钱的。不要在这里误导大家。——谢谢!

    今天我们也在讨论项目变更管理,结论是: 1、这属于管理方面 2、产品经理在项目变更时要合项目组、测试组开会评估工作量 3、在确定工作量后,确定变更流程

    :L 怎么过感觉好像,与配置管理没多大关系

  • 我也要进去,现在又好多问题都没地方找解决方法

  • 根据我半年 SCN 的工作经验,你怎么操作都无所谓(SVN),但是你必须写清楚操作信息,并且在每次项目构建(build)时,选择正确版本号,实际上也出不了差错。但是,这是理想状态,开发人员以时间有限为借口,乱写、简写、add、作为操作信息,在构件时,区分不了 正确的起始版本号,出错当然是肯定的。

  • 基线,基线库的困惑 at 2010年01月26日

    简单回答: 根据我所在公司的配置管理规定 新项目集成测试完毕,进入第一次系统测试(alpha)代码就应该进入基线库,成为主干(trunk),以后的版本都从 trunk 拉出,修改完成后,merge 主干,下一个版本继续从 trunk 拉出。 基于 svn 操作

    1、楼主所说的可能就是 CM 拿到的就是 tag 中的代码,然后构建,最后将构建成品给测试人员。 发布就是指 成熟的产品(release 产品),你可以在本项目配置库里建一个 release 库,专门存放成功发布的产品。 2、CM 当然是将构建后的产品给测试(除非是 PHP 项目,不涉及到构建工具,这样就只给文件) 3、变更流程从上到下进行,产品经理—质量管理员—CM—项目组 中间具体过程,根据你所在公司的部门结构而定。

    [[i] 本帖最后由 rexuekonglong 于 2010-5-24 13:28 编辑 ]

  • :lol 个人认为,只要多用鼠标刷新几次,有点耐心就好了

  • [原创] 关于版本管理 at 2010年01月07日

    :lol SVN 保留 tag,删除分支,觉得,可以考虑,毕竟 SVN 可以根据版本号 随意找出任何一个版本的代码。如果分支和 tag 都保留,感觉确实有点浪费资源。(毕竟在数据库中,增加 1 条 tag 的都是 N 大的数据存储量)其实仔细想想,一旦服务器数据库彻底报销,就是保留 N 个分支和 tag,数据如果都在一台服务器上,都是一样的结果——什么也没有

  • 代码的分支管理策略 at 2010年01月07日

    scmroad 于 2009-10-28 10:03 发表

    有个问题,就是,这样做开发的话,是怎么进行 merge 工作的?谁来做 merge? [/quote]

    实际上两种 merge 工作都可以由组织级 SCM 来做,但是,在座 merge 之前,必须得到项目经理的版本号确认,以及 SQA 的确定。这样,就能保证,merge 的版本是项目组需要的。

  • 再谈基线 by lihuashuecho at 2010年01月07日

    我新手, 感觉基线,就是一个定下来的模板,开发、测试都按照这个模板来,如果有新需求进入,才会有变更。就好像一个指标一样。