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是版本树演进的一个分支，为了不影响主枝，可以作为个人的工作位置，或者某定制开发的位置，如果将来有必要将该定制合并到主枝，可以使用配置库提供的合并功能。
httpblog.myspace.cne406532053.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的流程)
构建-提交测试-修改代码-构建-提交测试直至测试通过-配置审计-建立基线-走审批流程-发布
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企业版
linuxUbuntu（乌班图），Fedora，OpenSUSE，Debian（待宾），Mandriva，Mint，PCLinuxOS，Slackware，Gentoo，CentOS，FreeBSD
httpwww.cnbeta.comarticles112817.htm
unixAUX 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进行比较。