【IT168 专稿】

近日，IBM 宣布完成收购 Telelogic 公司的消息。这场收购的过程一波三折，最终，成功收购让 Telelogic 成为 IBM Rational 部门的一部分，IBM 则为此支付了 8.45 亿美元。

作为一家企业管理软件提供商，Telelogic 最早只是瑞典电信下属的一个研发机构，为瑞典电信进行 SDL（Simple DirectMedia Layer）协议的开发。虽然在最初阶段，Telelogic 只在电信领域拥有技术优势，但经历数年的收购整合，Telelogic 逐渐成长开始服务于拥有复杂庞大软件系统的大公司，以满足它们对企业资源规划和应用生命周期管理的需要。

IBM 行业发展策略的新信号

尽管位于瑞典 Malmo 市的这家瑞典科技企业 2007 年营业额不过 3 亿美元，目前在全球 22 个国家仅有 1100 名员工，算不上太知名，但是它所服务的客户名单中，却有着一长串耀眼的名字：宝马、波音、戴姆勒克莱斯勒、通用汽车、英国宇航、爱立信、诺基亚、西门子，沃达丰、德意志银行等。

Telelogic 于 2000 年进入中国，并在通讯、航空航天、汽车电子、消费电子、独立软件开发等领域取得了发展。包括华为、中兴、大唐、普天、河北网通、philips、中国航天、航空院所、CECT、中船、兵总、中科院、建设银行等多个行业用户采用了 Telelogic 的解决方案。

因此，正如 IBM 方面所表示的，对于收购 Telelogic，IBM 更看重其在创新领域的客户关系。显然，IBM 想借收购 Telelogic 之机，超越传统 IT 市场，扩展到更多行业领域。

当然，Telelogic 吸引 IBM 的还有其在嵌入式系统软件领域的发展优势。正如一位业内人士表示，Telelogic 在嵌入式软件领域实力很强，此外便是需求管理领域。

IBM 软件集团 Rational 总经理 Daniel Sabbah 博士表示：“Telelogic 是我们的软件与系统开发及交付战略的一大重点，在嵌入式设备与系统中，软件处于核心地位。无论是用于开发下一代通信设备，还是开发太空探测系统，此项 IBM 技术都将对整个社会产生重大影响。”

上边是我和 CMing 在讨论问题的时候的一些文字，单独列出来，方便查找

我们还可以用 CI 来自动打包，直接作出安装程序 每次测试之前删除数据库，重建数据库等等 。。。。。

当然用 CI 也是有限制的，比如有一些项目 build 的过程中需要太多的手工参与的过程，而这些手工参与的过程又是不能用脚本实现的，那么这样的项目做起 CI 来就很困难。比如我们 公司有个项目就是需要手工参与的地方太多了，build 过程太复杂了，现在还处于最原始的 build 状态。

再次读起，依然有收获

为什么是要授权的呢？我自己的理解：

1. 开发组可以自己创建 build，但是这些 build 是不能发布的，也是不能提交给除了开发组之外的任何人的,甚至不同开发组之间也是不能随意共享 build 的（比如，一个开发组可能用到另外一个开发组发布的东西，这两个开发组最好也不能使用对方没有经过 CM 授权的 build）
2. CM 做 build，要有 build 记录，比如这个 build 是哪个版本的 build，在什么环境下 build 出来的，一般 CM 都有记录。一旦有了问题，比 如某个发布给客户某个版本的 build 有个 bug，CM 可以及时找到（体现 traceability ），并且再次作出（体现 repeatable）同样的 build 以供再现客户遇到的问题，解决 bug 等等。

转载自：[url]http://www.cmcrossroads.com/component/option/url],com_fireboard/Itemid,593/func,view/id,85209/catid,3/[

Oh, give me a home Where crashes and data corruptions don’t roam Where all my developers say “SCM is the best” - all day And “we” have a successful release today,everyday!

Oh, give me a home Where changes can't roam With orderly baselines arrayed Where the status is known, and when audits are done Customers get that for which they all prayed.

Oh give me a home Where files can't roam Where streams with inheritance lay Where seldom is heard a discouraging word, And, 'Who broke the build?' is not echoed all day

MKS Source Integrity 是一个软件配置管理工具，它具有满足组织战略上需求的强大能力，例如项目状态，发布之后的维护以及安全等待那嘎。项目组可以通过基于 Java 的 GUI，命令行或者 IDE 接口来访问稳定的版本库。专业版本的 MKS Source Integrity 包含了 Track Integriy，一个 bug 跟踪和问题请求管理系统。

需要重点掌握的概念，包括但不陷于下面提到的内容： branch build project build Sandbox change package checkpointing default branch development path promoting revision label Sandbox shared Sandbox shared subproject freezing/thawing variant Sandbox member label

按照字面意思翻译了一下，还没有仔细检查。等我更新完善之后，再添加一个更新的版本。

CMing 于 2008-7-29 14:16 发表
她的意思好象是说是有个项目还没开始,公司现在有两个 CM 要是加上我就 3 个人. 让我等一段时间,先别辞职我现在的公司. 问我愿意等不,我说愿意,就这样! [/quote] 哦，形势还不错，哈哈哈

CMing 于 2008-7-29 13:28 发表
等一段时间才能去. [/quote] 这个是什么意思？

它给你口头 offer 了没有？它什么意思嘛？

CMing 于 2008-7-29 13:17 发表
呵呵,终于面完了,感觉还可以! 她们老总说对我印象还不错. [/quote] 鼓掌 噼里啪啦，噼里啪啦～～～

好好休息下，期待面经，发到 worklife 版，我也来拜读大作

zoe 于 2008-7-29 12:43 发表

诬蔑！！！ [/quote]

话说你最近在看楼盘哇~~

zoe 于 2008-7-29 12:44 发表

手动的多奢侈啊～～～

往年都只有大富人家才请得起人工 [/quote]

..... 我所说的手动是自己扇扇子:(

zoe 于 2008-7-28 23:47 发表
我盖的啊，只是盖的薄

我们空调很奇怪哦，开的睡眠模式，但是还是会自动关机 [/quote] 好奢侈啊，还空调。。。。。。我这都是手动

zoe 于 2008-7-28 23:47 发表
我忙得好久都没来了 [/quote] 太不关心这里了。。。

CMing 于 2008-7-28 13:59 发表
呵呵,看明天面的如何.

如果成功,一定好好讲下面经过程. [/quote] 要得嘛

上面定义的 3 类工作空间（分支）由配置管理员统一管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基线的推进。

3． 变更控制

对于大型的软件开发项目，无控制的变更将迅速导致混乱，变更控制就是通过结合人的规程和自动化工具，以提供一个变化控制的的机制。本文所涉及的变更控制的对象主要指配置库中的各基线配置项。变更管理的一般流程是：

A) 由开发人员或系统集成员提出变更需求；

B) 由 SCCB（软件变更控制委员会）审核并决定是否批准；

C) 配置管理员根据 SCCB 的决定临时开放相应的权限，并备案；

D) 系统集成员执行相应的变更。

在这里，将要涉及的变更控制分为两类：一类是基线的变更控制，另一类是软件版本的变更控制。

l 基线的变更控制

基线的变更是指在一个软件版本的开发周期内对基线配置项的变更，主要包括基线的应用和更新等活动。

基线变更所涉及的操作主要包括基线标签的定义和标签的使用。基线标签属于严格受控的配置项，它的命名必须严格按照相关的命名规范来进行。基线在建立时，按照角色职责的分工，须经 SCCB 同意并以正式的将该基线的标识和作用范围通知系统集成员，由后者负责执行；基线一旦划定，由该基线控制的各配置项的历史版本均处于锁定或严格受控状态，任何对基线位置的变更请求都必须按变更控制流程，提交 SCCB 批准，然后由系统集成员执行。

l 软件版本的变更

软件版本的命名规范应事先制定，并按照开发计划予以发布使用。在软件版本的演进过程中既需要从以前的版本中继承，又需要相对的独立性。所以在对于一个子版本（例如某特定用户的定制版本）就需要对一系列配置项从统一的开发起始基线所确定的版本上建立新的分支，然后在此分支上开发新的版本。因此在这样的变更控制流程中，受控的对象还应包括特定的分支类型，以及工作视图的选取规则，同时配置管理员将在这一过程中担负更多的操作职责。

上述几点是笔者在从事软件配置管理过程中的一些心得体会，在此抛砖引玉，供大家参考。

本文来自《PMT 评论》总第 23 期

其次，配置管理工具应具备一定的工作空间的管理功能。正如前文指出的那样，一个软件企业往往有多个项目同时进行着开发，为了最大程度的利用组织的经验、共享成果，我们有必要在一个共同的配置库里提供多视角的观察手段，在逻辑上按照不同的角色分工来组织信息的选取规则和显示方式，从而能根据需要，在开发人员间灵活的进行分工合作。

由于我们把配置管理工作立足于软件过程的改进，那么我们所选用的工具最好能具有一定的过程控制的能力，能利用它按照企业本身的开发流程来灵活的建立相应的电子流，并在此过程中记录用于过程度量的相关数据，整合软件过程管理的各个环节，以便于客观的发现问题，高效的解决问题。

另外，我们选取得工具一定要操作简便，不能给开发人员增加过多的负担，因为过多的形式化的约束往往带来人们的反感，使得大家不约而同的选择规避的措施，其结果只能是事倍功半，甚至和我们的目标南辕北辙。

三． 实现的策略

笔者所在的软件组织从事的通信软件的研发，我们把配置管理作为推进软件过程改进的一个很重要的工作领域。我们明确定义了配置管理相关的角色、工作职责和工作流程，通过一段时间的努力，已经取得了明显的效果。

1． 配置库的设置

决定配置库的结构是配置管理活动的重要基础。一般常用的是两种组织形式：按配置项类型分类建库和按任务建库。

按配置项的类型分类建库的方式经常为一些咨询服务公司所推荐，它适用于通用的应用软件开发组织。这样的组织一般产品的继承性较强，工具比较统一，对并行开发有一定的需求。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。但由于这样的库结构并不是面向和各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。

而按任务建立相应的配置库则适用于专业软件的研发组织。在这样的组织内，使用的开发工具种类繁多，开发模式以线性发展为主，所以就没有必要把配置项严格的分类存储，人为增加目录的复杂性。因此，笔者认为特别是对于研发性的软件组织来说，还是采用这种设置策略比较灵活。

2． 分支的划分

在实际的开发活动中系统中，为了让每个开发人员和各个开发团队能更好的分工合作，同时又互不干扰，我们基本上为每个配置项从建立开始就划分成 3 个不同的分支，让它们分别对应 3 类工作空间。

l 私有分支

私有分支对应的是开发人员的私有开发空间。开发人员根据任务分工获得对相应配置项的操作许可之后，他即在自己的私有开发分支上工作，他的所有工作成果体现为在该配置项的私有分支上的版本的推进，除该开发人员外，其他人员均无权操作该私有空间中的元素。

l 集成分支

集成分支对应的是开发团队的公共空间。凡是要为同组人员共享的配置项都从该分支获得。即各开发人员必须将私有工作空间中的开发成果归并（Merge）到该分支后才能进入下一个开发活动。所有涉及多人协调的开发工作（如集成测试等）都必须工作在这一空间中。该开发团队拥有对该集成分支的读写权限，而其他成员只有只读权限。该分支的管理工作由系统集成员及相关指定人员负责。

l 公共（主干）分支

公共分支对应的是整个软件开发组织的公共空间。各个开发小组在现阶段的任务完成后，将可以发布的版本归并到该分支上，将来需要查阅相关资料时，以该分支上的版本为准。该分支对组织内的全体软件人员开放只读权限。该分支的管理工作由系统集成员负责。

简单的说，Testopia 是和 Bugzilla 结合在一起 test case management（测试用例管理）的系统。 它是作为一个 bugzilla 的一个插件运行的。所以你先要装好 Bugzilla，然后再把 testopia 集成进去。

For tutorials and articles on using Mylyn refer to the Publications page ([url]http://www.eclipse.org/mylyn/publications/index.php/url][) . The role of this document is to provide up-to-date documentation on a listing of the key Mylyn features and is not intended as a tutorial, and to allow users to contribute additional documentation. Mylyn is a task-focused UI for Eclipse that makes working with very large workspaces as easy as working with small ones. Mylyn extends Eclipse with mechanisms for keeping track of the tasks that you work on. A task is defined as any unit of work that you want to recall or share with others, such as a bug reported by a user or a note to yourself about improving a feature. You can store tasks locally in your workspace, or they can come from one or more task repositories. To connect to a task repository, you must have a connector that supports that repository. (A task repository is a bug/ticket/issue tracker such as Bugzilla, Trac, or JIRA). Once your tasks are integrated, Mylyn monitors your work activity on those tasks to identify information relevant to the task-at-hand. Mylyn monitors Eclipse and captures your interaction in a task context. System artifacts such as files, types, methods, and fields get assigned a degree-of-interest based on how recently and frequently you interact with them. This results in uninteresting elements being filtered from view within Eclipse, allowing you to focus on on what is important. From this, Mylyn creates a task context, which is the set of all artifacts related to your task. These can include methods you have edited, APIs you have referred to, and documents you have browsed. Mylyn uses this task context to focus the Eclipse UI on interesting information, hide what's uninteresting, and automatically find what's related. Having the information you need to get your work done at your fingertips improves your productivity by reducing the time you spend searching, scrolling, and navigating. By making task context explicit, Mylyn also facilitates multitasking, planning, reusing past efforts, and sharing expertise.

牛牛啊，到时候你回来了，给说说面经