玉成配置+分支+构建文档.doc

1、 拉分支与分支合并策略1、 分支的基本概念就正如它的名字,开发的一条线独立于另一条线,如果回顾历史,可以发现两条线分享共同的历史,一个分支总是从一个备份开始的,从那里开始,发展自己独有的历史(如下图所示) 2、 分支创建的意义 创建分支的最大的目的就是跟主线进行并行开发的时候不影响主线的开发。 因为你在分支上所做的提交都只存于分支上，主线上的Update是看不到分支的修改的。如下图所示，trunk只能看到r344的版本，并看不到r343的版本。 如果大家都在一个主干上开发，A的工作没有做完，B根本无法调试运行，所以要开一个分支，减少B对A的依赖，保证bug修复与功能开发并行，不会出现堵塞情形。（什么时候应该使用分支呢？例如你接到了一个任务，完成这个任务需要三四个人的合作，你们之间需要共享资源，那们就可以创建一个专为这次任务的分支，参与此次任务的人员则在分支上做开发，等完成之后再合并到主线上，才不会出现将实现了一半的不完成功能也提交到主线上，影响主线的正常工作。又或者自己需要一个较长的开发周期来完成任务，这么长的时间内如果一直没有将资源进行提交，万一丢失了就前功尽弃了。当然分支不是只用于此类情况，还有其它很多种情况也能使用分支来达到目的。） 3、 使用分支需要不时merge使用分支需要注意,由于长期的独立开发，可能会在合并回主线时出现较多的冲突。所以在支线上开发间期如果发现主干有更新，而且这个更新有可能将来跟你产生冲突，那你可以先将主线的内容合并到分支上。已免等到做了大量修改再来更新。(其实此过程跟分支合并到主线上是一样的操作，只是目的地不同。) 4、 创建分支 假设目前我们版本库中的项目的布局如下图： 我们的项目放在了trunk（主线）目录，另外还有branch(分支)和tags(标签)目录，这样的布局是为了更清晰的区别主线、分支和标签三者的位置。 subversion对分支和标签是通过复制一份最新的版本库的快照来实现的。 在我们CheckOut的主线目录(trunk)上，右键点击然后选择“Branch/tag” 点击ok，分支创建完成。5、 分支合并主线在分支的根目录上右键点击，选择“TortoiseSVNMerge”。这个命令是包括三个参数的: 1. 初始的版本树 2.最终的版本树 3一个接收区别的工作拷贝。 弄明白这些概念之后我们继续往下操作。 在弹出的窗口中，选择主线目录和其版本号(初始的版本树)，再选择主线目录和最新的版本号（最终的版本树），这里也可以是某一个版本号但应该比初始的版本树的版本号要高，接收区默认为你右键所指的目录在点击“Merge”，合并后的文件（即对分支上的文件补上了主线上修改的内容），如无冲突则可以在分支上像其它文件一样使用了，如果合并后的内容不满意，可以通过撤销来取消这次的合并操作，前提是未对合并后的文件做提交操作。 分支合并到主线跟从主线上合并内容到分支上类似 不同的是 1）、开始的版本库是分支创建的版本 2）、结束的版本库是完成所以开发工作之后的版本 3）、应用的目的是主线目录 关于转换工作拷贝、标签（标签在Subversion中跟分支是相同原理的，一个不去做任何的修改的分支就是版本库某一时刻的一个快照，相当于为某一个版本做了一个标签）以下6、7点内容为网上分支策略参考：6、多分支策略1）develop开发分支开发人员日常开发时使用的分支，它代表着最新的开发状态。大多数的时候，最新节点的版本是未经检验的、不可靠的。为了使develop的开发状态可控，根据代码提交频度，定期做一次集成+基本用例测试。如果可以引入单元测试，就更好了。2）deature特性开发分支特性开发分支作为对开发分支的补充，保证不会因为特性开发的不完整，导致develop开发分支的不稳定。对大型功能的开发，或者试验性的开发，可以单独在本地检出feature分支进行开发。只要定期自己将develop分支的内容同步过来即可。3) master 主干分支代表着稳定状态的分支。任何时候，master分支的最新节点应该都是随时可发布的。当完成一个里程碑时(完成版本发布、完成hotfix)，应该在主干分支上打上tag，同时将变更内容同步到开发分支。4) release 版本发布分支实际一般主要用于发布测试版本，并提供开发人员在此分支上完成测试版本的bug修复。(如果是发布生产版本，一般直接取用某个测试版本即可) 测试版本应该从开发版本的当前最新节点检出。为了尽可能保证该节点的稳定性，项目经理应该提前通知开发人员做好代码提交。 修复bug时，可采用敏捷方式。通过每日集成+回归测试（只测试最新标记为修复的bug），完成快速迭代。 bug修复完成后，由项目经理将分支合入主干，并打上tag，同时将主干内容同步到开发分支develop。 bug修复完成后，release分支也不再有存在价值，可以由项目经理删除7、三分支策略如果你和你的开发团队同时面临以下几个问题,那么我强烈建议你至少考虑采用3分支的开发模式: 你开发只用一个分支或两个分支. 你的项目已经进入维护阶段,就是说项目本身已经上线使用. 用户的后续修改很多,而且仍然会有突发性的紧急错误修复. 你的代码需要通过测试人员测试才能发布. 你的发布人员就是简单的把现有的分支打包发布.如果你的项目组存在以上几个问题,那么可以说作为一个上线项目,你们的处境非常不利,你们每一次的发布都可能对原有系统产生不可预计的破坏;但不发布任何改动显然是不行的,为不断满足客户的要求,系统必须升级;要使每一次的发布对系统的影响降到最低,3分支方案是最基本的解决办法.要采用3分支的开发模式,其实并不困难,首先,我先假设一下你们项目组拥有以下3个角色(并不一定是3个人): 开发人员 测试人员 发布人员如何产生3分支: 首先,确认当前版本的代码和现行系统的内容一致. 把现行的分支命名为主干分支(Main) 从主干分支分出2个分支,分别命名为开发分支(Development)和发布分支(Release) 明确分支的负责人: 开发人员负责开发分支,测试人员负责主干分支,发布人员负责发布分支.如何使用3分支v 开发人员 开发人员人员可以在开发分支上开发当前版本,并任意签入代码. 注意已经提交测试的版本,不能在开发分支上修改. 开发人员仅当被测试人员通知修复错误时,才能在主干分支上修改指定的错误代码,并签入. 开发人员仅当被发布人员许可的情况下,才能在发布分支上修复紧急错误;注意紧急修复一般都是非常紧急和微小的,如果改动较大,应该考虑进入版本开发. 如果开发人员认为某一个版本已经开发结束,他有权把开发分支现有的代码完全合并入主干分支,提交测试.(只有一个特例,就是上一个版本还没有通过测试并发布,那么下一个版本就不能合并入主干分支,这属于项目管理中的失误,并不在本文章讨论范围)v 测试人员 测试人员有权在测试出错误后,让开发人员在主干上直接修复. 测试人员需要定期,将主干分支代码完全合并到开发分支. (这一步看似简单, 但其实十分重要!) 测试人员可以在测试通过后,将主干分支完全合并到发布分支,移交发布人员准备发布.v 发布人员 发布人员可以允许开发人员直接在发布分支上修复紧急错误. 紧急修复后,发布人员需要把发布分支完全合并到主干分支. 发布人员可以编译发布分支,并制作发布版本. 不过开发中不可能是一帆风顺的,紧急事件和临时变更经常发生,面对各种开发中的紧急情况,我们应该如何利用多分支开发来减少临时变更带来的风险.(而且在处理某些特殊事件时,必须采用面向修改集的代码合并技术才能解决问题,但产生的合并问题是不可预见的,这也是出现临时变更时必须面对的风险.) 特殊场景处理办法开发版本中任务需要紧急发布不能保证开发的质量,对系统稳定极为不利,建议至少等到测试阶段再更新测试版本中任务需要紧急发布前提是该任务已经通过测试,然后将该任务相关的修改集单独合并到发布分支,然后紧急发布系统开发版本中任务被取消回滚该任务对应的修改集,如果和其他代码重叠,解决合并问题测试版本中任务被取消同样采用回滚的方式,但回滚后,代码必须再次合并回开发分支开发版本中任务被延期在版本开发结束时,采用修改集合并的方法代替最新版合并方式,把除该任务以外的修改集一一合并到主干分支,留下的修改集进入下一个版本.测试版本中任务被延期类似于上面的方法,把版代码合并到发布分支时,跳过该任务对应的修改集,把剩下的修改集分别合并入发布分支发布,被跳过的修改集保留到下一个版本提交.紧急错误修复被取消回滚紧急修复代码,如果该修复代码已经合并回主干分支了,还需要把回滚后代码再次合并回主干分支,当然通过定期合并,还将合并回开发分支.2、 每日构建环境准备进展tomcat+Hudson+Maven+SVN_快速搭建持续集成环境1、 HudsonHudson 是一种革命性的开放源码 CI 服务器，它从以前的 CI服务器吸取了许多经验 教训。Hudson 最吸引人的特性之一是它很容易配置：很难找到更容易设置的 CI 服务器，也很难找到开箱即用特性如此丰富的CI 服务器。Hudson 容易使用的第二个原因是它具有强大的插件框架 ，所以很容易添加特性，例如添加tomcat插件后，可以方将build好的war,jar包方便的部署到Tomcat里。2、MavenMaven 是一个顶级的 Apache Software Foundation 开源项目，创建它最初是为了管理 Jakarta Turbine 项目复杂的构建过程。从那以后，不论是开源开发项目还是私有开发项目都选择 Maven 作为项目构建系统。3、 Subversion（svn）：版本控制软件，这里我用的是1.7版本。4、 工具的安装1）hudson的安装，Hudson的安装：Hudson的安装有两种方式：可以将Hudson部署到Tomcat下面运行，将下载的hudson.war直接放到Tomcat的webapp下，启动tomcat就ok了。还可以使用命令启动hudson。步骤：首先下载hudson.war,然后可以在一个盘符下建立一个文件夹，如D:hudson（自己可以随意建立），然后将这个路径设置环境变量，Hudson_Home=D:hudson，最后使用命令java -jar hudson.war启动hudson2）maven的安装把maven.zip解压到D:apache-maven-3.2.1（或者你自己想解压的位置，我是如此配置的）下面就是配置环境变量了。MAVEN_HOME=D:apache-maven-3.2.1在Path 中加入%MAVEN_HOME%bin测试是否安装成功，可以在命令行下输入mvn -v，出现如下界面，说明安装成功6、 配置hudson工程启动tomcat后浏览器上输入http:/localhost:8080/hudson-3.1.2/ 就可以访问hudson的dashboard界面了。hudson前面的配置使用默认的就可以了，只需要配置几个重要的选项就ok。1） Maven和JDK配置Maven这里的设置，就是取个名字，然后路径中指定maven的解压路径。如上图所示。在这里设置时，我一般去掉新增，而是直接指定MAVEN_HOME,我的maven是装在D:apache-maven-3.2.1（依个人设置）这里的，直接填入即可。Jdk的设置是必须的，如果你在这里没有设置jdk的路径的话，在build工程的时候有可能会报这个错误，如下图所示所以正确的设置也是去掉新增选项，直接填写名称和 JAVA_HOME我的JAVA_HOME是安装在C:jdk1.6.0_45这里的，所以直接填入即可。填写好的JDK设置如上图。2） shell,Ant,Maven,CVS等等，这些可以不用设定。这里就不做介绍啦，如果想了解的更深，右边的“help”（右边的蓝色小问号）会有很大的帮助。3）E-mail Notification 这个主要是邮件提醒，可以不用设置，要感兴趣的话，可以这样设置，具体参考右边的蓝色小问号。SMTP server-mail服务器地址（）Default user e-mail suffix-邮件的后缀名（123.com）System Admin E-mail Address-管理员用户的邮件帐号123123.comHudson URL-访问hudson的URL（:8080）至此，Hudson的全局配置就差不多了.7、 创建CI工程。1）点击左侧列表菜单的新建任务,出现如下界面：点击Ok后就进入新工程的具体设置。2）进入设置如下图：Project Name 在你建立项目的时候已经取过名字了.如果你哪天想改名字,就在这里改就可以了.Description 这里主要是写对TestJob这个项目的描述,可以写项目的参与者,项目起止日期等等,可以说这个地方是美化界面+项目描述+提示信息等等.Discard Old Builds 建议开启这个选项,很正常的大家都会在自己的目录下建立项目后,然后再用hudson去构建环境。Advanced Project Options: 这里是表示你可以对你的项目构建进行一定的设置，它下面包括两个小的选项，（1）.Quiet period: 时间可以根据项目的需要来设定。这个时间是说明从构建开始到项目真正开始构建之间的时间差，比如，我将此时间设为300S，说明TestJob在要开始构建之前会有5分钟的时间缓冲，这个是非常人性化的，因为如果有大量的代码需要提交，会需要很长时间，如果没有等待时间的话很容易出现少代码的情况导致整个构建过程的失败。（2）.Use custom workspace：这个地方你可以将可以对外公布的东西放在一个特定的目录下，然后把这里的值设成该目录。Source Code Management：呵呵，这里就是要结合版本控制工具的地方了，我们用的是svn,所以设置如下在Repository URL里填入你的仓库地址，svn有两种地址，一种是http:/.这样的，一种是svn:/.的，我这里是用的是：https:/yucheng-pc/svn/hubson/branches/branch1（注意，这里是工程的根目录，也就是pom.xml所在的目录）Use update: 这里选项勾上后，每次检测到库上有更新，就会使用svn update命令；如果没有勾上的话，那每次使用的是svn checkout命令，理由是update要比checkout命令省相当多的时间。Build Triggers：可以理解为你想以什么样的方式去触发你的构建，以其它构建成功后为基础，还是周期性的构建，还是根据poll SCM(变更触发)来触发构建。我习惯选择 Build periodically，并在Schedule中输入 0 12,20 * * *。注： Schedule的配置规则是有5个空格隔开的字符组成，从左到右分别代表：分 时 天 月 年。*代表所有，具体参考右面的蓝色小问号0 12,20 * * * 表示在任何年任何月的任何天的12和20点的0分 进行构建Build：这个选项主要加载我们自己的脚本。和Build Settings没有什么特殊的设置，可以不用设置Post-build Actions：这里也可以说是做一些发布啊，善后啊之类的，可以看到有mail, artifacts, publish之类的。Hudson的自动部署：一般我们build成功一个项目后，Hudson会在%Hudson_home%/jobs/projecct_name/ workspace/ projecct_name/ target下发布一个项目的war，jar包。（注释：project_name是你的项目名称，Hudson_home一般在C:Documents and Settingsusername.hudson下。其中username是你当前的系统用户，但是我们想build成功后，就要看到我们项目进展的怎么样了，就想通过Tomcat来加载这个war包直接看效果，这时，我们不得不手动的把这个war包拷贝到Tomcat的webapp下，然后启动Tomcat。很麻烦吧，这里介绍的就是这种简单的自动部署方法，可以通过Hudson的一个插件，呵呵，现在前面提到的那个插件就起大作用了。点击左侧列表菜单Manage Hudson，然后选择第三项Manage Plugins，这个选项的功能是管理Hudson插件的，（或者直接输入：http:/localhost:8080/hudson/pluginManager/）在这里说明了Hudson的扩展性有多么的强大，在插件管理中心点击Advanced,在upload plugin 中上传刚才下载的插件，上传完毕后需要重启hudson才能完成安装(即重启tomcat)，重启后点击New Job后，然后建立一个新的Job时（已有的项目，直接点击进入项目，然后点左侧的功能菜单configure），在配置页面的Post-build Actions项下面会多出一项功能：Deploy war/ear to a container，在这里WAR/EAR file:就是填写hudson所打好的war包路径，之前说过，hudson打好的war包是放在这里的，所以这里就写%Hudson_home%/jobs/projecct_name/ workspace/ projecct_name/ target/你的war文件的名称.war。Container选择你的Tomcat的版本。Manager user name：填写Tomcat的用户名，默认是admin, Manager password:填写Tomcat的密码，默认是空。Tomcat URL：填写http:/localhost:8080/就ok了，至此保存就可以了，这样，当你再build此工程的时候，war文件会自动部署到你的tomcat的webapp目录下。设置如下图所示3、 配置脚本简单应用1、代码库checkout update进入所需要放置代码的目录。svn checkout https:/yucheng-pc/svn/test/trsvn cleanupsvn update2、在hudson上用不到此命令，因为hudson已经把svn插件集成进去了，在hudson上需要用到的脚本比较简单，如下：echo test buildSet bat=D:apache-tomcat-6.0.41webappsjobskkkkkkkkkkkkkkkworkspacetarget2.MemDBcall mvn cleancall mvn packagecall mvn clean installCd %bat%Call startup.bat以上路径为自己定义的work