http://bbs.scmroad.com/viewthread.php?tid=1496
1你为什么要申请配置管理工程师这个职位?
我们公司已经通过了CMMI3,我在现在的公司就是做配置管理工程师的,我熟悉配置管理,并喜爱这份工作,希望能继续从事该工作。
2你觉得自己能否胜任这个职位?
能胜任,我们公司已经通过了CMMI3,并且日常工作都是按照CMMI3的流程规范进行的,并不是为了过级而过级,是切实为了保证软件质量才过级的。我做配置管理已经有一段时间了,不仅现有工作能够完全胜任,还非常乐于学习,如果贵公司的该职位有什么知识是我掌握的不够好的,我能在短时间内满足工作要求。
3你觉得配置管理工程师需要掌握哪些技能?
配置管理工具的使用,构建脚本的编写,对工件的理解,了解软件工程,配置管理相关知识,配置管理的工作方法。
需要掌握的技能: 专业技能如程序设计, 配置管理, 变更控制(版本风险控制), 发布管理, 持续集成, 配置项(包括很多, 如文档, 源码等)规范等; 其它技能: 团队合作能力, 与人沟通能力, 配置管理威信等.
4配置管理工程师的职责有哪些?
职责包括: 保证工作产品的一致性、完整性、可追溯性,管理配置项,维护配置库,变更控制,发布管理。
5配置管理能给项目带来的好处有哪些?
因为配置管理保证了配置项的完整和可追溯,使团队成员可以拿到所需工件的所需版本,不会因为某个人的习惯问题,导致配置项缺失(比如东西在某人本机保存,人离职了,东西就找不到了);
变更控制使团队每个人都了解到谁改变了哪些东西,保证了所有团队成员的信息对称;(比如需求已变化,但测试人员不知道,还按照老需求来测试,结果当然是不符合)
6作为一个配置管理工程师,哪些方面是工作的重点?可能的难点会有哪些?
branch,是用来做并行开发的,这里的并行是指和trunk进行比较。
当多个人合作,可能有这样的情况出现:John突然有个想法,跟原先的设计不太一致,可能是功能的添加或者日志格式的改进等等,总而言之,这个想法可能需 要花一段时间来完成,而这个过程中,John的一些操作可能会影响Sally的工作,John从现有的状态单独出一个project的话,又不能及时得到 Sally对已有代码做的修正,而且独立出来的话,John的尝试成功时,跟原来的合并也存在困难。这时最好的实践方法是使用branches。 John建立一个自己的branch,然后在里面实验,必要的时候从Sally的trunk里取得更新,或者将自己的阶段成果汇集到trunk中。
有一个客户想对产品做定制,但是我们并不想修改原有的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都应该包括哪些内容?
10广义上的Change Request(CR)都包括哪些内容?
大家回答的时候可以从前往后叙述,这样也不容易忘记,还显得有条理.
14在安装配置方面有什么需要注意的?他的扩展功能有哪些?如何实现?
格式化硬盘该怎么样去做?
16请问你是否装过linux或者unix操作系统?请分别说出你所知道的linux 和unix 发行版本
18你一般会把哪些东西纳入版本控制?
19怎样可以保证团队中每个人都知道谁改变了哪些东西?
20Tag和Branch的区别是什么?在什么情况下该使用tag,什么时候用branch?
tag,是用来做一个milestone的,不管是不是release,都是一个可用的版本。这里,应该是只读的。更多的是一个显示用的,给人一个可读(readable)的标记。
branch,是用来做并行开发的,这里的并行是指和trunk进行比较。
21怎样管理技术文档——如产品架构文档——的变化?
22如果客户想要对一款已经发布的产品做出变动,你怎么处理?
23版本管理和发布管理有什么差异?
24对文本文件的变化和二进制文件的变化进行管理,这二者有什么不同?
25同时处理多个变更请求,或是同时进行增量开发和维护,这种事情你怎么看待?
28JRE是什么的缩写?干什么用的?
JDK 是Java开发工具包 (Java Development Kit ) 的缩写。它是一种用于构建在 Java 平台上发布的应用程序、applet 和组件的开发环境。JDK包括了jre。jre可以自动升级是其自身具有的功能。
“做配置管理最终的目标是什么?实现目标的路线是怎么样的?”
31 Perforce 与 Subversion有啥区别?
32怎么利用分支模式支持 Agile 开发?
33简述项目经历,描述哪个项目收获最大.......
34 Ant build.xml什么情况下用到 for 循环?如何写 for 循环?
2: 我接触的arm编译器, 它支持 *.c/*.cpp这样的格式, 但使用这种, 编译出来的东西偶尔会有问题,而且是很莫名奇妙的问题. 所以研发要求逐个编译. 于是乎, 就变成了如下一串.
arm -c 1.c,2.c,3.c,4.c,5.c............
如果脚本这样写,是多大的维护量. 更何况项目还多, 假如我们用<for>呢.只需要维护一个build.properties就可以了. 然后可能arm的编译参数对不同的代码又不尽相同.那我们再加上<if> <elseif>呢, 将判断条件同样用properties文件管理.
VMware 面试题
36配置管理和 IT人员有何区别?(这个问题当时让我很震惊)
37用 Perl 如何过滤 log 信息 (主要考的还是正则表达式)
perl xxx.pl >/tmp/file
2.
open(STDOUT, ">/tmp/file");
system("build");
38Perl 如何排序
39表示邮件的正则表达式是什么?
40 Perforce 如何支持分布式开发?
42Perforce 如何创建 depot?
43Perforce 如何创建 branch?
44Perforce 如何用命令同步一个changelist
45Perforce 命令行下如何把几个文件放到同一个changelist 当中?
46SVN 分支发布和主干发布各有哪些优缺点?
47我们公司现在没有配置管理, 你打算怎么开展?
2--争取一个小时的时间对大家进行统一的培训,真样你就会有一个发挥的时间;
3--在介绍配置管理和使用配置管理工具的时候,清楚明了,并且强调这是部门的要求,需要所有人员参与配合。大家都可以在实施配置管理过程中得到相应的关于软件过程管理的知识,体现程序员的基本素质,适应软件组织发展的要求;
4--自己要有信心,对同事要有热情,及时报告结果。
48以前你是怎么做配置管理的? 怎么样通过配置管理控制质量?
49 基线的概念? 什么时候应该打基线?
50 如果你来建立一个SVN库存, 请你画一下SVN库的结构目录.
51可不可以自己对SVN做扩展? SVN与其它工具的集成, 如bugzilla, mantis等?
52如何关联SVN修改记录与bugzilla, mantis的BID修改项?
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基本命令?
55介绍下你的工作经历
56CMMI 评估中,你负责什么?KPA?
57CMMI 过程改进过程中,CM 都收集了哪些数据?哪些方面做了量化?
可以参照业内的基本信息,但是还要根据项目的实际情况去定义,只定义对项目的有用的度量信息,而不要追求数量
58CM 如何支持分布式开发?不同工作地点之间如何管理,同步数据?
59配置管理计划(CM Plan)中都包含哪些内容?
60什么是基线?基线是如何产生的?如何管理基线?
61如何考核一个配置管理员(SCM)?
62配置管理员最基本的素质是什么?
64什么是 branch?
65什么是 tag?
几乎每次面试和每次找工作都要面临的问题,但是这确是一个很不容易回答的问题。
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、统计配置状态 |