配置管理工程师面试题目

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是版本树演进的一个分支，为了不影响主枝，可以作为个人的工作位置，或者某定制开发的位置，如果将来有必要将该定制合并到主枝，可以使用配置库提供的合并功能。e406532053.htm 需求一：有一个客户想对产品做定制，但是我们并不想修改原有的svn中trunk的代码。方法：用svn建立一个新的branches，从这个branche做为一个新的起点来开发 svn copy svnservertrunk svnserverbranchesep -m init ep Tip 如果你的svn中以前没有branches这个的目录，只有trunk这个，你可以用 svn mkdir branches 新建个目录需求二：产品开发已经基本完成，并且通过很严格的测试，这时候我们就想发布给客户使用，发布我们的1.0版本 svn copy svnservertrunk svnservertagsrelease-1.0 -m 1.0 released 咦，这个和branches有什么区别，好像啥区别也没有？是的，branches和tags是一样的，都是目录，只是我们不会对这个release-1.0的tag 做修改了，不再提交了，如果提交那么就是branches 需求三：有一天，突然在trunk下的core中发现一个致命的bug,那么所有的branches一定也一样了，该怎么办？ svn -r 148149 merge svnservertrunk branchesep

其中148和149是两次修改的版本号。

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

程)

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

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

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

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

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

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

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

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

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

以项目计划为输入，做项目的配置管理计划，计划包含采用何种配置管理工具、备份策略、目录的设置、权限如何分配、配置项的受控计划、基线的建立计划、审计计划；按照配置管理计划建立配置管理库，维护配置管理库、分配配置库权限，管理配置项（受控工件、建立基线）；进行配置审计；项目的变更控制；打部署包提交测试，进行版本发布。维护项目的配置管理工作表，按月整理事业部配置管理月报。大家回答的时候可以从前往后叙述,这样也不容易忘记,还显得有条理.

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