面

http://bbs.scmroad.com/viewthread.php?tid=1496

 

1你为什么要申请配置管理工程师这个职位?

我们公司已经通过了CMMI3，我在现在的公司就是做配置管理工程师的，我熟悉配置管理，并喜爱这份工作，希望能继续从事该工作。

 

2你觉得自己能否胜任这个职位?

能胜任，我们公司已经通过了CMMI3，并且日常工作都是按照CMMI3的流程规范进行的，并不是为了过级而过级，是切实为了保证软件质量才过级的。我做配置管理已经有一段时间了，不仅现有工作能够完全胜任，还非常乐于学习，如果贵公司的该职位有什么知识是我掌握的不够好的，我能在短时间内满足工作要求。

 

3你觉得配置管理工程师需要掌握哪些技能?

配置管理工具的使用，构建脚本的编写，对工件的理解，了解软件工程，配置管理相关知识，配置管理的工作方法。

需要掌握的技能: 专业技能如程序设计,  配置管理, 变更控制(版本风险控制), 发布管理, 持续集成, 配置项(包括很多, 如文档, 源码等)规范等; 其它技能: 团队合作能力, 与人沟通能力, 配置管理威信等. 

 

4配置管理工程师的职责有哪些?

职责包括: 保证工作产品的一致性、完整性、可追溯性，管理配置项，维护配置库，变更控制，发布管理。

5配置管理能给项目带来的好处有哪些?

因为配置管理保证了配置项的完整和可追溯，使团队成员可以拿到所需工件的所需版本，不会因为某个人的习惯问题，导致配置项缺失（比如东西在某人本机保存，人离职了，东西就找不到了）；

变更控制使团队每个人都了解到谁改变了哪些东西，保证了所有团队成员的信息对称；（比如需求已变化，但测试人员不知道，还按照老需求来测试，结果当然是不符合）

配置管理给项目带来的最大的好处：规范化的配置项管理可以使整个团队随时拿到需要的东西（包括备份，文件历史等）；对变更的控制可以对整个配置库（特别是对开发项目）的发展，对产品的变更随时了解；有了配置管理的支持，更大的提高公司员工的工作效率，把公司从一个手工的，有点混乱的项目管理过程中解放出来，实现更完美的规范化。

6作为一个配置管理工程师,哪些方面是工作的重点?可能的难点会有哪些?

工作重点：当然是对配置项的规范化的这样一个过程，包括对配置管理工具的使用，对配置项的修改控制，对配置项的随时备份等。 难点：如果一个公司以前没有配置管理这样一个理念的话，最大的难处就是使公司内部人员熟悉并遵循配置管理这样一套理念啦。

7什么是基线?什么是label? tag ? branch?他们之间有什么联系和区别.

基线是一组被正式评审通过并经CCB同意发布的工作产品集合，它作为下游开展工作的基础，已基线工作产品的变更必须受控。

结合我们公司的情况，如果使用的是vss配置库，在里程碑处会建立基线，建立的同时，会为此基线打个label，相当于给这一系列的配置项集合贴了个标签，表示此集合都是xxxx1.0设计基线的成员；另外就是自动构建的时候会给参与构建的所有文件都打label，告诉此版本的文件参与了自动构建，将来有需要可以get到整个label；

在svn的使用中，会用到tag和branch，tag是里程碑处的一个copy;

tag:是用来做一个milestone的，不管是不是release，都是一个可用的版本。这里，应该是只读的。更多的是一个显示用的，给人一个可读（readable）的标记。
branch，是用来做并行开发的，这里的并行是指和trunk进行比较。

branches：分枝
当多个人合作，可能有这样的情况出现：John突然有个想法，跟原先的设计不太一致，可能是功能的添加或者日志格式的改进等等，总而言之，这个想法可能需 要花一段时间来完成，而这个过程中，John的一些操作可能会影响Sally的工作，John从现有的状态单独出一个project的话，又不能及时得到 Sally对已有代码做的修正，而且独立出来的话，John的尝试成功时，跟原来的合并也存在困难。这时最好的实践方法是使用branches。 John建立一个自己的branch，然后在里面实验，必要的时候从Sally的trunk里取得更新，或者将自己的阶段成果汇集到trunk中。

branch:是版本树演进的一个分支，为了不影响主枝，可以作为个人的工作位置，或者某定制开发的位置，如果将来有必要将该定制合并到主枝，可以使用配置库提供的合并功能。

http://blog.myspace.cn/e/406532053.htm

需求一：
有一个客户想对产品做定制，但是我们并不想修改原有的svn中trunk的代码。
方法：
用svn建立一个新的branches，从这个branche做为一个新的起点来开发
svn copy svn://server/trunk svn://server/branches/ep -m "init ep"
Tip:
如果你的svn中以前没有branches这个的目录，只有trunk这个，你可以用
svn mkdir branches
新建个目录
需求二：
产品开发已经基本完成，并且通过很严格的测试，这时候我们就想发布给客户使用，发布我们的1.0版本
svn copy svn://server/trunk svn://server/tags/release-1.0 -m "1.0 released"
咦，这个和branches有什么区别，好像啥区别也没有？
是的，branches和tags是一样的，都是目录，只是我们不会对这个release-1.0的tag做修改了，不再提交了，如果提交那么就是branches
需求三：
有一天，突然在trunk下的core中发现一个致命的bug,那么所有的branches一定也一样了，该怎么办？
svn -r 148:149 merge svn://server/trunk branches/ep
其中148和149是两次修改的版本号。


8一个构建(build)发布的过程是什么?(请描述一下典型的发布一个build的流程)

构建->提交测试->修改代码->构建->提交测试直至测试通过-配置审计->建立基线->走审批流程->发布

9release notes都应该包括哪些内容?

一般是版本控制(臂如vss,cvs等)的说明文档，臂如标签，修改说明等。这个格式可以自己定义，没有大标准。

项目简介、发布背景、运行/测试环境、与已有版本相比的新功能特性、升级方法、已知错误和局限性、已测试的性能、工件发布列表

10广义上的Change Request(CR)都包括哪些内容?

项目名称、变更原因、变更分析（影响程度、紧急程度、影响因素< □范围         □工作量       □进度         □成本         □资源         □质量>）、申请变更的内容（是配置项变更还是基线变更）、受到影响的配置项，变更配置项的具体执行人

11你一天的多长时间用来做build?你一天的时间安排是个什么样子的?

写好构建脚本后，之后系统每天自动执行自动构建。

12简述在一个项目周期中,配置管理工程师(CM)的主要活动(工作)有哪些?

以项目计划为输入，做项目的配置管理计划，计划包含采用何种配置管理工具、备份策略、目录的设置、权限如何分配、配置项的受控计划、基线的建立计划、审计计划；按照配置管理计划建立配置管理库，维护配置管理库、分配配置库权限，管理配置项（受控工件、建立基线）；进行配置审计；项目的变更控制；打部署包提交测试，进行版本发布。维护项目的配置管理工作表，按月整理事业部配置管理月报。

大家回答的时候可以从前往后叙述,这样也不容易忘记,还显得有条理.

13请描述一下你使用过的配置管理工具？

VSS，svn；

vss采用的是锁定-修改-解锁的方式，对于多人的协同开发存在一定弊端，系统无法自动检测来自他人的修改，只能在局域网使用。

svn采用的是复制-修改-合并的策略，可以检测到他人的修改，有较好的合并功能，还可以在外网使用，对于规模不太大的团队已经够用了，在windows的环境下使用非常的方便，并且可以集成到eclipse中直接进行操作，现阶段非常适合我们公司的开发环境。

 
14在安装配置方面有什么需要注意的？他的扩展功能有哪些？如何实现？

公司采用的是apache+svn的使用方式，windows下的安装是比较容易的，linux的话，就要注意先安装apr apr-util berkeley db这些

 

26除了你使用过的软件配置管理工具，还了解哪些工具？请说出这些工具的区别。

git分布式开发用非常好，权限控制薄弱，对windows的支持不好，需要在linux下使用.相比 svn，git 代码库体积小(能小 50% 多，如果 svn 里分支用本地文件拷贝 + svn add，那么 git 在体积上更占优势)，git 工具速度很快，对合并支持非常好，探测文件重命名的做法很独特，git-svn很好用，分支很轻量级. 如果不怎么理 Windows 平台，代码很庞大，对合并要求很高，不惮理解 git 的原理以及看手册，那么 git 是很好的选择。

cvs：文本下载是差异的，上传是全量，不是原子性提交，如果上传过程遇到网络中断，可能会上传一部分文件，导致版本出现问题，目录未纳入版本控制，不能重命名，对于二进制的文件是采用独立的冗余的存储，建议使用svn

clearcase：没有具体使用过，看资料都说安装配置使用比较复杂。

svn:项目不大，对权限控制很看重，应选择SVN

 

15请问你是否亲手装过windows 操作系统？是否使用过windows 2003 server？
格式化硬盘该怎么样去做？

安装使用过。我的电脑-管理里面进行操作

16请问你是否装过linux或者unix操作系统？请分别说出你所知道的linux 和unix 发行版本

自己装过redhat linux 5.2企业版

linux:Ubuntu（乌班图），Fedora，OpenSUSE，Debian（待宾），Mandriva，Mint，PCLinuxOS，Slackware，Gentoo，CentOS，FreeBSD

http://www.cnbeta.com/articles/112817.htm

unix:A/UX | AIX | BSD | DragonFly BSD | FreeBSD | GNU | HP-UX | IRIX | Linux | LynxOS | Mac OS X | Minix | NetBSD | NEXTSTEP | OpenBSD | QNX | SCO OpenServer | Solaris | System V | Tru64 | Xenix

 

17你知道配置管理中基线的含义么？怎样把项目中某个重要的时刻冻结？

基线是一组被正式评审通过并经CCB同意发布的工作产品集合，它作为下游开展工作的基础，已基线工作产品的变更必须受控。

18你一般会把哪些东西纳入版本控制？

项目的重要工作产品，过程性的文档就不需要版本控制了。

19怎样可以保证团队中每个人都知道谁改变了哪些东西？

通过变更控制，每次变更结束都会邮件通知涉众，并且维护该项目的配置管理工作表，记录此次变更，在工件重新受控提交时会在注释中简要记录。

可以通过变更控制，变更活动关联的配置项清单和配置工具的日志信息。

20Tag和Branch的区别是什么？在什么情况下该使用tag，什么时候用branch？

Tag是标签，Branch是分支。当项目里程碑到达了或项目发版的时候需要对项目的重要工作产品打一条Tag.当项目发版后主分支需要做新版本，而又有上线后的BUG需要上紧急版本修复时需以项目发版时创建的Tag为基准创建一条Branch来修改上线后的紧急BUG。

branches和tags是一样的，都是目录，只是我们不会对这个release-1.0的tag做修改了，不再提交了，如果提交那么就是branches
tag，是用来做一个milestone的，不管是不是release，都是一个可用的版本。这里，应该是只读的。更多的是一个显示用的，给人一个可读（readable）的标记。
branch，是用来做并行开发的，这里的并行是指和trunk进行比较。

21怎样管理技术文档——如产品架构文档——的变化？

首先对确定后的技术文档打好基线，之后就要对基线后的 技术文档进行变更控制，变更前要进行变更影响分析，变更时候要关联对应的变更活动，文档好写好变更记录。

22如果客户想要对一款已经发布的产品做出变动，你怎么处理？

作为定制需求在配置库做一个branch，相对于主枝做并行开发，最后综合评估所做修改是否要纳入产品主枝。

23版本管理和发布管理有什么差异？

版本管理是软件配置管理的基础，它管理并保护开发者的软件资源。它的主要功能有：(1) 集中管理档案，安全授权机制：档案集中地存放在服务器上，经系统管理员授权给各个用户。用户通过check in和check out的方式访问服务器上的文件，未经授权的用户则无法访问服务器上的文件。(2) 软件版本升级管理：每次登入时，在服务器上都会生成新的版本，任何版本都可以随时检出编辑。(3) 加锁功能：在文件更新时保护文件，避免不同的用户更改同一文件时发生冲突。(4) 提供不同版本源程序的比较。

版本控制系统用于保存编写开发应用程序时的文档的各个修订版（revision）。 版本控制也称作Revision Control System(RCS)

发布管理是对发布流程的控制，只有通过测试经过审批的版本才能够正式发布，未经测试的版本如果发布，存在质量隐患。

24对文本文件的变化和二进制文件的变化进行管理，这二者有什么不同？

对于svn文本和二进制文件的管理是一样的，采用统一的二进制差异算法

cvs对于文本进行差异化的存储，对二进制文件采用独立的冗余的存储。

25同时处理多个变更请求，或是同时进行增量开发和维护，这种事情你怎么看待？

 

 

 

 

27什么是dotnetframework？是干什么用的？

Microsoft .NET Framework 2.0 版可再发行组件包将安装运行针对 .NET Framework 2.0 版开发的应用程序时所需的 .NET Framework 运行库及相关文件。

28JRE是什么的缩写？干什么用的？

JRE   是Java运行环境   (Java     Runtime   Enviroment)   的缩写。它基本上就和Java虚拟机是同一个概念。
JDK   是Java开发工具包   (Java     Development   Kit   )   的缩写。它是一种用于构建在   Java   平台上发布的应用程序、applet   和组件的开发环境。JDK包括了jre。jre可以自动升级是其自身具有的功能。

 

29是否听说或者用过cpan？

CPAN是全面Perl归档网络（Comprehensive Perl  Archive Network）的缩写，那是一个值得常去的地方。这里有Perl源码，容易安装到非类Unix系统的Perl 例子，文档，Perl扩展部分，Perl归档信息等。简言之，CPAN是全面的。

http://www.cpan.org/

30一个HR的面试题

“做配置管理最终的目标是什么？实现目标的路线是怎么样的？”

保证软件产品的配置项的一致性、完整性、可追溯性；

按计划进行基线建立，定期进行配置审计，使用配置管理工具，对评审通过已受控的配置项的变更进行控制

用友的配置管理面试题
31 Perforce 与 Subversion有啥区别？

perforce是商业软件

svn是开源免费的

32怎么利用分支模式支持 Agile 开发？

agile敏捷

http://www.uml.org.cn/SoftWareProcess/201002094.asp

33简述项目经历，描述哪个项目收获最大.......

第一个接手的项目，建立配置管理概念，学习规范的配置管理流程，学习编写脚本

34  Ant build.xml什么情况下用到 for 循环？如何写 for 循环？

1: build完成之后生成了build.war包. 同时这个war包要分别部署到10台不同的测试机上, 简单点说copy到10个不同的目录下. 然不成要我写10个<copy>, 这样的脚本写出来, 又难看,又难以维护. 假如我们用<for>  用一个properties文件来保存10个路径, 并以参数形式传递给<for>,岂不是方便了很多. 假如要<copy> 20,30....或者更多次呢?

http://bbs.scmroad.com/viewthread.php?tid=5109

2: 我接触的arm编译器, 它支持 *.c/*.cpp这样的格式, 但使用这种, 编译出来的东西偶尔会有问题,而且是很莫名奇妙的问题. 所以研发要求逐个编译. 于是乎, 就变成了如下一串.
arm -c 1.c,2.c,3.c,4.c,5.c............
如果脚本这样写,是多大的维护量. 更何况项目还多, 假如我们用<for>呢.只需要维护一个build.properties就可以了. 然后可能arm的编译参数对不同的代码又不尽相同.那我们再加上<if> <elseif>呢, 将判断条件同样用properties文件管理.

VMware 面试题

35Perforce 与 Subversion有啥区别？

perforce是商业软件

svn是开源的

36配置管理和 IT人员有何区别？（这个问题当时让我很震惊）

配置管理员的安装维护配置管理库，分配权限这些工作IT人员也可以做，但是IT人员只是为项目提供支持环境，不关注项目质量，不关注项目的变更，不关注产品版本

37用 Perl 如何过滤 log 信息 (主要考的还是正则表达式）

比如我在 perl里执行了 系统的某个命令，比如一个build命令，会在命令行里打印出好多过程信息，如何把这些信息保存成一个 文件，谢谢！

1.
perl xxx.pl >/tmp/file

2.
open(STDOUT, ">/tmp/file");
system("build");

38Perl 如何排序

39表示邮件的正则表达式是什么?

/^/w+((-/w+)|(/./w+))*/@[A-Za-z0-9]+((/.|-)[A-Za-z0-9]+)*/.[A-Za-z0-9]+$/

40 Perforce 如何支持分布式开发？

41 Perforce proxy的原理是什么？

42Perforce 如何创建 depot？

43Perforce 如何创建 branch？

44Perforce 如何用命令同步一个changelist

45Perforce 命令行下如何把几个文件放到同一个changelist 当中？

整理的一些面试题:
46SVN 分支发布和主干发布各有哪些优缺点?

47我们公司现在没有配置管理, 你打算怎么开展?

1－－写好必要的操作手册和支持文档，把这些标准的文档发给你的上司，引起他们的注意；
2－－争取一个小时的时间对大家进行统一的培训，真样你就会有一个发挥的时间；
3－－在介绍配置管理和使用配置管理工具的时候，清楚明了，并且强调这是部门的要求，需要所有人员参与配合。大家都可以在实施配置管理过程中得到相应的关于软件过程管理的知识，体现程序员的基本素质，适应软件组织发展的要求；
4－－自己要有信心，对同事要有热情，及时报告结果。

了解公司现有流程，根据现状和不足，按照CMMI的要求起草配置管理相关的规程、指南、表单；

每个配置文件写好后都邀请各角色的使用者代表参与评审；

根据评审意见进行修改，直至关闭评审；

提交EPG或者分管负责人进行审批；

审批通过后进行试行；

试行结束，将配置文件正式发布执行；

在执行过程中，如果遇到新的问题，再进行持续改进。

48以前你是怎么做配置管理的? 怎么样通过配置管理控制质量?

49 基线的概念? 什么时候应该打基线?

基线是一组被正式评审通过并经CCB同意发布的工作产品集合，它作为下游开展工作的基础，已基线工作产品的变更必须受控。

项目计划的里程碑处需要打基线，比如需求、设计、开发、测试完成之后通常都需要建立基线。

50 如果你来建立一个SVN库存, 请你画一下SVN库的结构目录.

trunk branches tags controlvar promanage

51可不可以自己对SVN做扩展? SVN与其它工具的集成, 如bugzilla, mantis等?

现阶段还没做过，如果需要，可以研究一下

52如何关联SVN修改记录与bugzilla, mantis的BID修改项?

下面谈谈 BugZilla VS Mantis 的结论；
1. 界面。 BugZilla的几面几乎可以说惨不忍睹，鼎鼎大名的开源软件，界面居然是这样。呵呵。真想不通。相对而言 Mantis的界面则要友善的多了。操作也相对更加人性化一点。
2. 功能。 就功能来说， BugZilla的定制功能的确更强，能满足更多用户差异化的需求。而Manits的好多设置还得通过 修改代码来实现，相比麻烦了很多。
3. 本地化。 Mantis本身就提供了十几国的语言可以供用户直接选择。很不错的哦。而 BugZilla本身只有英文，网站提供的多国语言包，看起来也是Sourceforge上其他项目组完成的，更新的节奏也比英文版慢了一年半年的。不爽的很。
4. 知名度，呵呵。这个 BugZilla和Mantis没得比了。Linux,Eclipse,NASA(美国宇航局居然也用开源的？？？）...等等知名的厂商都在用。而Manits的使用者大多都是一下不知名的小公司了。
5. 安装。 平心而论 BugZilla的安装确实比Mantis简单。CheckSetup.pl替用户省了不少心。

53 做项目配置管理的时候,如果项目多, 你会采用多库管理还是单库管理? 并说明原因?

如果项目间关联性大，会互相影响，就建一个库，不是这种情况就分别建库。不同库的代码无法合并，所以相关联的项目实现多库管理，会导致无法得到其他项目的变化，如果没有这个原因，各自建库，会使库更简单清晰便于管理。

54 tag, branch的概念? SVN基本命令?

tag和branch都是个目录，是一个工作copy，tag通常在里程碑处对项目的一个快照，用于显示，不做修改使用。branch可以实现和trunk的并行开发，通常用于定制需求，或者trunk已经到了2.0版本，1.0被找到了bug，用来解决1.0的问题，或者作为个人一些不影响主枝开发的开发尝试进行的地方，还能随时从主枝获得版本最新改变，如果有必要还可以将自己的工作成果合并到主枝。

斯顿信息技术有限公司(智控美信) SCM 面试题

55介绍下你的工作经历

我现在的工作是xx的xxxx部门的配置管理工程师，负责全部门11个产品的配置管理工作，日常工作包括做各产品线的配置计划，受控评审通过的工件，在项目里程碑处建立基线，控制项目变更，维护配置管理工作表，进行配置审计，写ant脚本进行产品的自动构建，提交部署包给测试人员，测试通过后进行产品发布。受理产品的版本申请。建立维护配置管理库，分配库权限

56CMMI 评估中，你负责什么？KPA？

检查配置管理是否按CMMI的要求进行，需要有的报告文档是否齐全，进行cm访谈。

57CMMI 过程改进过程中，CM 都收集了哪些数据？哪些方面做了量化？

cmmi中要收集哪些数据？

一般有三个数据是强制一点：schedule，effort，defect density(缺陷密度)

系统范围、代码行、复杂度、工作量（分不同阶段）、成本、缺陷率

项目属性、项目人员、项目规模、项目进度、项目工作量、项目成本、项目培训、项目评审活动、关键计算机资源、项目缺陷、项目过程、项目需求管理

楼上说的都对，跟CMMI级别无关
可以参照业内的基本信息，但是还要根据项目的实际情况去定义，只定义对项目的有用的度量信息，而不要追求数量

http://bbs.51testing.com/thread-29451-1-1.html

58CM 如何支持分布式开发？不同工作地点之间如何管理，同步数据？

59配置管理计划（CM Plan）中都包含哪些内容？

配置工具的选择，项目的软件开发环境，目录设置及目录说明，各目录的权限分配，配置项（含批准人信息），基线计划，发布计划，项目所需报告、记录（变更）

60什么是基线？基线是如何产生的？如何管理基线？

评审通过被批准进入基线的已系列工件的集合，作为之后开发的基准。在项目计划的里程碑处建立基线（需求基线、设计基线、部署基线、发布基线），对于纳入基线的工件变化需要变更控制。

61如何考核一个配置管理员（SCM）？

62配置管理员最基本的素质是什么？

63问性格类型，公司业务知识的了解。

用英文解释
64什么是 branch？

65什么是 tag？

66你为啥要从现在公司离职？

因为贵公司的职位接触的技术更多，我希望能够学习更多的东西，而且贵公司无论规模、知名度、还是薪酬待遇都对我很有吸引力。于个人而言，我希望自己三十岁之前可以有一个自己比较满意的工作，专注于这份工作，把它做好，更好的体现自己的价值。

几乎每次面试和每次找工作都要面临的问题，但是这确是一个很不容易回答的问题。

67如果公司目前存在XX配置管理推进方面的问题，你怎么解决？

全面了解现有情况、流程，找到症结所在，分析问题，找到解决办法，试行办法，检验改进结果，继续改进或正式按办法执行，在发现新的问题时进行持续改进。

68你知道配置管理中基线的含义么？怎样把项目中某个重要的时刻冻结？

 

69你一般会把哪些东西纳入版本控制？

项目进行过程中所有重要工作产品，不包括过程文件。

 

70怎样可以保证团队中每个人都知道谁改变了哪些东西？

通过变更控制，变更申请提交CCB审批（团队成员都是CCB的成员），通过后开始进行变更，变更后内容需要进行评审，评审通过后的内容经CCB同意重新纳入基线。将变更结果通知该项目所有涉众。

 

71Tag和Branch的区别是什么？在什么情况下该使用tag，什么时候用branch？

 

 

 

73你用什么侗剧管理项目中所有数字信息的状态？你最喜欢哪种工具？

 

 

 

76对文本文件的变化和二进制文件的变化进行管理，这二者有什么不同？

通过差异化的二进制文件处理看SVN与CVS的区别：由于历史原因，CVS主要是为早期的程序员设计的，CVS能够有效处理文本文件（或ASCII文件，源代码文件），可以对文本文件进行差异化的存储、新旧版本的比较，文件合并等；但对于二进制文件，CVS则明显力不从心。

与CVS不同，Subversion采用统一的二进制差异算法（binarydifferencingalgorithm），即对文本文件和二进制文件采用相同的差异比较算法，并以相同的方式在版本库中进行存储：每次提交后版本库中只存储相对于先前版本的差异，从而可以节省大量的存储空间。该二进制差异算法不仅应用在版本的存储上，更为重要的是，Subversion对二进制文件与文本文件一视同仁，当客户端需要获取新的版本时（如执行svnupdate），在网络上只有版本的差异被传输，从而大大减少对网络带宽的消耗。更多细节参见“七、双向的差异化－压缩网络传输”。

 

 

77同时处理多个变更请求，或是同时进行增量开发和维护，这种事情你怎么看待？

 

 

为何要进行软件配置管理，结合工作说说软件配置管理有什么好处

配置管理的目标是保证版本的一致性、完整性、可追溯性；简单的举例说明，一致性：2.0的部署包配套的同时是2.0的源码、测试报告，而不是2.0的部署包，带的是1.0的源码；完整性：版本里程碑时，必须有的东西要有，而不是你本机有，其他人都找不到，或者某人离职导致配置项缺失，比如需求、源码、部署包、部署说明、用户手册等；可追溯性：每次通过评审的版本都可以找到。

好处：配置管理是一套保证软件质量的方法论，结合我自己的工作，比如测试通过后，已经要发布了，开发人员又想修改一个小bug，他就直接修改，然后发布修改后的版本，而测试人员并不知道，但是这种修改有可能引起软件的其他问题，这时候发布，就存在质量隐患。在比如需求需要变更，项目经理直接把需求给改了，测试人员按照修改后的需求来测试，测试通过，满足需求，但是这个需求已经不是项目相关人员评审过的那个需求了，最后的产品已经不是原来规划中的样子了，就会发生货不对版的情况，对于经过评审已受控的配置项，变更需要受到控制。

因为配置管理保证了配置项的完整和可追溯，使团队成员可以拿到所需工件的所需版本，不会因为某个人的习惯问题，导致配置项缺失（比如东西在某人本机保存，人离职了，东西就找不到了）；

变更控制使团队每个人都了解到谁改变了哪些东西，保证了所有团队成员的信息对称；（比如需求已变化，但测试人员不知道，还按照老需求来测试，结果当然是不符合）

配置管理给项目带来的最大的好处：规范化的配置项管理可以使整个团队随时拿到需要的东西（包括备份，文件历史等）；对变更的控制可以对整个配置库（特别是对开发项目）的发展，对产品的变更随时了解；有了配置管理的支持，更大的提高公司员工的工作效率，把公司从一个手工的，有点混乱的项目管理过程中解放出来，实现更完美的规范化。

 

 

1)我感觉有些时候面试吧,有些问题真的不知道怎么去回答. 如:什么是配置管理? 配置管理应该怎么做?等等...方向特别大的问题.
2)遇到过最诚实的一个项目经理, 面谈的时候直接说, 我包括项目的成员对配置管理一概不懂, 现在想找一个懂的人把这块做起来.
3)有些公司有配置管理员, 但是不同的配置管理没有一个统一的定义啊. 有些时候虽然同样是做配置管理的,但很难找到共同话题, 因为大家都认为自己做的是最正确的.

 

21你用什么工具管理项目中所有数字信息的状态？你最喜欢哪种工具？

 

cvs的tag

http://linux.chinaunix.net/techdoc/system/2009/02/09/1061531.shtml

什么时候使用tag
        tag的功能就像是给你的工程的某个时刻建立了一个快照。添加了tag后，不论你最源文件做了任何
修改，只要发现你的修改发生了错误，或者是如果有人宣称在某个版本里有个 bug，但你在当前工作的副本中是找不到那个
bug，都可以根据tag重新rollback回去，或checkout出那个快照。
        tag给开发人员带了这样的便利，因此在任何重要的开发阶段，都应该打上tag。

        一般性的，在下面的情况都应该考虑给你的工程简历一份快照（tag）：
        完成了某个重要的功能
        在每一个milestone
        在去掉某个存在功能之前
        在测试开始之前
        在你对源文件做重大修改之前
        新建分支（branch，下文会详细谈到）的时候
        很并分支之前

       当然了，这些都是一般性的建议。其实我感觉是只要你觉得做的修改可能会有副作用的时候，就应该打上tag。

 

配置管理工作一般就几个环节： 1、指定配置计划 2、标识配置项 3、版本管理 4、变更管理 5、配置审计 6、统计配置状态

配置管理工作包括：

1. 确定那些是要进行配置管理的工作产品(配置项)。

2. 用适当的工具建立配置管理系统，建立配置库。

3. 用组织规定的办法标识配置项(打标签：标识代号、版本

号等) 。

4. 控制变更、分析变更带来的影响，变更基线。

5. 建立配置管理记录。

6. 建立和报告配置基线。

7. 执行配置审核(有人对配置库、配置项、标识、基线作检

查)。