先来说几个名词的含义吧:
版本库:repository
主线:trunk
分支:branch
标签:tag
检入:check in
检出:check out
基线:被完整标记出来的,具有整体的完整代码的版本
trunk:是用来做主方向开发的,一个新模块的开发,这个时候就放在trunk,当模块开发完成后,需要修改,就用branch。
branch:是用来做并行开发的,这里的并行是指和trunk进行比较。
tag:是用来做一个milestone的,不管是不是发布版本,但都是一个可用的版本。这里,应该是只读的。更多的是一个显示用的,给人一个可读的标记。
由于公司刚成立不久,对版本控制竟然是完全手工的。哎,看着就揪心,万一哪天出事故,估计要哭死!但是大家现在好像都在坐以待毙,我知道大家都是觉得用一个新工具上手比较难,所以好像得过且过吧,还有一个重要的原因就是,我们公司管理制度没有搞起来。要让大家组织培训吧也不行,所以现在要让大家心甘情愿的弄确实难度很大。在大家都反对的情况下,想过放弃了吧。但是心里还是强烈的想把它做起来。下面就来说说我的心得。
软件的配置与管理,权威的定义太多高大上,根本看不懂,大家可以试试看看:
我觉得只要是正常人都看不明白,云里雾里的。
呵呵,在这里我就要说我理解的配置管理了。其实也是偷拿别人的理解啦。
软件配置管理既是:软件的资产管理:
1、软件历史版本的记录
2、修改的原因,谁修改的,这些记录必须有,以便后来的维护
3、两个人同时修改文件,防止版本的覆盖问题
可以形象的比喻为:保险柜、岩钉、脚印。请大家仔细体会这几个词与软件版本控制之间的关系。
svn版本控制的原理就是,找个大的公共储存区,保证,每次提交前去公共区里拿到最新的代码,每个人拿到最新的代码去提交,这样就不会导致版本不一致问题。当然如果修改的是同一行代码,这时候就会有冲突,需要人工去解决。
解决充的方法有两种:
1 串行锁模式
2、并行复制修改合并模式,每个程序员都可以先拷贝一个副本在自己本地进行开发修改,最后进行商量合并。
这两种模式都有自己的适用范围:
锁模式适用于哪些不能合并的元素,例如图片元素。
复制修改合并模式适用于代码等可以合并操作的元素。
任务单元-活动-变更集
以上三点都是一个概念就是指同一个意思,为什么要说任务单元呢?
其实这里就是我们要说的项目提交粒度问题,我们将一个大任务分成很多小任务,这样的小任务一旦完成,并做好了相应的 测试,那么此时就可以检入操作。这样的检入操作既保证后期能够及时的合并,(因为开发时间越长,合并的难度就越大),也可以防止没有完成的提交导致编不能通过的问题。
下面我们来说一下版本号的命名:
版本号一般分为:主版本号、特征版本号、BUG修复版本号。
主版本号标志着产品的第几代,特征版本号表示新叠加的功能,bug修复版本号很显然就是每次版本的bug修复编号。bug修复编号也标志着产品质量的提升。
一个号的命名规则可以使我们更好的找到对应的版本。
系统集成:就是将开发好的各个开发好的模块组织起来,完成一个能运行的整体。
系统集成看起来是开发好模块后完成,但是在实际的研发中不是这样的,你想像一下这个场景,A、B、C各开发好了一个功能,他们都能在自己的环境下运行,但是他们不知道的是他们之间修改的代码有很多交叉,这样合并集成的难度就会非常大,所以在适时的集成就非常重要了。也许是打好了框架,也许是完成了雏形就可以进行集成了。
及早、经常、持续集成:
持续更新中。。。。。