软件配置知识分享
  • IBM CDL--宁波 / 无锡--招聘 SCM at 2012年06月26日

    有对个职位感兴趣的同学,赶紧联系我哈! 这个是 IBM 正式员工的职位,一年 14 月薪水,办公环境很好。

  • linux 命令大全 at 2010年08月20日

    不错，很实用的命令。

  • CMMI 介绍 PPT 文档 at 2010年03月30日

    谢谢,很精辟!

  • deliver 错误 at 2010年01月19日

    please to check current for no check out element

  • SCM Administrator 惠普公司 at 2010年01月14日

    上面没有联系方式?

  • SCM Administrator 惠普公司 at 2010年01月14日

    谁帮我推荐,推荐..

  • Senior Engineer, Build & Integration- 北京 Nokia at 2010年01月12日

    可以试试.

  • 修改组件的名称，怎么让客户端也更新到？ at 2010年01月12日

    如果是 UCM,重新 monut, base 重新修改 load rules

  • Clearcase 是否适合敏捷开发？ at 2009年12月27日

    UCM 在设计时遵规 RUP 的思想,RUP 是可裁剪的. 个人认为 UCM 是适合敏捷思想的

    有兴趣可以交流这方面的思想.

  • ClearCase 免费在线培训课程 at 2009年12月27日

    这个教程不错,有兴趣可以看看.

  • Rational ClearCase 操作指导——环境搭建 For Windows at 2009年12月27日

    初学者,照着学一遍,可以在概念级别和实践级别认识一下 CC

  • clearcase 命令 at 2009年12月27日

    规范你可以参考一些配置管理的模板,具休的实施还要要根据公司的具体情况来确定.

  • clearcase 命令 at 2009年12月27日

    真正做好配置管理的关键在人 CM 对配置的理解及责任和高层的支持!

  • 欢迎各位申请版主 at 2009年12月27日

    支持,欢迎新朋友加入我们的行列!

  • 软件配置管理案例分析 7: 你要先测试 VS 你要先出 build at 2009年12月22日

    能详细说明一下,跟 patch 有什么关系?

  • 配置管理知识点之配置管理审计 (Configuration Management Audit) at 2009年12月22日

    什么是 CM audit 我想举一个例子说明: 中国为什么要做人口审查呢?目的是控制人口增长,提高人口素质,提高人口的生活质量,减少社会矛盾,提高国民收入.

    CM audit 也一样,控制代码量,提高代码质量,使开发过程化,条理化.

    审计的内容可分为两部分代码和文档.

    代码和文档分别为两个维度:功能和实实在在的数量.

    从代码来看,第一是看代码的功能实现情况,第二是看实现功能所需的代码量情况.文档也一样.

    传统的 audit,我们通过 excel 来统计.. 当数据量大时,我们采用 audit 系统,或者写一些脚本来实现.

  • 软件配置管理案例分析 8: 软件产品 or 组件补丁的发布 at 2009年12月22日

    我们先分析一下问题:

    什么是软件,软件=系统吗? 我想他们是相等的.

    所以应当用系统思维方式来解决问题

    系统是相互联系,相互依赖的,它们是一个整体.

    所以 A 和 B 是一个整体.但是它们是可以拆分的.A 和 B 拆分了就成了系统的两个部分,在系统中他们是可以独立存在的.

    有一点很重要,他们不能单独发布.举个例子: 就像一个人有手和脚,他们之间是相互联系,相互依赖的,你不能说人只有手没有脚,当然有天生缺陷和后天因素也会有这种情况出现,我们只能说他不是一个正常的人.对于我们系统来说也是一样,它应该一个符合客户需求的系统.这里面有一个概念需要提一下.什么是符合用户需求的系统呢?我的解释是它的支持系统运行的主要组成部分,缺一不可.. 当然在我们软件中,分为很多行业软件,需求都不相同,所以系统的主要组成部分差别也很大.

    业务=软件已经成为了软件行业的趋势,这个趋势使得软件开发活动依赖于业务的需要, 所以 1) A 和 B 同属于产品 XXX，我们都应该以产品 XXX 的补丁发布而不应该以其中的一部分 A 或者 B 的形式发布。 2）A 和 B 只是产品的一部分，不应该单独出补丁，而是应该作为系统的一部分发布补丁 3）A 和 B 是产品的一部分，把他们放到补丁的名称里边反而更容易混淆 4）可以在补丁的内部实现只对那些安装了 B 的客户打这个补丁；没有安装的则不必要打。"

    上面 4 点的活动都应该依赖于用户的需要,至于应该怎样发布应该由业务决定. 其中需要注意的是,我们开发的系统,不是用户需求,在满足用户需求的同时,要保证系统的完整性和一致性.

  • 软件配置管理案例分析 1：Leader 和 Manager 的任务 at 2009年12月22日

    这些事情在我们日常工作中,反反复复存在的,楼上的几位讲得都很好. 我觉得最好用数据说话会更有效,相信每个领导都是讲道理的!

    [font=宋体] 我是一只配置管理小菜鸟，一天早上收到了两封邮件：一个是 [/font] Leader [font=SimSun] 让我去做一个项目构建的统计报告，把过去半年来 [/font] CM team [font=SimSun] 发布出去的 [/font] build [font=SimSun] 进行统计，归纳，今天之内交给他；一个是 [/font] manager [font=SimSun] 让我写一份手里项目进展状态报告，今天之内交给他。[/font]

    至于第一封邮件的内容,即使是一位熟悉的 CM,也无法在一天之内统计出来 (前提是没有数据作支撑)

    这封邮件里面没有提到要统计的属性,其次,"把半年来 CM Team 发布出去的 build 进行统计"描述不清楚,因为里面有很多垃圾信息,对 CM 来说,是不需要理会的.

    另一个方面,从 CM 的角度来说,对 Build 进行统计,那就意味着每次 build 过程都是有数据,这里的数据包括 (需求,缺陷,变更),这些数据记录了每次 build 的结果,build 的结果是以报告的方式的展示的.

    有了这些数据之后,我们可以从中抽取关键的属性,这时候就应该容易多了.因为数据量非常大,即使有数据工作量也会比较大,所以我们可以写一些脚本或工具,来使整个过程自动化.

    至于第二封邮件的内容,有了前面的基础也就好统计了

    总之一句话,要达成邮件内容,应该从 3 个方面入手: 1.有一套 build 流程来保证 build 过程的数据是能记录下来的. 2.明确 build 的目标,也是属性,这些属性必须能够反映 build 目标 3.自动的流程和工具 (现在也有很多开源的) 上面 3 方面离不开人的主观能动性,要达成这些目标,必须把人放在第一位.

  • 内部发布和对外发布的区别 at 2009年10月16日

    非常好的内外发布概念,原来公司也有内外发布的概念,周期比较长,做得比较细.. 敏捷概念新颖! 适合于小型团队,比较合适于国内的公司.

  • clearcase 命令 at 2009年10月11日

    人 + 规范 + 工具 = 好的配置管理方法 关键在于人

  • UCM 实践的经验教训 at 2009年10月11日

    根据你公司的实际情况来做流程,如果 UCM 可以满足你们的需求,当然也可以.

  • [原创] 对产品项目化应如何做配置管理 at 2009年10月10日

    是啊,只有这样了,谢谢.

  • 各位新来的朋友都来报个到吧 at 2009年10月10日

    注册有一段时间了，来报个到， 嘿嘿

  • 配置管理之路 (scmroad) 诚邀你加入管理团队 at 2009年10月10日

    【论坛 ID】make 【申请版块】clearcase,构建管理 【职业】senior configuration management 【技术专长】CC,CQ,PERL,

  • 配置管理工程师的级别 at 2009年10月10日

    每个公司都不一样.

    按技术水平和对配置管理的理解来分,可能比较客观.