SVN环境搭建完整步骤

1、SVN安装

从VM新建虚拟机

1）安装路径：D：\ubuntu-test

使用ubuntu 软件：c:\svn安装软件\ubuntu-10.04.1-desktop.i386.iso

Network adapter：Bridged

Ubuntu登录账号/密码：kiki/kiki

安装完成，重启ubuntu，打开terminal，自动获得了一个IP（172.28.6.13）。

2) 设置，安装过程

a) 设置 ip 和dns上网。

    Step1,

sudo –s 转成root用户，方便操作。

    Step2,

设置IP, vi /etc/network/interfaces

加入：

auto eth0

iface eth0 inet static

address 172.28.6.239

netmask 255.255.0.0

gateway 172.28.16.1

    Step3,

           Sudo nano /etc/resolv.conf

           是一个编辑工具，设置DNS。

           加入：nameserver 10.58.100.1

    Step4,

重新启动 networking 服务：

sudo /etc/init.d/networking restart

    总结：设置OK，ping 172.28.6.69成功。

b) apt-get update 先更新一下源。

c) 安装VIM

    apt-get install vim

d) 安装openssh-server

e)  安装subversion

f) 安装subversion-tools

g) 安装apache2

h) 安装libapache2-svn

i) 安装tree

j) 设置apache2下的SVN

       vim /etc/apache2/dav_svn.conf

       设置如下：

<Location /test/>

 DAV svn

  SVNListParentPath on

   SVNParentPath /home/repo/

  # SVNIndexXSLT "/apache2-default/svnindex.xsl" （注释掉，否则会有xml的错误，不能显示）

  AuthType Basic

  AuthName "Subversion Repository"

  AuthUserFile /etc/apache2/dav_svn.passwd

    Require valid-user

  AuthzSVNAccessFile /etc/apache2/dav_svn.authz  z居然泄露了，害我找了好久的原因

</Location>

PS：

1）刚安装好的apache2没有dav_svn.passwd文件，

使用vim 创建，

然后htpasswd -b dav_svn.passwd kiki kiki  更新密码。

创建dav_svn.auth文件，设置*=rw方便测试。

权限文件设置注意：[]*=rw,并且具备权限继承性，子目录的权限将代替父目录的权限。

2）创建测试所用的版本库，路径在：/home/repo/test1,其中test1是版本库。

3）重启apache服务  /etc/init.d/apache2 restart

4)  设置创建的帐户文件所属者为www-data.

设置创建的库所属者为www-data,

root@kiki-desktop:/etc/apache2# chown www-data:www-data dav_svn.passwd

root@kiki-desktop:/etc/apache2# chmod 777 dav_svn.passwd

root@kiki-desktop:/home# chown -R www-data:www-data repo

5）访问：http://IP/test/库名，SSH远程登录ubuntu出现中文乱码时，设置LANG=””;

2、SVN版本对比

2.1   Subversion 1.6的新东西

改进的认证数据处理

版本库根的相对URL

svn:externals的改进

目录树冲突的检测

文件系统存储改进

Ctypes Python绑定

改进的交互式冲突解决

稀疏目录的排除选项

svnserve的日志支持

察看历史的新HTTP URI语法

命令行客户端改进

API变更、改进以及多种语言绑定

超过65项新的bug修正和提升

参考：http://www.subversion.org.cn/?action-viewnews-itemid-99

2.2   以下为共进实际情况：

服务器：10.58.100.247 Subversion1.5

客户端：10.58.102.3    Subversion1.6

改进和bug修正

改进的交互式冲突解决(客户端)

svn up:

3、SVN备份

1. 10.58.101.6 截图：

2. 10.58.100.247 截图

2. 10.58.101.6截图：

1. Rsync（remote synchronize）是一个远程数据同步工具，可通过LAN/WAN快速同步多台主机间的文件。Rsync使用所谓的“Rsync算法”来使本地和远 程两个主机之间的文件达到同步，这个算法只传送两个文件的不同部分，而不是每次都整份传送，因此速度相当快。

第一次连通完成时，会把整份文件传输一次，以后则就只需进行增量备份。

2. Rsync支持大多数的类Unix系统，无论是Linux、Solaris还是BSD上都经过了良好的测试。此外，它在windows平台下也有相应的版 本，如cwRsync和Sync2NAS等工具。

3. Rsync的基本特点如下：

　　1.可以镜像保存整个目录树和文件系统；

　　2.可以很容易做到保持原来文件的权限、时间、软硬链接等；

　　3.无须特殊权限即可安装；

　　4.优化的流程，文件传输效率高；

　　5.可以使用rsh、ssh等方式来传输文件，当然也可以通过直接的socket连接；

6.支持匿名传输

4. rsync是一个功能非常强大的工具，其命令也有很多功能特色选项，我们下面就对它的选项一一进行分析说明。 Rsync的命令格式可以为以下六种：

　　rsync [OPTION]... SRC DEST

　　rsync [OPTION]... SRC [USER@]HOST:DEST

　　rsync [OPTION]... [USER@]HOST:SRC DEST

5. 从远程rsync服务器中拷贝文件到本地机。当SRC路径信息包含”::“分隔符时启动该模式。如：rsync -av  root@172.16.78.192::www  /databack

　 从本地机器拷贝文件到远程rsync服务器中。当DST路径信息包含”::“分隔符时启动该模式。如：rsync -av  /databack  root@172.16.78.192::www

-a, --archive 归档模式，表示以递归方式传输文件，并保持所有文件属性，等于-rlptgoD

-v, --verbose 详细模式输出

4、SVN分支策略（常用分支模式-摘自svn指南.doc）

参考资料：

Subversion1.4手册       http://www.subversion.org.cn/svnbook/1.4/svn.branchmerge.maint.html

Subversion1.6手册       http://i18n-zh.googlecode.com/svn/www/svnbook/zh/svn.tour.cycle.html#svn.tour.cycle.resolve

常用分支模式

版本控制在软件开发中广泛使用，这里是团队里程序员最常用的两种分支/合并模式的介绍，如果你不是使用Subversion软件开 发，可随意跳过本小节，如果你是第一次使用版本控制的软件开发者，请更加注意，以下模式被许多老兵当作最佳实践，这个过程并不只是针对 Subversion，在任何版本控制系统中都一样，但是在这里使用Subversion术语会感觉更方便一点。

发布分支

大多数软件存在这样一个生命周期：编码、测试、发布，然后重复。这样有两个问题，第一，开发者需要在质量保证小组测试假定稳定 版本时继续开发新特性，新工作在软件测试时不可以中断，第二，小组必须一直支持老的发布版本和软件；如果一个bug在最新的代码中发现，它一定也存在已发 布的版本中，客户希望立刻得到错误修正而不必等到新版本发布。

这是版本控制可以做的帮助，典型的过程如下：

开发者提交所有的新特性到主干。 每日的修改提交到/trunk：新特性，bug修正和其他。

这个主干被拷贝到“发布”分支。 当小组认为软件已经做好发布的准备(如，版本1.0)然后/trunk会被拷贝到/branches/1.0。

项目组继续并行工作，一个小组开始对分支进行严酷的测试，同时另一个小组在/trunk继续新的工作(如，准备2.0)，如果一个bug在任何一个位置被发现，错误修正需要来回运送。然而这个过程有时候也会结束，例如分支已经为发布前的最终测试“停滞”了。

分支已经作了标签并且发布，当测试结束，/branches/1.0作为引用快照已经拷贝到/tags/1.0.0，这个标签被打包发布给客户。

分支多次维护。当继续在/trunk上为版本2.0工作，bug修正继续从/trunk运送到/branches/1.0，如果积累了足够的bug修正，管理部门决定发布1.0.1版本：拷贝/branches/1.0到/tags/1.0.1，标签被打包发布。

整个过程随着软件的成熟不断重复：当2.0完成，一个新的2.0分支被创建，测试、打标签和最终发布，经过许多年，版本库结束了许多版本发布，进入了“维护”模式，许多标签代表了最终的发布版本。

特性分支

一个特性分支是本章中那个重要例子中的分支，你正在那个分支上工作，而Sally还在/trunk继续工作，这是一个临时分支，用来作复杂的修改而不会干扰/trunk的稳定性，不象发布分支(也许要永远支持)，特性分支出生，使用了一段时间，合并到主干，然后最终被删除掉，它们在有限的时间里有用。

还有，关于是否创建特性分支的项目政策也变化广泛，一些项目永远不使用特性分支：大家都可以提交到/trunk，好处是系统的简单—没有人需要知道分支和合并，坏处是主干会经常不稳定或者不可用，另外一些项目使用分支达到极限：没有修改曾经直接提交到主干，即使最细小的修改都要创建短暂的分支，然后小心的审核合并到主干，然后删除分支，这样系统保持主干一直稳定和可用，但是造成了巨大的负担。

许多项目采用折中的方式，坚持每次编译/trunk并进行回归测试，只有需要多次不稳定提交时才需要一个特性分支，这个规则可以用这样一个问题检验：如果开发者在好几天里独立工作，一次提交大量修改(这样/trunk就不会不稳定。)，是否会有太多的修改要来回顾？如果答案是“是”，这些修改应该在特性分支上进行，因为开发者增量的提交修改，你可以容易的回头检查。

最终，有一个问题就是怎样保持一个特性分支“同步”于工作中的主干，在前面提到过，在一个分支上工作数周或几个月是很有风险的，主干的修改也许会持续涌入，因为这一点，两条线的开发会区别巨大，合并分支回到主干会成为一个噩梦。

这种情况最好通过有规律的将主干合并到分支来避免，制定这样一个政策：每周将上周的修改合并到分支，注意这样做时需要小心，需要手工记录合并的过程，以避免重复的合并(在“手工跟踪合并”一节描述过)，你需要小心的撰写合并的日志信息，精确的描述合并包括的范围(在“合并分支到另一分支”一节中描述过)，这看起来像是胁迫，可是实际上是容易做到的。

在一些时候，你已经准备好了将“同步的”特性分支合并回到主干，为此，开始做一次将主干最新修改和分支的最终合并，这样以后，除了你的分支修改的部分，最新的分支和主干将会绝对一致，所以在这个特别的例子里，你会通过直接比较分支和主干来进行合并：

$ cd trunk-working-copy

$ svn update

At revision 1910.

$ svn merge http://svn.example.com/repos/calc/trunk@1910 \

            http://svn.example.com/repos/calc/branches/mybranch@1910

U real.c

U integer.c

A newdirectory

A newdirectory/newfile

…

通过比较HEAD修订版本的主干和HEAD修订版本的分支，你确定了只在分支上的增量信息，两条开发线都有了分枝的修改。

可以用另一种考虑这种模式，你每周按时同步分支到主干，类似于在工作拷贝执行svn update的命令，最终的合并操作类似于在工作拷贝运行svn commit，毕竟，工作拷贝不就是一个非常浅的分支吗？只是它一次只可以保存一个修改。

5、Subversion管理代码最佳实践

代码管理实践
代码仓库均采用svn来管理

5.1   代码目录的创建：
一般创建三个目录分别为
trunk(主干)，
tags（标签/标记)，
branches(分支)。
tags和branches下一般为根据需要从trunk目录拷贝过来的。

5.2   tags的创建要求：
代码在一种平台下通过编译（必须）
代码编译出来的版本通过一定的冒烟测试。
在项目要求的平台都可以编译通过。
一般有一个安装包给测试时，就需要在tags下建立对应代码的标签。
tags下的代码一般不可以修改。

5.3   两种代码管理模式介绍:
a、始终分支系统(OpenOffice社区采用管理方式)
典型特征:项目较大，代码较多，编译时间较长，参与人员比较多时。
每个用户对每项编码任务的创建或操作都是在私有分支中进行的。
编码完成后，原编码者、同级或经理将对所有私有分支的更改进行审查并将它由合并到 /trunk 中。
里程碑的创建
集成人员集成将开发人员提交的功能集成到主干上，编译通过后，提交的主干上，集成了一定的功能后，创建一个里程碑版本，一般建议按周创建里程碑版本。并在tags下创建相应的代码快照，并将安装包传至指定位置。
开发人员基于里程碑版本开发。
开发人员一般基于最新的里程碑版本创建分支，并在分支上工作，并在自己的分支上提交，在提交到svn之前需要编译通过。开发人员需要根据自己开发情况来同步到主干的里程碑代码。如果需要集成到主干上，需要同步到最近的里程碑。
测试人员.
测试人员对开发人员的代码进行测试，达到一定的测试标准后，测试通过，然后交由集成人员来集成。

b、按需分支系统（Subversion社区采用管理方式）
适用方式代码较少，或者参与开发的人员较少
开发人员可以直接在主干上提交。开发负责人来编译版本给测试。
开发者把所有的新特性提交到主干。 每日的修改提交到/trunk：新特性，bug修正和其他。新近的开发人员不能提交代码，交由有经验的开发人员验证后来提交到主干上。
当开发小组认为软件已经做好基本发布的准备(如，版本1.0)然后/trunk会被拷贝到/branches/1.0。这个主干被拷贝到“发布”分支。然后在发布分支上继续修改bug.
如果bug修正经测试达到一定的要求认为可以完成时，可以拷贝到/tags/1.0.0，这个标签被建立并发布给相关人员。

5.4   向svn库提交提交代码要求
针对每次提交到主干上的代码均需要编译通过
代码每次提交到svn上均需要添加注释。
每个人都用自己账号来提交代码。

6、参考资料

l         分支模式在SVN环境下的应用

http://www.webwoo.net/SVN/svnsy/2009/1211/51007.html

l         持续集成之“分支策略”

http://wwling2001.blogbus.com/logs/164479726.html

l         SVN常用分支模式

http://i18n-zh.googlecode.com/svn/www/svnbook-1.4/svn.branchmerge.commonuses.html

l         配置管理一问一答

http://qa.uml.net.cn/Question/List.aspx?t=1&tid=13&tn=%E9%85%8D%E7%BD%AE%E7%AE%A1%E7%90%86&area=0

l         百度-主干开发，分支提测

http://www.cnblogs.com/topiemie/

l         subversion管理代码最佳实践

http://www.zxbc.cn/html/20081212/68890.html

l         Subversion中文站

http://www.subversion.org.cn/?action-category-catid-1

l         Subversion FAQ(常见问题解答)

http://subversion.apache.org/faq.zh.html

[原创]配置管理员(CM)如何接手一个正在进展中的项目？

2012工作计划

工作总结需含概以下内容：

1、   简述您上一个年度所具体负责的工作、工作业绩，以及您对自己的工作业绩是否满意；

2、   简述您的下一步工作及学习计划，以及您今后的工作目标定位；

3、   期望公司及部门改善的地方；

1. 从事版本管理工作之后，2011主要完成如下工作：

1）.编写软件配置管理文档：如软件配置管理计划，及软件配置状态报告。

2）.根据深圳SCM主管的配置管理整理方案，完成对上海各事业部的配置库目录结构的整理及权限文件的整理，提高代码资源的管控。

3）.在上海公司使用统一编译服务器，统一项目编译环境，保证代码及时提交入库。

4）. 推广持续集成，自动编译，提高网关研发同事出版本的效率,及代码编译不通过的提醒，自测可以直接从CI工具hudson中取得，同时保证研发自测版本与测试部版本的一致性；

5）. 增加SVN密码修改模块，通过自己查找资料，经过环境搭建测试，完成SVN密码修改模块，同时统一上海代码服务器的账号文件，清除废弃及重复的账号，避免相同的服务器使用多个账号，避免了混乱麻烦的状况。。

6）. SVN服务器备份，使用本地备份及异地备份，全量备份与增量备份相结合的方式，进行代码库数据的备份，避免一旦服务器出现异常导致无法使用带来的巨大损失。

7）. 深圳同事提交代码出现卡死的情况，针对深圳同事的具体情况，使用账户模拟场景，再现问题，及研究SVN触发的脚本，找出问题根源，并测试通过，改善了同事的工作过程。

8）. 深圳配置管理主管指导交流，提高了我自己对配置管理的认识，同时按照深圳高工给出的配置管理方案对上海代码库进行整理，目前已经完成EOC，无线，网关的代码库整理工作，然后我们会严格按照配置管理策略来指导及执行项目的配置管理工作。

2. 2012的工作及学习计划如下：

1）.策划一组SVN系列培训，提供研发同事使用SVN的熟练程度。

    大致会包括如下的培训内容：

SVN客户端使用；

SVN服务器使用；

SVN常见问题解决方法；

2）.精通shell，使版本管理工作更高效。

3）.努力参与项目，使软件配置管理更加深入项目，做好软件配置管理的本职工作，改善研发过程。

按照软件配置管理计划来参与项目，完善软件配置状态报告，及项目基线管理及版本管理；

4）.精通SVN，提高应对版本库出现的各种问题的解决能力。

5）.深入了解软件配置管理思想，在工作中要尽可能的去体会以及应用在工作中。需要多搜集资料，学习别人的经验，同时结合本公司现状，加以应用。力求把上海的配置管理工作做好，做到位。

6）．尝试实现SVN二次开发，提高研发过程。

7）.开展软件配置管理系统培训，普及软件配置管理知识，培训内容包括：

           SCM基本概念培训；

           SCM规范培训；

           SCM策略培训；

严格按照软件产品发布流程发布软件版本是建立和完善软件产品版本控制，保证软件产品质量的关键过程之一。参与软件产品发布的人员主要是测试负责人和BM（Build Master）。

公司软件产品发布的规程如下：

1、 发布准备。
发布之前，所有程序freezed由测试人员进行确认测试；
检查qcs系统内登记的所有bug都已经被fixed，或者遗留的bug不影响系统的使用，如果有严重bug未解决（级别为must fixed）不能发布；
程序打包前做冒烟测试。

2、 测试负责人编写release产品质量报告进行质量分析和总结。

3、 源码、文档入库。
源码包括数据库创建脚本（含静态数据）、编译构建脚本和所有源代码；
文档包括需求、设计、测试文档，安装手册、使用手册、二次开发手册、产品介绍（ppt）、使用demo等。

4、BM进行程序打包；标记源码、文档版本tag。

5、 BM填写发布基线通知并通知相关人员；BM经理对发布基线进行审计。

6、在qcs系统上新建产品发布计划，填写配置项，执行发布计划（发布产品）。

7、上传程序包、使用文档至download站点。

8、 编写发布说明readme.txt（或者release note）。
Readme的内容应该包括产品版本说明、产品概要介绍、本次发布包含的文件包、文档说明、本次发布包含或者新增的功能特性说明、遗留问题及影响说明、版权声明以及其他需要说明的事项。

9、 正式发布通知。
通知开发、测试、市场、销售各相关部门并附上产品发布说明和产品介绍。

10、后续工作。
产品发布后，在使用过程中可能还会发现一些bug。在不影响正常使用的情况下，这些bug将在下一版本发布时解决；如果bug严重影响使用，必须打patch或者按照流程重新发布。

11、 临时发布。
软件产品未正式发布前，可能需要一个临时版本供开发人员或者用户应急使用，这时候需要临时发布一个版本。这个版本只包括基本的程序包和必要的使用说明。临时发布需要通知相关开发、测试人员；BM需要为源码、文档打tag标记。

12、 软件产品发布后，即建立了一条发布基线。
所有用户安装及二次开发必须在此基线上进行，开发人员不能直接从cvs或vss上check 代码编译交付用户使用或者进行二次开发。

另一种说法：

公司软件产品发布的规程如下：
1.FAE首先向版本管理员提交需求;
2.版本管理员将需求提交给项目经理,由经理确认需求以及发布基线;
3.发布准备:发布之前，先将当前主干中的所有程序freezed,并从主干中拉出一条发布分支branch,由开发人员对其进行功能测试:检查所有bug是否都已经被fixed，或者遗留的bug不影响软件的使用，如果有严重bug未解决暂时不能发布。
4.如果测试通过,则由相关开发人员进行程序打包；标记源码、文档版本tag。
5.开发人员将标记的源码和文档地址交予版本管理员,由版本管理员编写发布说明release list.release list内容应包括本次发布包含的文件包、文档说明;各类文件的存放路径,提供者及tag信息;本次发布包含或者新增的功能特性说明；遗留问题及影响说 明；版权声明以及其他需要说明的事项。
6.管理员在jira上建立测试任务并邮件通知相关测试人员。
7.FAE测试,测试完成后，FAE向版本管理员反馈测试结果（确认所提需求是否全部实现，不然则列出哪些功能还存在不足或BUG）:如果测试没有通过， 将由版本管理员向开发组请求重新release内部版本，再交FAE重新测试;如果测试通过，则由版本管理员为当前的版本进行标记和命名,同时提交到发布 库中.
8.正式发布通知。邮件通知各相关部门并附上产品发布说明和产品介绍。
9.由FAE将发布后的版本打包release给客户;
10.后续工作。产品发布后，在使用过程中可能还会发现一些bug。在不影响正常使用的情况下，这些bug将在下一版本发布时解决；如果bug严重影响使用，必须打patch或者按照流程重新发布。
11. 临时发布。软件产品未正式发布前，可能需要一个临时版本供开发人员或者用户应急使用，这时候需要临时发布一个版本。这个版本只包括基本的程序包和必要的使用说明。临时发布需要通知相关开发、测试人员；管理员需要为源码、文档打tag标记。
12. 软件产品发布后，即建立了一条发布基线。所有用户安装及二次开发必须在此基线上进行，开发人员不能直接从svn上check 代码编译交付用户使用或者进行二次开发。

问题一：

@ERROR: chroot failed

rsync error: error starting client-server protocol (code 5) at main.c(1522) [receiver=3.0.3]

原因：

服务器端的目录不存在或无权限。创建目录并修正权限可解决问题。

问题二：

@ERROR: auth failed on module tee

rsync error: error starting client-server protocol (code 5) at main.c(1522) [receiver=3.0.3]

原因：

服务器端该模块（tee）需要验证用户名密码，但客户端没有提供正确的用户名密码，认证失败。提供正确的用户名密码解决此问题。

问题三：

@ERROR: Unknown module ‘tee_nonexists’

rsync error: error starting client-server protocol (code 5) at main.c(1522) [receiver=3.0.3]

原因：

服务器不存在指定模块。提供正确的模块名或在服务器端修改成你要的模块以解决问题。

问题四：

password file must not be other-accessible

continuing without password file

Password:

原因：

这是因为rsyncd.pwd rsyncd.secrets的权限不对，应该设置为600。如：chmod 600 rsyncd.pwd

问题五：

rsync: failed to connect to 218.107.243.2: No route to host (113)

rsync error: error in socket IO (code 10) at clientserver.c(104) [receiver=2.6.9]

原因：

对方没开机、防火墙阻挡、通过的网络上有防火墙阻挡，都有可能。关闭防火墙，其实就是把tcp udp的873端口打开。

问题六：

rsync error: error starting client-server protocol (code 5) at main.c(1524) [Receiver=3.0.7]

原因：

/etc/rsyncd.conf配置文件内容有错误。请正确核对配置文件。

问题七：

rsync: chown "" failed: Invalid argument (22)

原因：

权限无法复制。去掉同步权限的参数即可。(这种情况多见于Linux向Windows的时候)

代表多个源代码文件的一组版本。
比如有三个文件，aaa.c、bbb.c和ccc.h。可以对这三个文件做一个基线，取aaa.c的版本1.1，取bbb.c的版本1.3，取ccc.h的版本1.0。(1.1,1.3,1.0)就是一个基线。换
句话说，通常在vss和cvs里面做label，就是在做基线。

2) 基线提升：

一个文档如果经过讨论被通过了，被固定了，就可以说这个文档被“基线化”了，然后所有人就可以在这个“基线”的基础上工作。

当然，文档不可能一成不变，所以当对文档的修改仍然会不断进行，但这种修改并不会随时随地的添加到被“基线化”了的文档中去。因为既然是“基线”，就不能随便动。

但是到了一定时候，修改积累到一定程度，就需要把很多修改合并到原来的文档中去了，并生成一个新版本的文档作为团队中所有的人的参考标准，并把老的版本淘汰掉。这就叫做“基线提升”。

4）发行基线
你会对你要发行的代码，文档版本进行label, 比如Release2.2,
这样，你可以随时取出此版本作build，进行测试，发布。

5）产品基线
当发布时，你会对产品中所有的配置项进行label,包括可执行命令，文档手册，库文件。。。

8) 基线(Baseline)说起. 基线是软件文档或源码(或其它产出物)的一个稳定版本,它是进一步开发的基础.所以,当基线形成后,项目负责SCM的人需要通知相关人员基线已经形成,并 且哪儿可以找到这基线了的版本.这个过程可被认为内部的发布.至于对外的正式发布,更是应当从基线了的版本中发布.

      基线是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。

      参与项目的开发人员将基线所代表的各版本的目录和文件填入他们的工作区。随着工作的进展，基线将合并自从上次建立基线以来开发人员已经交付的工作。变更 一旦并入基线，开发人员就采用新的基线，以与项目中的变更保持同步。调整基线将把集成工作区中的文件并入开发工作区。

      建立基线的三大原因是：重现性、可追踪性和报告。

      重现性是指及时返回并重新生成软件系统给定发布版的能力，或者是在项目中的早些时候重新生成开发环境的能力。可追踪性建立项目工件之间的前后继承关系。 其目的在于确保设计满足要求、代码实施设计以及用正确代码编译可执行文件。报告来源于一个基线内容同另一个基线内容的比较。基线比较有助于调试并生成发布 说明。

      建立基线后，需要标注所有组成构件和基线，以便能够对其进行识别和重新建立。

      建立基线有以下几个优点：

      基线为开发工件提供了一个定点和快照。
      新项目可以从基线提供的定点之中建立。作为一个单独分支，新项目将与随后对原始项目（在主要分支上）所进行的变更进行隔离。
      各开发人员可以将建有基线的构件作为他在隔离的私有工作区中进行更新的基础。
      当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。
      您可以利用基线重新建立基于某个特定发布版本的配置，这样也可以重现已报告的错误。

      使用
      定期建立基线以确保各开发人员的工作保持同步。但是，在项目过程中，应该在每次迭代结束点（次要里程碑），以及与生命周期各阶段结束点相关联的主要里程碑处定期建立基线：
      生命周期目标里程碑（先启阶段）
      生命周期构架里程碑（精化阶段）
      初始操作性能里程碑（构建阶段）
      产品发布里程碑（产品化阶段）

   区别对待缺陷和新增功能

通过进一步了解我们发现紧急的变更一般是指影响系统正常使用的软件缺陷，这些缺陷需要及时的修 复；而新增功能请求一般不是那么紧急的，允许开发团队有一段时间来开发实现。但开发人员目前是把所有紧急和非紧急的变更请求混杂在一起实现的，往往是一个 紧急的缺陷已经修复，但另外一个正在开发中的新增功能也修改了同一组文件版本，造成两者之间的版本依赖，从而导致紧急的缺陷修复不能按时提交。

我们建议把缺陷的修复工作和新增功能的开发工作区分开来，这就涉及到多个版本的并行开发，开发团队主要面临以下三个版本的开发：

Ø        v1.0中的缺陷修复

Ø        v1.0的新增功能版本v1.1

Ø        下一个版本v2.0

***********************************************************************************

发布版本构建(build)而不是源代码

这样缺陷修复和新增功能开发相互独立，保证紧急的缺陷修复不会受到新增功能的影响。

   版本发布管理

对于所发布的构建版本，我们也需要进行有序的管理，可以用版本号来唯一标识每一个发布版本。一 般可以把用于开发团队内部系统测试的称之为内部发布版本，把提交给客户的称之为外部发布版本，这两种软件发布版本都要统一编号管理。在我们的例子中，内部 发布版本可以简单地用构建号来表示，如：

v1.0_build_008      表示版本v1.0开发过程中生成的第8次构建外部发布版本可以由版本号和发布号组合而成，如：

v1.0_rel01          表示版本v1.0的第一个外部发布版本

对于v1.0中的缺陷修复，我们可以通过补丁的方式来发布，一个补丁中可以包含有多个缺陷修复，被修复的缺陷需要在补丁的发布说明(Release Notes)中写明，补丁名称可以由版本号、发布号和补丁号组合而成，如：

v1.0_rel01_p001     表示针对发布版本v1.0_rel01的第001号补丁

对于v1.0中新增功能，我们需要制定一个发布计划，根据客户新增功能请求的紧急程度来分期分批实现，一次发布中可以包含多个新增功能，并且包括所有已改正的软件缺陷，这些改动都必须在发布说明中写明，发布版本号可以在前一个发布版本的基础上递增，如：

v1.1_rel02          表示版本v1.1的第二个外部发布版本

对于下一个版本v2.0的开发，则与版本v1.0开发的发布管理完全一致，如：

v2.0_build_002      表示版本v2.0开发过程中生成的第2次构建

在版本发布管理的流程中，发布版本的安装应该由专门的角色负责，可以是配置管理员或者是集成员(integrator)；开发人员被禁止向各平台（测试平台、准生产环境、生产系统）上安装任何软件，并且各平台上所安装软件的版本号.0.0 Notes 11都应该有详细的记录。当软件缺陷被发现时，我们就可以明确知道问题究竟是出在哪一个版本。

内部发布版本只会被安装到测试平台上，经过 “开发 à 构建 à 测试 à 发现缺陷à 修改代码” 的多次循环之后，内部发布版本的质量趋于稳定，开发团队才会决定做一个外部发布版本。

外部发布版本被安装到准生产环境上，并且只有通过用户验收测试，它才可以被安装到生产系统上 去。如果该版本没有通过用户验收测试，那么开发团队需要提供相应的补丁来解决用户验收中发现的问题，直到通过用户验收后再将该发布版本及其所有的累积补丁 全部安装到生产系统上去。有些情况下，最终通过验收测试的也可能是下一个发布版本，所以生产系统上安装的发布版本前后之间不一定是连续的，中间可能跳过一 些质量不够成熟的版本。

同样的，只有通过用户验收测试的补丁才会被最终安装到生产系统上去。紧急的补丁经过用户验收测试之后会马上安装到生产系统上，不紧急的补丁可以累积几个以后批量安装上去。

主题

• 定义
• 解释
• 使用

定义

基线是项目储存库中每个工件版本在特定时期的一个“快照”。它提供一个正式标准，随后的工作基于此标准，并且只有经过授权后才能变更这个标准。建立一个初始基线后，以后每次对其进行的变更都将记录为一个差值，直到建成下一个基线。 

参与项目的开发人员将基线所代表的各版本的目录和文件填入他们的工作区。随着工作的进展，基线将合并自从上次建立基线以来开发人员已经交付的工作。变更一旦并入基线，开发人员就采用新的基线，以与项目中的变更保持同步。调整基线将把集成工作区中的文件并入开发工作区。

解释

建立基线的三大原因是：重现性、可追踪性和报告。

重现性是指及时返回并重新生成软件系统给定发布版的能力，或者是在项目中的早些时候重新生成开发环境的能力。可追踪性建立项目工件之间的前后继承关 系。其目的在于确保设计满足要求、代码实施设计以及用正确代码编译可执行文件。报告来源于一个基线内容同另一个基线内容的比较。基线比较有助于调试并生成 发布说明。

建立基线后，需要标注所有组成构件和基线，以便能够对其进行识别和重新建立。

建立基线有以下几个优点：

• 基线为开发工件提供了一个定点和快照。
• 新项目可以从基线提供的定点之中建立。作为一个单独分支，新项目将与随后对原始项目（在主要分支上）所进行的变更进行隔离。
• 各开发人员可以将建有基线的构件作为他在隔离的私有工作区中进行更新的基础。
• 当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。
• 您可以利用基线重新建立基于某个特定发布版本的配置，这样也可以重现已报告的错误。

使用

定期建立基线以确保各开发人员的工作保持同步。但是，在项目过程中，应该在每次迭代结束点（次要里程碑），以及与生命周期各阶段结束点相关联的主要里程碑处定期建立基线：

• 生命周期目标里程碑（先启阶段）
• 生命周期构架里程碑（精化阶段）
• 初始操作性能里程碑（构建阶段）
• 产品发布里程碑（产品化阶段）

引言

Thomas Carlyle说：“人类是使用工具的动物。没有工具，人什么都不是；有了工具，人无所不能。”金融家们创造了复杂的金融工具，并利用这些工具制造了财富 神话，制造了著名的跨国公司，也制造了世界范围的危机。软件精英们为了让自己的工作效率更高，有更多时间去做想做的事，也创造了各式各样的工具。持续集成 已经不是一个新概念，在这个概念发展的十多年间，出现了支持这一概念的众多工具。这些工具的组合使用，为软件开发提供了强大的支持。

持续集成工具的分类和功能

一般来说，持续集成工具可以分成两大类：自动化构建工具和构建计划安排工具。

自动化构建工具有这样一些基本功能：代码编译、组件打包、程序执行和文件操作。编译源代码是构建的主要工作之一，为了提高效率，编译应该根据相应的 源代码是否发生改变而有条件地执行。组件打包是将编译的结果和其他需要包含的文件组织在一起，形成可以部署的组件。构建工具应该知道何时需要重新打包。程 序执行是指构建工具能够在它支持的平台上，调用所有提供命令行接口的程序。构建工具应该支持创建、拷贝、删除文件和目录等操作。

某些自动化构建工具还有一些扩展功能：执行开发者测试、版本控制工具集成、文档集成、部署功能、代码品质分析、支持扩展、多平台构建、加速构建。虽 然构建工具可以通过命令行执行的方式来集成构建工具和测试工具，但如果它提供更直接的集成方式，开发者就更省力。同样，如果构建工具能够直接与版本控制工 具集成，开发者也会觉得更方便。文档集成是指构建工具能够自动从源代码中抽取并生成API文档。构建工具还可以将打包好的组件自动部署到目标测试环境中 去。构建工具一般通过一些第三方插件，支持对代码品质进行分析。而提供插件接口，是构建工具实现可扩展性的通用方式。如果您开发的软件需要在多个平台上构 建并测试，那么构建工具对多平台的支持就会带来极大的方便。对于较大的代码集，一次构建可能需要好几个小时，这为持续集成带来了一些挑战。有的构建工具支 持加速构建，即在多个构建服务器的多个处理器上进行分布式构建。

常见的自动化构建工具包括Ant、NAnt、MSBuild、make、Maven、Rake等。

构建计划安排工具有这样一些基本功能：构建执行、版本控制集成、构建工具集成、提供反馈、为构建打上标签。构建计划安排工具的核心功能就是在特定时 间执行自动化的构建，这可以通过轮询版本控制库、计划驱动或事件通知等方式来实现。大部分构建计划安排工具都支持大多数流行的版本控制系统，也支持大多数 流行的构建工具。构建计划安排工具至少支持通过电子邮件提供反馈信息，有一些工具可以通过即时消息、手机短信或其他设备来提供反馈。大多数构建计划安排工 具会提供某种类型的升序计数，作为构建版本的标签。

某些构建计划安排工具还有一些扩展功能：支持项目间依赖关系、提供用户界面、制品发布、安全。如果项目间存在依赖关系，您可能希望在被依赖的项目重 新构建时，重新构建依赖于它的项目。设计良好的用户界面会在工作时为您节约时间。制品发布是指除了得到可部署的组件之外，一些成熟的某些构建计划安排工具 可以将文档、测试结果、品质分析结构和其他测量指标数据格式化，便于查看。有一些工具提供了身份认证和授权等安全方面的功能，允许您指定谁能查看结果和修 改配置。

常见的构建计划安排工具包括AnthillPro、Continuum、CruiseControl、CruiseControl.NET、Draco.NET、Luntbuild、Hudson等。

下面介绍两个颇具代表性的工具：Ant和Hudson。

Ant

Ant是Java构建工具的事实标准，一般建议，不论项目团队成员使用哪种集成开发环境，项目都要有一个可以脱离IDE执行的Ant脚本。Ant采用插件式的设计结构，通过不同的插件来实现各种任务，其任务分类如表1所示。

Archive Tasks
 打包解包任务，支持的格式包括：BZip2、Cab、Ear、GZip、Jar、Rpm、Tar、War、Zip。
 
Audit/Coverage Tasks
 JDepend任务，调用JDepend实现代码静态分析，针对每个Java包生成设计品质指标数据。
 
Compile Tasks
 编译任务，实现对Java、JSP、NetRexx等源文件的编译。
 
Deployment Tasks
 部署任务，实现在JavaEE服务器上热部署。
 
Documentation Tasks
 文档生成任务，生成javadoc文档、Apache Stylebook文档。
 
EJB Tasks
 EJB任务，提供对1.x和2.x的EJB的支持，并支持不同供应商的应用服务器。
 
Execution Tasks
 执行任务，包括对子项目调用Ant、调用同一脚本中的另一个target、执行系统提供的命令行程序、执行Java程序、暂停和并行同步执行等功能。
 
File Tasks
 文件任务，实现对文件和目录的操作。
 
Java2 Extensions Tasks
 Java2 扩展信息任务，对jar包中的版本、供应商等扩展信息进行检查和操作。
 
Logging Tasks
 日志任务，将构建过程事件记录到文件中。
 
Mail Tasks
 邮件任务，发送SMTP邮件。
 
Miscellaneous Tasks
 其他任务，各种或许会用到的小任务，例如播放wav文件。
 
.NET Tasks
 .NET任务，支持执行.NET程序、执行NUnit测试、调用NAnt、调用MSBuild、调用WiX工具。
 
Pre-process Tasks
 预处理任务，实现编译之前的一些预处理。例如调用ANTLR、JavaCC、Native2Ascii等程序。
 
Property Tasks
 属性任务，对脚本中的属性变量进行判断和操作。
 
Remote Tasks
 远程任务，支持FTP、Rexec、Scp、SSH和Telnet。
 
SCM Tasks
 SCM任务，支持各种配置管理（版本控制）软件，包括CVS、ClearCase、Continuus、Visual SourceSafe、Perforce、PVCS、SourceOffSite和StarTeam。
 
Testing Tasks
 测试任务，支持执行JUnit测试。
 
表1. Ant任务分类

以上介绍的只是Ant发行版所带的一些任务。由于Ant采用的是插件结构，所以开发者可以开发自己需要的Ant任务，支持各种工具，如FindBugs、TestNG等其他代码检查工具和测试工具。早期的Ant没有很好的依赖关系支持，后来则通过Ivy弥补了这一缺点。

关键是Ant为我们提供了一个跨平台的Java构建工具，为持续集成提供了根本的支持。对于Java开发者来说，如果不想采用Ant，也可以考虑采用Maven。

Hudson

Hudson是一个开放源代码的CI服务器，受到世界各地各种规模和类型的开发团队的欢迎。关键是因为它非常易于安装和使用，提供了灵活的配置方式和复杂的功能，同时支持Java项目和非Java项目，由强大的Hudson社区提供技术支持。

简而言之，Hudson不仅仅是一个CI服务器，它的可扩展架构使它不仅是一个构建管理系统，也成为一个通用的开发生命周期管理系统，让开发者能够完成提升基线、打标签、执行工作流、根据依赖关系追踪变更、监视并图示测试结果、查看代码覆盖率和违反编码标准的情况等任务。

Hudson是最活跃，成长最快的开源社区之一，目前每周下载达4000次，有超过2万个在工作的安装实例。它的开发者超过160人，贡献的工作量超过137人年，目前已发布了超过300个发行版本。Hudson实际上是现在世界上最受欢迎的开源CI服务器。

图1是Apache软件基金会运行Hudson的屏幕截图，您可以在http://wiki.hudson-ci.org/display/HUDSON/Meet+Hudson 看到更多Hudson的使用案例。

图1. Apache运行的Hudson

Huddon的主要优点包括：

易于安装。只要执行“java –jar hudson.war”，或者将hudson.war部署到应用服务器上就可以了，不需要其他的安装工作，也不需要建立数据库。
易于配置。所有东西都通过Web GUI界面来配置，不需要手工修改XML文件。
支持分布式构建。Hudson支持将构建和测试负载分布到多台机器上，图2是Apache采用Hudson的分布式构建功能。
支持环境配置矩阵。Hudson支持在不同的环境配置下执行相同的任务，例如不同的JDK版本、不同的操作系统、不同的数据库。执行的结果可以汇总在一起。
支持JUnit/TestNG测试报告。测试的结果可以分标签列出、汇总，并与历史信息一同显示。历史趋势可以显示在图中。
追踪依赖关系。Hudson追踪记录哪次构建生成了哪些jar，某次构建使用了哪些版本的jar，即使这些jar包来自于外部也可以。

图2. Hudson支持的分布式构建

Hudson通过大量的插件来实现其丰富的功能，这些插件大致可以分为以下几类：

SCM。Hudson缺省支持CVS和Subversion，通过安装插件支持Accurev、Bitkeeper、ClearCase、Git、Mercurial、Perforce、StarTeam、Synergy等
构建触发器。可以通过IRC、Ivy、Jabber、Join、Locks and Latches、Navigator来触发执行构建。
构 建工具。缺省支持Ant、Maven、shell s和Windows 批处理命令，通过安装插件支持batch tasks、Gant、Gradle、Grails、Groovy、Jython、Kundo、MSBuild、Phing、Powershell、 Python、Rake、Ruby、SCons、SCTMExecutor,Selenium等。
构建包装。对构建的方式进行一些控制，如并发 同步、启停虚拟机等。包括Hudson Centralized Job Action、Hudson Distributed Workspace Clean、Locks and Latches、M2 Extra Steps、M2 Release、Release、VMware、Xvnc、Zen Timestamp等。
构建通知。缺省支持电子邮件通知，通过插件支持 Campfire、Google Calendar、HudsonTracker (RSS feeds)、IRC、Jabber、Nabaztag、SameTime、Status Monitor、The new Emailer、TuxDroid、Twitter等。
Slave启动和控制。缺省支持JNLP和命令行，通过插件支持SSH。
构建 报告。缺省支持JUnit、javadoc和FindBugs，通过插件支持CCCC、Checkstyle、Clover、DRY、Emma、 Gallio、Gnat、Grinder、Japaex、JavaNCS、JavaTest Report、MSTest、N Cover、NUint、Plot、PMD、PureCoverage、Ruby metrics、Selenium AES、Selenium hq、Serenitec、SLOCCount、Task Scanner、Testability Explorer、Violations、Warnings、WebTest Presenter等。图3是Sonar生成的项目报告的样例。
集群管理/分布式构建。支持DistFork、Hadoop、PXE、Selenium、Swarm等。
制品上传。支持FTP-Publisher、java.net uploader、SCP,SFEE、SVN等。
身份认证和用户管理。支持操作审计追踪、LDAP、MySQL认证等。

图3. Sonar Dashboard

结束语

工欲善其事，必先利其器。人是工具的主宰。A fool with a tool is still a fool（傻子拿着工具还是傻子）。人们总是在学习工具、使用工具、创造更好的工具，以期提高工作的效率和品质。人要有智慧，工具要先进。

【================= windows OS系统下的： Hudson环境搭建过程记录===========】

1. 安装jakarta-tomcat-5.0.30.exe, 使用的jdk（C:\Program Files\Java\jdk1.6.0_14）。

设置HUDSON_HOME环境变量，按住windows键+Pause键快速出现环境变量设置界面。

HUDSON_HOME=C:\hudson_ci\hudson

TOMCAT_HOME=C:\hudson_ci\Tomcat 5.0

       JAVA_HOME=C:\Program Files\Java\jdk1.6.0_14

       CALSSPATH=C:\ProgramFiles\Java\jdk1.6.0_14\lib\dt.jar;C:\ProgramFiles\Java\jdk1.6.0_14\lib\tools.jar

2. hudson-2.0.0.war copy到C:\hudson_ci\Tomcat 5.0\webapps目录。

3. 访问http://localhost:8080/hudson-2.0.0/出现hudson web页面。

【=================PC环境=================】

1.       OS:fedora 8

2.       【备注信息】

1）jobs里面：只有job的各项设置参数值，数据没有保存下来比如MD5值等。

2）

2.1.） 之前试过2次jdk和tomcat6都安装好的情况，每次浏览hudson就出现内存泄露的情况，是因为hudson-2.0.1.war和hudson-2.0.0.war虽然在windows环境访问OK，但是在fedora中不兼容，于是从hudson官网下了个hudson.war，部署到webapps最终搞定。

2.2.）

yum list | grep tomcat    //列出tomcat可安装包

yum -y install tomcat5   //安装tomcat5

yum remove tomcat5     //卸载tomcat5

yum remove java          //卸载所有JAVA

rpm –qa | grep jdk         //查找jdk

查看方法:rpm –qa |grep –I java

卸载方法:rpm –e –nodeps java*包名

将jdk-6u21-linux-i586-rpm.bin给予可执行权限

修改权限：chmod u+x jdk-6u21-linux-i586-rpm.bin

3.       【SVN版本信息】

【服务器端SVN】：

查看SVN版本方法：

【客户端SVN】

TortoiseSVN 1.5.5, Build 14361 - 32 Bit , 2008/10/24 18:06:34

Subversion 1.5.4,

4.        【几个重要的目录】

1）# cd /etc/init.d/ 目录下面在hudson使用之后，会产生hudson目录，用于存放Hudson的一些数据信息，包括Hudson_home变量，所以当hudson想要重新配置的时候，一定要删除这里的Hudson目录。

2）/etc/sysconfig/Hudson 与上面类似，可以使用命令启动Hudson，目前最好不用。/etc/init.d/hudson start

。

3）查看hudson的环境变量值是否设置好 ：

使用

[root@localhost etc]# echo $HUDSON_HOME

/home/kiki/compile/hudson_ci/Hudson

如果环境变量值OK,说明是上面所述的2个目录需要清理干净才可以。

5.       【当前HUDSON的一些数据信息】

安全机制的用户：

匿名只有R权限

admin/kiki/xufuli@twsh.com

tester/tester/xufuli@twsh.com

【=================fedora 8下面hudson搭建过程=================】

[备注]hudson相应的设置都在系统设置时所规定的Hudson_home目录下面，

与/usr/apache-tomcat-6.0.32/webapps下面的hudson不相干，所以保存Hudson_home目录下面的数据，就可以对hudson进行迁移。

JDK6

1.       JDK使用软件：jdk-6u21-linux-i586-rpm.bin,下载路径

http://zh.sourceforge.jp/projects/sfnet_crawlzilla/downloads/other/jdk-6u21-linux-i586-rpm.bin/

2.       JDK安装路径 ： /usr/java/jdk1.6.0_21

3.       执行安装命令：./ jdk-6u21-linux-i586-rpm.bin

APACHE

1.       apache使用软件：apache-tomcat-6.0.32.tar.gz

2.       apache 安装路径：/usr/apache-tomcat-6.0.32

3.       apache安装方法：tar xzvf apache-tomcat-6.0.32.tar.gz

HUDSON软件

1.       hudson使用Hudson.war

2.       直接copy Hudson.war 到/usr/apache-tomcat-6.0.32/webapps目录下面

3.       【hudson相应环境变量设置】

 修改文件/etc/profile,在文件末尾添加如下，执行source /etc/profile生效：

4. apache 目录中tomcat-users.xml配置apache的访问用户。

       修改文件/usr/apache-tomcat-6.0.32/conf如下：

4.       进入apache目录/usr/apache-tomcat-6.0.32/bin,启动apache服务。

5.       登录http://172.28.6.36:8080/hudson看到hudson首页即成为搭建hudson.

【=================hudson配置过程=================】

1.       安全机制配置：

Hudson>系统管理>系统设置 配置如下,然后点击页面右上角的【登录】，跳转到登录页面，单击【Create an account】创建一个hudson访问用户：

2.       单个SVN路径项目的配置如下；

3.       多个相同库或不同库的SVN源码的项目配置方式：

4. 在hudson首页有个： Check File Fingerprint

可以通过这个功能检查构件是否由hudson所构建产生。

4.       进入任务的某次构建页面：有Tag this build

可以通过此将此次构建的路径及SVN版本号在SVN库中打上基线。

5.       进入任务页面，

状态会显示上次成功构建所产生的构件list,

变更集：显示每次构建源码库所产生的变化，如果是每次提交代码触发一次构建，那么这里显示的就是每次的提交变更记录。

【================遇到的问题======================】

1. hudson无法指定SVN版本的实现（下载最新的SVN插件即OK，服务器端SVN与客户端SVN版本不一致导致，请求IT开通下载权限再试）

插件这里升级为：

*********尝试步骤：

新建任务：test812

可以了。

目录

用持续集成构建特性

持续集成实践

　　只维护一个源码仓库

　　自动化 build

　　让你的build自行测试

　　每人每天都要向mainline提交代码

　　每次提交都应在集成计算机上重新构建 mainline

　　保持快速 build

　　在模拟生产环境中进行测试

　　让每个人都能轻易获得最新的可执行文件

　　每个人都能看到进度

　　自动化部署

持续集成的益处

引入持续集成

最后的思考

延伸阅读

　　相关文章

　　持续集成（第一版）

　　进化式数据库设计

我还可以生动记起第一次看到大型软件工程的情景。我当时在一家大型英国电子公司的QA部 门实习。我的经理带我熟悉公司环境，我们进到一间巨大的，充满了压抑感和格子间的的仓库。我被告知这个项目已经开发了好几年，现在正在集成阶段，并已经集 成了好几个月。我的向导还告诉我没人知道集成要多久才能结束。从此我学到了软件开发的一个惯例：集成是一个很耗时并难以预测的过程。但是事实并非总是如 此，我的 ThoughWorks 同事所做的项目，以及很多其它遍布世界各地的软件项目，都不会把集成当回事。任何一个开发者本地的代码和项目共享基准代码的差别仅仅只有几小时的工作而 已，而且这只要几分钟的时间就可以被集成回去。任何集成错误都可以很快被发现，并被快速修复。这鲜明的差别并非源于昂贵和复杂的工具。其中的精华蕴含于一 个简单的实践：使用统一的代码仓库并频繁集成（通常每天一次）。

当我向别人介绍持续集成方法 时，人们通常会有两种反应：“这（在我们这儿）不管用”和“做了也不可能有什么不同”。但如果他们真的试过了，就会发现持续集成其实比听起来要简单，并且 能给开发过程带来巨大的改变。因此第三种常见的反应是：“我们就是这么做的，做开发怎可能不用它呢？”

“持续集成”一词来源于极限编程（Extreme Programming），作为它的12个实践之一出现。当我开始在 ThoughWorks 开始顾问职业生涯时，我鼓励我所参与的项目使用这种技巧。Matthew Foemmel 将我抽象的指导思想转化为具体的行动。我们看到了项目从少而繁杂的集成进步到我所描述的不当回事。Metthew和我将我们的经验写进了这篇论文的第一版里。这篇论文后来成了我网站里最受欢迎的文章之一。

相关文章：持续集成（第一版）

这是我的个人网站上关于持续集成最早的文章。尽管我觉得新的更好，但大多数链接还是指向原先的这篇文章。文中我描述了 Matt 于2000年早期在 ThoughtWorks 项目中帮助实施持续集成的经验。

尽管持续集成不需要什么特别的工具，我们发现使用一个持续集成服务器软件还是很有效果的。最出名的持续集成服务器软件是 CruiseControl，这是一个开源工具，最早由 ThoughWorks 的几个人开发，现在由社区维护。之后还有许多其他持续集成服务器软件出现，有些是开源的，有些则是商业软件，比如 ThoughtWorks Studio 的 Cruise。

用持续集成构建特性

对我来说，解释持续集成最简单的方法就是用一个简单的例子来示范开发一个小 feature。现在假设我要完成一个软件的一部分功能，具体任务是什么并不重要，我们先假设这个 feature 很小，只用几个小时就可以完成。（我们稍后会研究更大的任务的情况。）

一开始，我将已集成的源代码复制一份到本地计算机。这可以通过从源码管理系统的 mainline 上 check out 一份源代码做到。

如果你用过任何源代码管理系统，理解上面的文字应该不成问题。但如果你没用过，可能会有读天书的感觉。所以我们先快速解释一个这些概念。源代码管理系统将项目的所有源代码都保存在一个“仓库（repository）”中。系统的当前状态通常被称为“mainline”。开发者随时都可以把mainline复制一份到他们自己的计算机，这个过程被称为“check out”。开发者计算机上的拷贝被称为“工作拷贝（working copy）”。（绝大部分情况下，你最终都会把工作拷贝的内容提交到mainline上去，所以两者实际上应该差不多。）

现在我拿到了工作拷贝，接下来需要做一些事情来完成任务。这包括修改产品代码和添加修改自动化测试。在持续集成中，软件应该包含完善的可自动运行的测试，我称之为自测试代码。这一般需要用到某一个流行的 XUnit 测试框架。

一旦完成了修改，我就会在自己的计算机上启动一个自动化 build。这会将我的工作拷贝中的源代码编译并链接成为一个可执行文件，并在之上运行自动化测试。只有当所有的 build 和测试都完成并没有任何错误时，这个 build 过程才可以认为是成功的。

当我 build 成功后，我就可以考虑将改动提交到源码仓库。但麻烦的情况在于别人可能已经在我之前修改过 mainline。这时我需要首先把别人的修改更新到我的工作拷贝中，再重新做 build。如果别人的代码和我的有冲突，就会在编译或测试的过程中引起错误。我有责任改正这些问题，并重复这一过程，直到我的工作拷贝能通过 build 并和 mainline 的代码同步。

一旦我本地的代码能通过 build，并和 mainline 同步，我就可以把我的修改提交到源码仓库。

然而，提交完代码不表示就完事大吉了。我们还要做一遍集成 build，这次在集成计算机上并要基于 mainline 的代码。只有这次 build 成功了，我的修改才算告一段落。因为总有可能我忘了什么东西在自己的机器上而没有更新到源码仓库。只有我提交的改动被成功的集成了，我的工作才能结束。这可以由我手工运行，也可以由 Cruise 自动运行。

如果两个开发者的修改存在冲突，这通常会被第二个人提交代码前本地做 build 时发现。即使这时侥幸过关，接下来的集成 build 也会失败掉。不管怎样，错误都会被很快检测出来。此时首要的任务就是改正错误并让 build 恢复正常。在持续集成环境里，你必须尽可能快地修复每一个集成 build。好的团队应该每天都有多个成功的 build。错误的 build 可以出现，但必须尽快得到修复。

这样做的结果是你总能得到一个稳定的软件，它可能有一些 bug，但可以正常工作。每个人都基于相同的稳定代码进行开发，而且不会离得太远，否则就会不得不花很长时间集成回去。Bug被发现得越快，花在改正上的时间就越短。

持续集成实践

从上面的故事我们大概了解了持续集成是如何在我们的日常工作中发挥作用的。但让一切正常运行起来还需要掌握更多的知识。我接下来会集中讲解一下高效持续集成的关键实践。

只维护一个源码仓库

在软件项目里需要很多文件协调一致才能 build 出产品。跟踪所有这些文件是一项困难的工作，尤其是当有很多人一起工作时。所以，一点也不奇怪，软件开发者们这些年一直在研发这方面的工具。这些工具称为 源代码管理工具，或配置管理，或版本管理系统，或源码仓库，或各种其它名字。大部分开发项目中它们是不可分割的一部分。但可惜的是，并非所有项目都是如 此。虽然很罕见，但我确实参加过一些项目，它们直接把代码存到本地驱动器和共享目录中，乱得一塌糊涂。

所以，作为一个最基本的要求，你必须有一个起码的源代码管理系统。成本不会是问题，因为有很多优秀的开源工具可用。当前较好的开源工具是 Subversion。（更老的同样开源的 CVS 仍被广泛使用，即使是 CVS 也比什么都不用强得多，但 Subversion 更先进也更强大。）有趣的是，我从与开发者们的交谈中了解到，很多商业源代码管理工具其实不比 Subversion 更好。只有一个商业软件是大家一致同意值得花钱的，这就是 Perforce。

一旦你有了源代码管理系统，你要确保所有人都知道到哪里去取代码。不应出现这样的问题：“我应该到哪里去找xxx文件？” 所有东西都应该存在源码仓库里。

即便对于用了源码仓库的团队，我还是观察到一个很普遍的错误，就是他们没有把所有东西都放在源码仓库里。一般人们都会把代码放进去，但还有许多其它文件，包括测试脚本，配置文件，数据库Schema，安装脚本，还有第三方的库，所有这些build时需要的文件都应该放在源码仓库里。我知道一些项目甚至把编译器也放到源码仓库里（用来对付早年间那些莫名其妙的C++编译器很有效）。一个基本原则是：你必须能够在一台干净的计算机上重做所有过程，包括checkout和完全build。只有极少量的软件需要被预装在这台干净机器上，通常是那些又大又稳定，安装起来很复杂的软件，比如操作系统，Java开发环境，或数据库系统。

你必须把build需要的所有文件都放进源代码管理系统，此外还要把人们工作需要的其他东西也放进去。IDE配置文件就很适合放进去，因为大家共享同样的IDE配置可以让工作更简单。

版本控制系统的主要功能之一就是创建 branch 以管理开发流。这是个很有用的功能，甚至可以说是一个基础特性，但它却经常被滥用。你最好还是尽量少用 branch。一般有一个mainline就够了，这是一条能反映项目当前开发状况的 branch。大部分情况下，大家都应该从mainline出发开始自己的工作。（合理的创建 branch 的理由主要包括给已发布的产品做维护和临时性的实验。）

一般来说，你要把build依赖的所有文件放进代码管理系统中，但不要放build的结果。有些人习惯把最终产品也都放进代码管理系统中，我认为这是一种坏味道——这意味着可能有一些深层次的问题，很可能是无法可靠地重新build一个产品。

自动化build

通常来说，由源代码转变成一个可运行的系统是一个复杂的过程，牵扯到编译，移动文件，将 schema 装载到数据库，诸如此类。但是，同软件开发中的其它类似任务一样，这也可以被自动化，也必须被自动化。要人工来键入各种奇怪的命令和点击各种对话框纯粹是浪费时间，也容易滋生错误。

在大部分开发平台上都能找到自动化 build 环境的影子。比如 make，这在 Unix 社区已经用了几十年了，Java 社区也开发出了 Ant，.NET 社区以前用 Nant，现在用 MSBuild。不管你在什么平台上，都要确保只用一条命令就可以运行这些脚本，从而 build 并运行系统。

一个常见的错误是没有把所有事都放进自动化 build。比如：Build 也应该包括从源码仓库中取出数据库 schema 并在执行环境中设置的过程。我要重申一下前面说过的原则：任何人都应该能从一个干净的计算机上 check out 源代码，然后敲入一条命令，就可以得到能在这台机器上运行的系统。

Build 脚本有很多不同的选择，依它们所属的平台和社区而定，但也没有什么定势。尽管大部分的 Java 项目都用 Ant，还是有一些项目用 Ruby（Ruby Rake 是一个不错的 build 脚本工具）。我们也曾经用 Ant 自动化早期的 Microsoft COM 项目，事实证明很有价值。

一个大型 build 通常会很耗时，如果只做了很小的修改，你不会想花时间去重复所有的步骤。所以一个好的 build 工具应该会分析哪些步骤可以跳过。一个通用的办法是比较源文件和目标文件的修改时间，并只编译那些较新的源文件。处理依赖关系要麻烦一些：如果一个目标文件修改了，所有依赖它的部分都要重新生成。编译器可能会帮你处理这些事情，也可能不会。

根据你的需要，你可能会想 build 出各种不同的东西。你可以同时 build 系统代码和测试代码，也可以只 build 系统代码。一些组件可以被单独 build。Build 脚本应该允许你在不同的情况中 build 不同的 target。

我们许多人都用 IDE，许多 IDE 都内置包含某种 build 管理功能。然而，相应的配置文件往往是这些 IDE 的专有格式，而且往往不够健壮，它们离了 IDE 就无法工作。如果只是 IDE 用户自己一个人开发的话，这还能够接受。但在团队里，一个工作于服务器上的主 build 环境和从其它脚本里运行的能力更重要。我们认为，在 Java 项目里，开发者可以用自己的 IDE 做 build，但主 build 必须用 Ant 来做，以保证它可以在开发服务器上运行。

让你的build自行测试

传统意义上的 build 指编译，链接，和一些其它能让程序运行起来的步骤。程序可以运行并不意味着它也工作正常。现代静态语言可以在编译时检测出许多 bug，但还是有更多的漏网之鱼。

一种又快又省的查 bug 的方法是在 build 过程中包含自动测试。当然，测试并非完美解决方案，但它确实能抓住很多 bug——多到可以让软件真正可用。极限编程（XP）和测试驱动开发（TDD）的出现很好地普及了自测试代码的概念，现在已经有很多人意识到了这种技巧的价值。

经常读我的著作的读者都知道我是 TDD 和 XP 的坚定追随者。但是我想要强调你不需要这两者中任何一个就能享受自测试代码的好处。两者都要求你先写测试，再写代码以通过测试，在这种工作模式里测试更多着重于探索设计而不是发现 bug。这绝对是一个好方法，但对于持续集成而言它并不必要，因为这里对自测试代码的要求没有那么高。（尽管我肯定会选择用 TDD 的方式。）

自测试代码需要包含一套自动化测试用例，这些测试用例可以检查大部分代码并找出 bug。测试要能够从一条简单的命令启动。测试结果必须能指出哪些测试失败了。对于包含测试的 build，测试失败必须导致 build 也失败。

在过去的几年里，TDD 的崛起普及了开源的 XUnit 系列工具，这些工具用作以上用途非常理想。对于我们在 ThoughWorks 工作的人来说，XUnit 工具已经证明了它们的价值。我总是建议人们使用它们。这些最早由 Kent Beck 发明的工具使得设置一个完全自测试环境的工作变得非常简单。

毋庸置疑，对于自动测试的工作而言，XUnit 工具只是一个起点。你还必须自己寻找其他更适合端对端测试的工具。现在有很多此类工具，包括FIT，Selenium，Sahi，Watir，FITnesse，和许多其它我无法列在这里的工具。

当然你不能指望测试发现所有问题。就像人们经常说的：测试通过不能证明没有 bug。然而，完美并非是你要通过自测试 build 达到的唯一目标。经常运行不完美的测试要远远好过梦想着完美的测试，但实际什么也不做。

每人每天都要向 mainline 提交代码

集成的主要工作其实是沟通。集成可以让开发者告诉其他人他们都改了什么东西。频繁的沟通可以让人们更快地了解变化。

让开发者提交到 mainline 的一个先决条件是他们必须能够正确地 build 他们的代码。这当然也包括通过 build 包含的测试。在每个提交迭代里，开发者首先更新他们的工作拷贝以与 mainline 一致，解决任何可能的冲突，然后在自己的机器上做 build。在 build 通过后，他们就可以随便向 mainline 提交了。

通 过频繁重复上述过程，开发者可以发现两个人之间的代码冲突。解决问题的关键是尽早发现问题。如果开发者每过几个小时就会提交一次，那冲突也会在出现的几个 小时之内被发现，从这一点来说，因为还没有做太多事，解决起来也容易。如果让冲突待上几个星期，它就会变得非常难解决。

因为你在更新工作拷贝时也会做 build，这意味着你除了解决源代码冲突外也会检查编译冲突。因为 build 是自测试的，你也可以查出代码运行时的冲突。后者如果在一段较长的时间还没被查出的话会变得尤其麻烦。因为两次提交之间只有几个小时的修改，产生这些问题只可能在很有限的几个地方。此外，因为没改太多东西，你还可以用 diff-debugging 的技巧来找 bug。

总的来说，我的原则是每个开发者每天都必须提交代码。实践中，如果开发者提交的更为频繁效果也会更好。你提交的越多，你需要查找冲突错误的地方就越少，改起来也越快。

频繁提交客观上会鼓励开发者将工作分解成以小时计的小块。这可以帮助跟踪进度和让大家感受到进展。经常会有人一开始根本无法找到可以在几小时内完成的像样的工作，但我们发现辅导和练习可以帮助他们学习其中的技巧。

每次提交都应在集成计算机上重新构建 mainline

使用每日提交的策略后，团队就能得到很多经过测试的 build。这应该意味着 mainline 应该总是处于一种健康的状态。但在实践中，事情并非总是如此。一个原因跟纪律有关，人们没有严格遵守在提交之前在本地更新并做 build 的要求。另一个原因是开发者的计算机之间环境配置的不同。

结论是你必须保证日常的 build 发生在专用的集成计算机上，只有集成 build 成功了，提交的过程才算结束。本着“谁提交，谁负责”的原则，开发者必须监视 mainline 上的 build 以便失败时及时修复。一个推论是如果你在下班前提交了代码，那你在 mainline build 成功之前就不能回家。

我知道主要有两种方法可以使用：手动 build，或持续集成服务器软件。

手动 build 描述起来比较简单。基本上它跟提交代码之前在本地所做的那次 build 差不多。开发者登录到集成计算机，check out 出 mainline 上最新的源码（已包含最新的提交），并启动一个集成 build。他要留意 build 的进程，只有 build 成功了他的提交才算成功。（请查看 Jim Shore 的描述。）

持续集成服务器软件就像一个监视着源码仓库的监视器。每次源码仓库中有新的提交，服务器就会自动 check out 出源代码并启动一次 build，并且把 build 的结果通知提交者。这种情况下，提交者的工作直到收到通知（通常是 email）才算结束。

在 ThoughtWorks，我们都是持续集成服务器软件的坚定支持者，实际上我们引领了 CruiseControl 和 CruiseControl.NET 最早期的开发，两者都是被广泛使用的开源软件。此后，我们还做了商业版的 Cruise 持续集成服务器。我们几乎在每一个项目里都会用持续集成服务器，并且对结果非常满意。

不是每个人都会用持续集成服务器。Jim Shore 就清楚地表达了为什么他更偏好手动的办法。我同意他的看法中的持续集成并不仅仅是安装几个软件而已，所有的实践都必须为了能让持续集成更有效率。但同样的，许多持续集成执行得很好的团队也会发现持续集成服务器是个很有用的工具。

许多组织根据安排好的日程表做例行 build，如每天晚上。这其实跟持续集成是两码事，而且做得远远不够。持续集成的最终目标就是要尽可能快地发现问题。Nightly build 意味着 bug 被发现之前可能会待上整整一天。一旦 bug 能在系统里呆这么久，找到并修复它们也会花较长的时间。

做好持续集成的一个关键因素是一旦 mainline 上的 build 失败了，它必须被马上修复。而在持续集成环境中工作最大的好处是，你总能在一个稳定的基础上做开发。mainline 上 build 失败并不总是坏事，但如果它经常出错，就意味着人们没有认真地在提交代码前先在本地更新代码和做 build。当 mainline 上 build 真的失败时，第一时间修复就成了头等大事。为了防止在 mainline 上的问题，你也可以考虑用 pending head 的方法。

当团队引入持续集成时，这通常是最难搞定的事情之一。在初期，团队会非常难以接受频繁在 mainline 上做 build 的习惯，特别当他们工作在一个已存在的代码基础上时更是如此。但最后耐心和坚定不移的实践常常会起作用，所以不要气馁。

保持快速 build

持续集成的重点就是快速反馈。没有什么比缓慢的 build 更能危害持续集成活动。这里我必须承认一个奇思怪想的老家伙关于 build 快慢标准的的玩笑（译者注：原文如此，不知作者所指）。我的大部分同事认为超过1小时的 build 是不能忍受的。团队们都梦想着把 build 搞得飞快，但有时我们也确实会发现很难让它达到理想的速度。

对大多数项目来说，XP 的10分钟 build 的指导方针非常合理。我们现在做的大多数项目都能达到这个要求。这值得花些力气去做，因为你在这里省下的每一分钟都能体现在每个开发者每次提交的时候。持续集成要求频繁提交，所以这积累下来能节省很多时间。如果你一开始就要花1小时的时间做 build，想加快这个过程会相当有挑战。即使在一个从头开始的新项目里，想让 build 始终保持快速也是很有挑战的。至少在企业应用里，我们发现常见的瓶颈出现在测试时，尤其当测试涉及到外部服务如数据库。

也许最关键的一步是开始使用分阶段build（staged build）。分阶段 build（也被称作 build 生产线）的基本想法是多个 build 按一定顺序执行。向 mainline 提交代码会引发第一个 build，我称之为提交 build（commit build）。提交 build 是当有人向 mainline 提交时引发的 build。提交 build 要足够快，因此它会跳过一些步骤，检测 bug 的能力也较弱。提交 build 是为了平衡质量检测和速度，因此一个好的提交 build 至少也要足够稳定以供他人基于此工作。

一旦提交 build 成功，其他人就可以放心地基于这些代码工作了。但别忘了你还有更多更慢的测试要做，可以另找一台计算机来运行运行这些测试。

一个简单的例子是两阶段 build。第一阶段会编译和运行一些本地测试，与数据库相关的单元测试会被完全隔离掉（stub out）。这些测试可以运行得非常快，符合我们的10分钟指导方针。但是所有跟大规模交互，尤其是真正的数据库交互的 bug 都无法被发现。第二阶段的 build 运行一组不同的测试，这些测试会调用真正的数据库并涉及更多的端到端的行为。这些测试会跑上好几小时。

这种情况下，人们用第一阶段作为提交 build，并把这作为主要的持续集成工作。第二阶段 build 是次级build，只有在需要的时候才运行，从最后一次成功的提交 build 中取出可执行文件作进一步测试。如果次级 build 失败了，大家不会立刻停下手中所有工作去修复，但团队也要在保证提交 build 正常运行的同时尽快修正 bug。实际上次级 build 并非一定要正常运行，只要 bug 都能够被检查出来并且能尽快得到解决就好。在两阶段 build 的例子里，次级 build 经常只是纯粹的测试，因为通常只是测试拖慢了速度。

如果次级 build 检查到了 bug，这是一个信号，意味着提交 build 需要添加一个新测试了。你应该尽可能把次级 build 失败过的测试用例都添加到提交 build 中，使得提交 build 有能力验证这些 bug。每当有 bug 绕过提交测试，提交测试总能通过这种方法被加强。有时候确实无法找到测试速度和 bug 验证兼顾的方法，你不得不决定把这个测试放回到次级 build 里。但大部分情况下都应该可以找到合适加入提交 build 的测试。

上面这个例子是关于两阶段 build，但基本原则可以被推广到任意数量的后阶段 build。提交 build 之后的其它 build 都可以同时进行，所以如果你的次级测试要两小时才能完成，你可以通过用两台机器各运行一半测试来快一点拿到结果。通过这个并行次级 build 技巧，你可以向日常 build 流程中引入包括性能测试在内的各种自动化测试。（当我过去几年内参加 Thoughtworks 的各种项目时，我碰到了很多有趣的技巧，我希望能够说服一些开发者把这些经验写出来。）

在模拟生产环境中进行测试

测试的关键在于在受控条件下找出系统内可能在实际生产中出现的任何问题。这里一个明显的因素是生产系统的运行环境。如果你不在生产环境做测试，所有环境差异都是风险，可能最终造成测试环境中运行正常的软件在生产环境中无法正常运行。

自然你会想到建立一个与生产环境尽可能完全相同的测试环境。用相同的数据库软件，还要同一个版本；用相同版本的操作系统；把所有生产环境用到的库文件都放进测试环境中，即使你的系统没有真正用到它们；使用相同的IP地址和端口；以及相同的硬件；

好 吧，现实中还是有很多限制的。如果你在写一个桌面应用软件，想要模拟所有型号的装有不同第三方软件的台式机来测试显然是不现实的。类似的，有些生产环境可 能因为过于昂贵而无法复制（尽管我常碰到出于经济考虑拒绝复制不算太贵的环境，结果得不偿失的例子）。即使有这些限制，你的目标仍然是尽可能地复制生产环 境，并且要理解并接受因测试环境和生产环境不同带来的风险。

如果你的安装步骤足够简单，无需太多交互，你也许能在一个模拟生产环境里运行提交 build。但事实上系统经常反应缓慢或不够稳定，这可以用 test double 来解决。结果常常是提交测试为了速度原因在一个假环境内运行，而次级测试运行在模拟真实的生产环境中。

我注意到越来越多人用虚拟化来搭建测试环境。虚拟机的状态可以被保存，因此安装并测试最新版本的build相对简单。此外，这可以让你在一台机器上运行多个测试，或在一台机器上模拟网络里的多台主机。随着虚拟化性能的提升，这种选择看起来越来越可行。

让每个人都能轻易获得最新的可执行文件

软件开发中最困难的部分是确定你的软件行为符合预期。我们发现事先清楚并正确描述需求非常困难。对人们而言，在一个有缺陷的东西上指出需要修改的地方要容易得多。敏捷开发过程认可这种行为，并从中受益。

为了以这种方式工作，项目中的每个人都应该能拿到最新的可执行文件并运行。目的可以为了 demo，也可以为了探索性测试，或者只是为了看看这周有什么进展。

这做起来其实相当简单：只要找到一个大家都知道的地方来放置可执行文件即可。可以同时保存多份可执行文件以备使用。每次放进去的可执行文件应该要通过提交测试，提交测试越健壮，可执行文件就会越稳定。

如果你采用的过程是一个足够好的迭代过程，把每次迭代中最后一个 build 放进去通常是明智的决定。Demo 是一个特例，被 demo 的软件特性都应该是演示者熟悉的特性。为了 demo 的效果值得牺牲掉最新的 build，转而找一个早一点但演示者更熟悉的版本。

每个人都能看到进度

持续集成中最重要的是沟通。你需要保证每个人都能轻易看到系统的状态和最新的修改。

沟通的最重要的途径之一是 mainline build。如果你用 Cruise，一个内建的网站会告诉你是否正有 build 在进行，和最近一次 mainline build 的状态。许多团队喜欢把一个持续工作的状态显示设备连接到 build 系统来让这个过程更加引人注目，最受欢迎的显示设备是灯光，绿灯闪亮表示 build 成功，红灯表示失败。一种常见的选择是红色和绿色的熔岩灯，这不仅仅指示 build 的状态，还能指示它停留在这个状态的时间长短，红灯里出现气泡表示 build 出问题已经太长时间了。每一个团队都会选择他们自己的 build 传感器。如果你的选择带点幽默性和娱乐性效果会更好（最近我看到有人在实验跳舞兔）。

即使你在使用手动持续集成，可见程度依然很重要。Build 计算机的显示器可以用来显示 mainline build 的状态。你很可能需要一个 build 令牌放在正在做 build 那人的桌子上（橡皮鸡这种看上去傻傻的东西最好，原因同上）。有时人们会想在 build 成功时弄出一点噪音来，比如摇铃的声音。

持续集成服务器软件的网页可以承载更多信息。Cruise 不仅显示谁在做 build，还能指出他们都改了什么。Cruise 还提供了一个历史修改记录，以便团队成员能够对最近项目里的情况有所了解。我知道 team leader喜欢用这个功能了解大家手头的工作和追踪系统的更改。

使用网站的另一大优点是便于那些远程工作的人了解项目的状态。一般来说，我倾向于让项目中发挥作用的成员都坐在一起工作，但通常也会有一些外围人员想要了解项目的动态。如果组织想要把多个项目的 build情况聚合起来以提供自动更新的简单状态时，这也会很有用。

好的信息展示方式不仅仅依赖于电脑显示器。我最喜欢的方式出现于一个中途转入持续集成的项目。很长时间它都无法拿出一个稳定的 build。我们在墙上贴了一整年的日历，每一天都是一个小方块。每一天如果 QA 团队收到了一个能通过提交测试的稳定 build，他们都会贴一张绿色的贴纸，否则就是红色的贴纸。日积月累，从日历上能看出 build 过程在稳定地进步。直到绿色的小方块已经占据了大部分的空间时，日历被撤掉了，因为它的使命已经完成了。

自动化部署

自 动化集成需要多个环境，一个运行提交测试，一个或多个运行次级测试。每天在这些环境之间频繁拷贝可执行文件可不轻松，自动化是一个更好的方案。为实现自动 化，你必须有几个帮你将应用轻松部署到各个环境中的脚本。有了脚本之后，自然而然的结果是你也要用类似的方式部署到生产环境中。你可能不需要每天都部署到 生产环境（尽管我见过这么做的项目），但自动化能够加快速度并减少错误。它的代价也很低，因为它基本上和你部署到测试环境是一回事。

如果你部署到生产环境，你需要多考虑一件事情：自动化回滚。坏事情随时可能发生，如果情况不妙，最好的办法是尽快回到上一个已知的正常状态。能够自动回滚也会减轻部署的压力，从而鼓励人们更频繁地部署，使得新功能更快发布给用户。（Ruby on Rails 社区开发了一个名为 Capistrano 的工具，是这类工具很好的代表。）

我还在服务器集群环境中见过滚动部署的方法，新软件每次被部署到一个节点上，在几小时时间内逐步替换掉原有的软件。

参见相关文章：进化式数据库设计

许多人在频繁发布时都遇到的一个障碍是数据库的迁移。数据库的改动很麻烦，因为你不能仅仅修改 schema，你还要保证数据本身也被顺利迁移。这篇文章描述了我的同事 Pramod Sadalage 自动化重构和迁移数据库的技巧。这篇文章只是一个简单的记录，其中的信息在 Pramod 和 Scott Amblers 关于数据库重构的书中有更详细的阐述[ambler-sadalage]。

在 web 应用开发中，我碰到的一个有趣的想法是把一个试验性的 build 部署到用户的一个子集。团队可以观察这个试验 build 被使用的情况，以决定是否将它部署到全体用户。你可以在做出最终决定之前试验新的功能和新的 UI。自动化部署加上良好的持续集成的纪律是这项工作的基础。

持续集成的益处

我认为持续集成最显著也最广泛的益处是降低风险。说到这里，我的脑海中还是会浮现出第一段描述的早期软件项目。他们已经到了一个漫长项目的末期（至少他们期望如此），但还是不知道距离真正的结束有多远。

延迟集成的问题在于时间难以估计，你甚至无法得知你的进展。结果是你在项目最紧张的阶段之一把自己置入了一个盲区，此时即使没有拖延（这很罕见）也轻松不了多少。

持续集成巧妙的解决了这个问题。长时间的集成不再存在，盲区被彻底消除了。在任何时间你都知道你自己的进展，什么能运转，什么不能运转，你系统里有什么明显的 bug，这些都一目了然。

Bug 让人恶心，它摧毁人的自信，搞乱时间表，还破坏团队形象。已部署软件里的 bug 招致用户的怒气。未完成软件里的 bug 让你接下来的开发工作受阻。

持续集成不能防止 bug 的产生，但它能明显让寻找和修改 bug 的工作变简单。从这个方面看，它更像自测试代码。如果你引入 bug 后能很快发现，改正也会简单得多。因为你只改了系统中很小的一部分，你无需看很多代码就能找到问题所在。因为这一小部分你刚刚改过，你的记忆还很新鲜，也会让找 bug 的工作简单不少。你还可以用差异调试——比较当前版本和之前没有 bug 的版本。

Bug 也会积累。你的 bug 越多，解决掉任何一个都会越困难。这部分原因是 bug 之间的互相作用，你看到的失败实际上是多个问题叠加的结果，这使得检查其中任何一个问题都更加困难。还有部分原因是心理层面的因素，当人们面对大量 bug 时，他们寻找和解决 bug 的动力就会减弱。《Pragmatic Programmer》一书中称之为“破窗综合症“。

使用持续集成的项目的通常结果是 bug 数目明显更少，不管在产品里还是开发过程中都是如此。然而，我必须强调，你受益的程度跟你测试的完善程度直接相关。其实建立测试系统并非想象中那么困难，但带来的区别却显而易见。一般来说，团队需要花一定时间才能把 bug 数量减少到理想的地步。做到这一点意味着不断添加和改进测试代码。

如果你用了持续集成，你就解决了频繁部署的最大障碍之一。频繁部署很有价值，因为它可以让你的用户尽快用到新功能，从而快速提供反馈，这样他们在开发过程中可以有更多的互动。这可以帮助打破我心目中成功的软件开发最大的障碍——客户与开发团队之间的障碍。

引入持续集成

看 到这里，你一定想要尝试一下持续集成了。但是从哪里开始呢？我在上面描述了一整套的实践，这些可以让你体验到所有的好处。但你也不必一开始就照单全收，你 有自己的选择余地，基本上取决于你的环境和团队的特性。我们也从过去的实践中吸取了一些经验和教训，做好下面这些事会对于你的持续集成运作有重要的意义。

最早的几步之一是实现 build 自动化。把所有需要的东西都放进版本控制系统里，这样你就可以用一条命令 build 整个系统。这对许多项目而言不是什么小任务，这对于其他东西正常工作非常重要。刚开始你可能只是偶尔需要的时候做一个 build，或者只是做一个自动的 nightly build。当你还没有开始持续集成时，自动 nightly build 也是一个不错的开始。

其次是引入一些自动化测试到你的 build 中。试着指出主要出错的地方，并要让自动化测试暴露这些错误。建立又快又好的测试集合会比较困难，特别在已存在的项目中，建立测试需要时间。你必须找个地方开始动手，就像俗话说的，罗马不是一天建成的。

还要试着加快提交 build 的速度。虽然需要几个小时 build 的持续集成也比什么都没有好，但能做到传说中的10分钟会更好。这通常要对你的代码动一些大手术，以剥离对运行缓慢那部分的依赖。

如果你刚刚开始一个新项目，从一开始就用持续集成。对build时间保持关注，当慢于10分钟时就立即采取行动。通过快速行动，你可以在代码变得太大之前做一些必要的架构调整。

比所有事情都重要的是寻找帮助。找一个以前做过持续集成的人来帮你。像所有新技巧一样，当你不知道最终结果怎样的时候会非常难以实施。请一个导师（mentor）可能会花些钱，但如果你不做，你会付出时间和生产效率损失的代价。（免责声明/广告：是的，我们 ThoughtWorks 在这个领域提供咨询服务。不管怎样，我们曾经犯过你可能会犯的大多数错误。）

最后的思考

在我和 Matt 写完最初那篇论文后的几年，持续集成已经成为了软件开发的一个主流方法。ThoughtWorks 的项目很少有不用到它的。我们也能看到世界各地的人们在用持续集成。与极限编程中一些充满争议的实践不同，我很少听到关于持续集成的负面消息。

如果你还没用持续集成，我强烈建议你试一下。如果你已经在做了，可能这篇文章中的某些方法可以帮你得到更好的效果。过去几年中，我们已经了解了很多关于持续集成的知识，我希望还有更多的知识可以让我们学习和提高。

What is Hudson?

Hudson monitors executions of repeated jobs, such as building a software project or jobs run by cron. Among those things, current Hudson focuses on the following two jobs:

1. Building/testing software projects continuously, just like CruiseControl or DamageControl. In a nutshell, Hudson provides an easy-to-use so-called continuous integration system, making it easier for developers to integrate changes to the project, and making it easier for users to obtain a fresh build. The automated, continuous build increases the productivity.
2. Monitoring executions of externally-run jobs, such as cron jobs and procmail jobs, even those that are run on a remote machine. For example, with cron, all you receive is regular e-mails that capture the output, and it is up to you to look at them diligently and notice when it broke. Hudson keeps those outputs and makes it easy for you to notice when something is wrong.

Features

Hudson offers the following features:

1. Easy installation: Just java -jar hudson.war, or deploy it in a servlet container. No additional install, no database.
2. Easy configuration: Hudson can be configured entirely from its friendly web GUI with extensive on-the-fly error checks and inline help. There's no need to tweak XML manually anymore, although if you'd like to do so, you can do that, too.
3. Change set support: Hudson can generate a list of changes made into the build from CVS/Subversion. This is also done in a fairly efficient fashion, to reduce the load on the repository.
4. Permanent links: Hudson gives you clean readable URLs for most of its pages, including some permalinks like "latest build"/"latest successful build", so that they can be easily linked from elsewhere.
5. RSS/E-mail/IM Integration: Monitor build results by RSS or e-mail to get real-time notifications on failures.
6. After-the-fact tagging: Builds can be tagged long after builds are completed
7. JUnit/TestNG test reporting: JUnit test reports can be tabulated, summarized, and displayed with history information, such as when it started breaking, etc. History trend is plotted into a graph.
8. Distributed builds: Hudson can distribute build/test loads to multiple computers. This lets you get the most out of those idle workstations sitting beneath developers' desks.
9. File fingerprinting: Hudson can keep track of which build produced which jars, and which build is using which version of jars, and so on. This works even for jars that are produced outside Hudson, and is ideal for projects to track dependency.
10. Plugin Support: Hudson can be extended via 3rd party plugins. You can write plugins to make Hudson support tools/processes that your team uses.

Hudson Best Practices

Continuous Integration with automated test execution has seen broad adoption in recent years. The ideas behind Continuous Integration have changed how companies look at Build Management, Release Management, Deployment Automation, and Test Orchestration. This section provides a set of best practices for Hudson - A Continuous Integration Solution to provide executives, business managers, software developers and architects a better sense of the development progress and code quality of projects throughout the development lifecycle. (View Hudson Best Practices)

Introductory Articles

• http://linsolas.developpez.com/articles/hudson/ (French)
• http://www.slideshare.net/carlo.bonamico/continuous-integration-with-hudson/
• Kohsuke presenting Hudson in FOSDEM 2008 (video)
• Introduction to Hudson (French)
• Introduction and best practice by Kohsuke (Japanese)
• Introdución a Hudson (Spanish)
• Kohsuke presenting Hudson in JavaZone 2009 (video)
• Hawebs.net docs for Hudson (简体中文 Simplified Chinese)
• Hudson Wiki - Hudson 中文维基 (简体中文 Simplified Chinese)

Test Drive

Launch Hudson through Java Web Start for a test drive. Once it launches, visit http://localhost:8080/ to get to the dashboard. Any configuration that you do with this Hudson will be stored in ~/.hudson, so your data will survive through Hudson process restart.

Installation

To run Hudson, minimally you need to have JRE 1.5 or later. After you download hudson.war, you can launch it by executing java -jar hudson.war. This is basically the same set up as the test drive, except that the output will go to console, not to a window.

Alternatively, if you have a servlet container that supports Servlet 2.4/JSP 2.0 or later, such as Glassfish, Tomcat 5, JBoss, Jetty 6, etc., then you can deploy hudson.war as you would any WAR file. See this document for more about container-specific installation instruction.

Once the war file is exploded, run chmod 755 hudson in the exploded hudson/WEB-INF directory so that you can execute this shell script.

If you're running on Windows you might want to run Hudson as a service so it starts up automatically without requiring a user to log in. One way is to first install Tomcat as a service and then deploy Hudson to it in the usual way.  Another way is to use the Java Service Wrapper. However, there may be problems using the service wrapper, because the Main class in Hudson in the default namespace conflicts with the service wrapper main class. Deploying inside a service container (Tomcat, Jetty, etc.) is probably more straightforward, even for developers without experience with such containers.

Also, see how other people are deploying Hudson to get some idea of how to make it fit your environment.

• Case study of Sven Reimers
• Case study of Kohsuke Kawaguchi
• Case study of Rhett Sutphin
• Case study of Ned Collyer
• Case Study of Arnaud Lacour
• Case Study of JBoss
• Using Hudson with Tibco BusinessWorks
• Case Study of Xuggler and Red5
• we'd love to list yours here. Please talk to us.

【windows OS系统下的： Hudson环境搭建过程记录】

1. 安装jakarta-tomcat-5.0.30.exe, 使用的jdk（C:\Program Files\Java\jdk1.6.0_14）。

设置HUDSON_HOME环境变量，按住windows键+Pause键快速出现环境变量设置界面。

HUDSON_HOME=C:\hudson_ci\hudson

TOMCAT_HOME=C:\hudson_ci\Tomcat 5.0

       JAVA_HOME=C:\Program Files\Java\jdk1.6.0_14

       CALSSPATH=C:\ProgramFiles\Java\jdk1.6.0_14\lib\dt.jar;C:\ProgramFiles\Java\jdk1.6.0_14\lib\tools.jar

2. hudson-2.0.0.war copy到C:\hudson_ci\Tomcat 5.0\webapps目录。

3. 访问http://localhost:8080/hudson-2.0.0/出现hudson web页面。

=============================================================

【linux (fedora)系统下hudson搭建过程】

1. fedora机器的一些信息

       IP：172.28.6.36（7楼时）

       PC账户：root/123456

2. 安装JDK jdk-6u21-linux-i586-rpm.bin (JDK6)

(下载页面

http://zh.sourceforge.jp/projects/sfnet_crawlzilla/downloads/other/jdk-6u21-linux-i586-rpm.bin/)

执行：./ jdk-6u21-linux-i586-rpm.bin

[root@localhost ~]# vim /etc/profile

在最下面加入如下内容

JAVA_HOME=/usr/java/jdk1.6.0_21 #你的jdk所在目录

PATH=$PATH:$JAVA_HOME/bin

CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar

export JAVA_HOME

export PATH

export CLASSPATH

1) 马上生效：

[root@localhost ~]# source /etc/profile

3）查看是否已生效

[root@localhost kikitest]# java -version

java version "1.6.0_21"

Java(TM) SE Runtime Environment (build 1.6.0_21-b06)

Java HotSpot(TM) Server VM (build 17.0-b16, mixed mode)

3. 安装Tomcat6

tar xzvf  apache-tomcat-6.0.32.tar.gz

4.

PS:

1.） 之前试过2次jdk和tomcat6都安装好的情况，每次浏览hudson就出现内存泄露的情况，是因为hudson-2.0.1.war和hudson-2.0.0.war虽然在windows环境访问OK，但是在fedora中不兼容，于是从hudson官网下了个hudson.war，部署到webapps最终搞定。

2.）

yum list | grep tomcat    //列出tomcat可安装包

yum -y install tomcat5   //安装tomcat5

yum remove tomcat5     //卸载tomcat5

yum remove java          //卸载所有JAVA

rpm –qa | grep jdk         //查找jdk

查看方法:rpm –qa |grep –I java

卸载方法:rpm –e –nodeps java*包名

将jdk-6u21-linux-i586-rpm.bin给予可执行权限

修改权限：chmod u+x jdk-6u21-linux-i586-rpm.bin

SVN里的钩子脚本（T&W）

【post-commit】S204提交之后邮件通知

#!/bin/sh

REPOS="$1"

REV="$2"

DOMAIN=twsh.com

PROJECTNAME=`basename $REPOS`

/urr/local/ActivePerl/site/bin/svnnotify

--repos-path "$1"

--revision "$2"

--to $PROJECTNAME@$DOMAIN

--user-domain $DOMAIN

--smtp 10.58.100.8

--smtp-user svn@twsh.com –

-smtp-pass 15021151553

--subject-prefix [SVN:$PROJECTNAME] -g en_US

--handler "HTML::ColorDiff"

--with-diff

--diff-encoding GBK

【post-commit】DSL库提交之后的邮件通知（DSL是一个大库，里面包含很多小项目库）

.

#!/bin/sh

REPOS="$1"

REV="$2"

DOMAIN=twsh.com

PROJECTNAME=`basename $REPOS`

PATHFILTER='4.02L.03_CT_BCM963293+TK3715_E8C_EPON\|Gewv2.3L19A-B2-V03'

SVNLOOK=/usr/bin/svnlook

if ( $SVNLOOK dirs-changed -r $REV "$REPOS" | grep "$PATHFILTER" > /dev/null ); then

    /urr/local/ActivePerl/site/bin/svnnotify \

        --repos-path "$REPOS" \

        --revision "$REV" \

        --to ponsw@twsh.com \

        --user-domain $DOMAIN \

        --smtp 10.58.100.8 \

        --smtp-user svn@twsh.com \

        --smtp-pass 15021151553 \

        --subject-prefix [SVN:$PROJECTNAME] \

        -g en_US \

        --handler "HTML::ColorDiff" \

        --with-diff \

        --diff-encoding GBK

fi

【pre-commit】提交之前LOG限制

#!/bin/sh

REPOS="$1"

TXN="$2"

SVNLOOK=/usr/bin/svnlook

if ( $SVNLOOK log -t "$TXN" "$REPOS" | grep "[a-zA-Z0-9]" > /dev/null ); then

        exit 0;

fi

echo "Empty log message not allowed. Commit aborted!" >&2

exit 1;

【pre-revprop-chang】实例验证过，可修改:author and log message.

#!/bin/sh

REPOS="$1"

REV="$2"

USER="$3"

PROPNAME="$4"

ACTION="$5"

原文:http://www.blogjava.net/xiaodu/archive/2008/07/08/213298.html

一.什么是持续集成

持续集成的核心概念

CI 过程会经常构建软件组件；在许多情况下，每当源代码存储库（比如 Subversion 或 ClearCase）中的代码发生变化时，都要构建软件组件。CI 的好处是：经常构建软件可以确保尽早遇到问题（比如代码缺陷），避免问题在软件开发周期晚期变复杂时才被发现。

工具与过程

尽管 CI 实际上是一个过程，但是持续集成 这个词常常与一个或多个工具相关联。在本教程中，讲解如何安装、配置和使用 Hudson 作为 CI 服务器，但是要记住，CI 远不只是个工具。实际上，使用的工具可能是 CI 比较次要的方面，因为 CI 工具所做的仅仅是在代码存储库中探测到修改时运行构建。构建过程本身比用来运行它的工具重要得多。

开始使用 CI

开始使用 CI 需要三个组件：

• 用 Ant 或 Maven 等工具建立的自动构建过程
• 一个代码存储库，比如 CVS 或 Subversion
• 一个 CI 服务器，比如 Hudson，但是 cron 作业也可以满足需要

我们来详细讨论这些组件。

自动的构建

CI 过程会经常集成软件，这需要通过构建来完成。在 Java 环境中，Ant 是常用的构建平台。可以使用 Ant 可靠地自动执行编译、测试等任务，甚至可以执行软件检查和部署。在掌握了 CI 的所有组件之后，您会发现构建策略是成功的 CI 过程最重要的方面。如果缺少适当的构建过程，CI 就难以发挥作用。

源代码管理

为 了让 CI 正确地发挥作用，需要一个源代码管理（SCM）系统或存储库，比如 Subversion 或 CVS。CI 服务器向 SCM 存储库查询代码修改。在找到修改时，CI 服务器执行签出（即更新本地沙箱）并执行构建。除了执行得更频繁之外，构建过程与在本地环境中执行的构建相同。

CI 服务器

对 于成功的 CI 过程，需要用一个自动的过程监视 SCM 存储库并在探测到修改时运行构建，这也非常重要。对于 Java 平台，有许多可用的 CI 服务器，包括开放源码软件和商业产品。它们的基本配置都很相似，适合监视特定的 SCM 并在探测到修改时运行构建。所有 CI 服务器都有自己的优缺点。Hudson 尤其让人感兴趣，因为它容易配置而且具有强大的插件，这些插件可以显示测试结果趋势等信息。

二.Hudson 简介

Hudson 是一种革命性的开放源码 CI 服务器，它从以前的 CI 服务器吸取了许多经验教训。Hudson 最吸引人的特性之一是它很容易配置：很难找到更容易设置的 CI 服务器，也很难找到开箱即用特性如此丰富的 CI 服务器。Hudson 容易使用的第二个原因是它具有强大的插件框架，所以很容易添加特性。例如，一个 Hudson 插件可以随时间的推移跟踪 FindBugs 和代码覆盖。它还可以报告测试结果的趋势（来自 JUnit 或 TestNG）以及构建结果和对应的执行时间。

Hudson 需要运行 Java 5。如果需要使用 Hudson 附带的嵌入式容器（Winstone）之外的其他容器，那么只需使用一种 Servlet 2.4 容器。对于大多数情况，Winstone 就足够了。

三.Hudson使用

CI 过程的最后一个方面是 CI 服务器本身。CI 服务器在整个开发过程中的主要作用是控制者：当服务器在代码存储库中探测到修改时，它将运行构建的任务委托给构建过程本身。如果构建失败了，那么 CI 服务器将通知相关方面，然后继续监视存储库。它的角色看起来是被动的；但是，它是快速反映问题的关键。

安装 Hudson

使用 Hudson 的主要好处之一是它的设置很简单。在最简单的情况下，Hudson 只需要两个步骤：

1. 下载最新的版本（它打包为一个 WAR 文件）。 hudson官方网址:https://hudson.dev.java.net/
2. 运行 java -jar hudson.war。

这样就可以了。因为下载的是一个 WAR 文件，所以如果愿意，可以将它部署在 Tomcat 或 JBoss 等容器中。这完全由您自己决定。当然，Hudson 假设在安装它的机器上运行着 Java 5，而且如果定义了 JAVA_HOME 环境变量，Hudson 就会使用它。（正如前面提到的，Hudson 需要 Java 5。）

在安装并运行 Hudson 之后（将 WAR 文件部署到 servlet 容器或从命令行执行 java -jar hudson.war），启动浏览器并访问默认安装位置。如果通过命令行运行 Hudson 而且您在本地机器上，那么可以访问 http://localhost:8080/。

配置 Hudson

如果访问 Hudson 主页的本地实例并单击左上角的 Manage Hudson 链接，应该会看到图 3 所示的可配置选项列表。

参数说明:
system.message 填写一些说明信息
Quiet period:hudson定时构建工程的时间(秒)
 Enable security:设置hudson登陆的规则(默认为匿名登陆)
TCP port for JNLP slave agents:不了解JNLP不敢胡写总之就是三种方式:固定(fixed) 随机(Radom) 不使用(disabled),使用固定时可以填入JNLP信息

还可以配置服务器的其他几个方面，比如向 Hudson 提供一个电子邮件服务器的位置，以便在构建失败时接收电子邮件。根据您的组织设置电子邮件的方式，可能需要让系统管理员帮助设置这个特性。设置电子邮件并 不是必需的；Hudson 还支持以 RSS 作为通知机制，对于某些人来说，这种方式比电子邮件更好。究竟选择哪些通知机制完全取决于您。（注意，这里说的是 “哪些”，也就是说，可以同时使用多种通知机制！）

在 Hudson 中配置项目

既然 Hudson 已经能够与 SCM 存储库通信了，就该配置项目了。这个示例所用的项目称为 solar-ci。在 Hudson 主页上单击左上角的 New Job 链接。这时会看到图 5 所示的屏幕：

该页面可以使我们通过hudson来管理cvs里的一个对应的工程

Project name:工程名称

Description:描述信息

Discard build:如果选择此项可以设置build记录保存的天数,或者build记录保存的数理,或者只保存最新的build记录,一般不需填写

Advance project options:可以设置hudson定时检查cvs工程的时间间隔,还可以指定cvs工程check out到本地的工程路径,一般不需要填写

Source code management:我们选择cvs将出现以下参数:

Cvsroot:将写cvs登陆字符串,格式(:protocol:user:password@host:path),例如: :pserver:cvsadmin:1@127.0.0.1:2401:/CVSNT/Repository,使用cvs必填
 

Modules:填写cvs仓库下的具体工程名, 使用cvs必填

Branch:填写分支名称,也可以勾选this is a tag,no a branch指定标记名称
 

选择subversion可以进行相应的subversion设置

Build trigger可以设置hudson自动执行的一些动作,build after others projects are built指定hudson构建完成后需要继续构建的工程名

Build periodically 根据hudson定义的语法规则来设定自动构建工程的时间间隔

Post-build actions

设置一些构建完成后的动作,如放邮件,打包,产生测试报告,产生java doc 等.

点击ok保存设置

使用hudson
进入刚配置的项目,可以在左侧build history看到历史的build记录,点击build now 可以手动执行构建动作,完成后可以通过记录标记的颜色来看是否出错,红色有错,蓝色成功.点击记录查看详细信息,如果有变化hudson将列出类信息

提起软件质 量管理，人们更多地会想起ISO9001、CMM、CMMI这些“质量管理圣经”。但国内企业做了这么多年的质量认证，却没有使软件质量有大幅度地提高。 实际上，很多企业通过ISO9001、CMM、CMMI等质量认证的目的就不是为了提高质量：有的企业是为了跟风，有的企业则是为了向客户展示证书。

    在很多软件企业里，软件质量管理在内部开发产品时做的相对较好：因为产品开发通常在各个软件企业的研发中心进行，涉及的人员以内部为主，进度压力相对较 小，可以投入时间和精力来开展软件质量管理。对于有客户进行参与的软件实施项目，多数企业为了节省成本和赶进度，往往会忽略质量管理，最后导致软件质量很 差——投产后的软件经常会被用户发现很多Bug。实际上，在项目实施中开展质量管理工作更加重要，因为产品上线后的质量问题往往意味着更大的投入。本文将 和读者一起探讨软件项目实施中如何开展质量管理工作。

    1. 质量管理主要内容

    在探讨项目实施中开展软件质量管理工作前，我们先回顾一下质量管理的基础知识。质量管理主要包括三个过程：质量计划制定、质量保证和质量控制。

    质量计划：是质量管理的第一过程域，它主要指依据公司的质量方针、产品描述以及质量标准和规则等制定出来实施方略，其内容全面反应用户的要求，为质量小组 成员有效工作提供了指南，为项目小组成员以及项目相关人员了解在项目进行中如何实施质量保证和控制提供依据，为确保项目质量得到保障提供坚实的基础。

    质量保证：是贯穿整个项目全生命周期的有计划和有系统的活动，经常性地针对整个项目质量计划的执行情况进行评估、检查与改进等工作，向管理者、顾客或其他方提供信任，确保项目质量与计划保持一致。

    质量控制：是对阶段性的成果进行测试、验证，为质量保证提供参考依据。

    在软件实施项目中，质量保证对应于技术评审与过程检查，质量控制对应于软件测试等工作，如图1所示。

图1 全面软件质量管理模型

    2. 项目中质量管理的原则

    在软件项目实施中，由于进度和成本两大因素的影响，它的质量管理与产品开发有着很大的差别。因此，在项目实施中做好质量管理工作应该坚持自己的原则。

    我们先看一下国内企业实施软件项目的一些特征：

    “进度高于一切”可以说是国内企业实施项目的最大特点，而“为了短期利益不惜愚弄客户”、不重视质量、喜欢追究责任则成了这道“靓丽”风景上的点缀。回顾 国内很多IT热门领域，可以发现多是大家看好某个领域后就会“一哄而上”，然后进行低价为主的恶性竞争，结果是搞得自己没有能力来重视质量，而为了生存， 还要拼命的加班赶进度，最后形成一个怪圈。可以说在很多IT领域，国内软件企业为自己精心打造了无数个这样的“怪圈”。

    国内的企业要想挑出“怪圈”，最根本的办法是从源头做起：即从项目一开始就开始重视产品质量，因为质量是根本，好的质量加上好的服务才能拥有更强的市场竞 争能力。同时也应该认识到质量、进度、成本是相辅相成的，决不可以忽略任何一个方面。过分重视质量，必然会耽误进度和加大成本投入，甚至会失去市场机会； 过分节约成本、抢进度又会降低质量，质量不好的产品肯定不会在市场上走多远。

    根据作者多年的经验，IT企业要想在软件项目实施中做好质量工作，应该坚持下面几个重要的原则：

    ·不但要主观认识到质量的重要性，同时还要落实到行动中。

    软件质量管理的重要性已经逐渐被国内的IT企业认可，但是要落实到具体的项目实施工作中，并通过它提高软件质量，还有一段很长的路要走。因为几乎所有的软件公司都灌输着“进度高于一切”的思想，只要是为了赶进度和发布产品，所有影响进度的工作都可以忽略。

    因此，把想法落实到实际工作中是做好软件质量管理的第一原则。

    ·树立提高质量就是尊重客户的思想。

    可以说，目前很多公司都有“愚弄客户”的嫌疑，不管是有心的还是无意的。很多公司实施项目时只要能拿到“钱”就达到目的了，因此也就不在乎是否掩盖缺陷和敷衍客户。至于后果，那是以后的事情了。

    在软件产业发达的今天，已经是客户的买方市场，客户永远会选择质量和服务都表现良好的产品来满足自己的需求。因此，我们应该尊重客户，把客户放在“上帝”的位置上，认证做好质量。

    ·建立规范的质量保证体系，逐步使软件开发进入良性循环状态。

    在没有开发规范的前提下，软件团队是不能开发出高质量软件的。因此软件团队一定要建立规范的质量保证体系，同时把规范体系逐步落实到工作中。如果急功近利，不但会做很多浪费人力和物力的无效工作，还会给客户留下不好的印象。

3. 项目中质量管理开展方法

    要想在项目中开展质量管理，就不能脱离中国软件企业实施项目的现状：工期短、任务重、利润低。在这种背景下，开展全面质量管理是不太现实的，只能根据每个项目的进度和成本实际情况来进行合理的投入，否则质量投入过大不但耽误进度，还会影响到企业利润，这是本末倒置的。在项目实施中，通常是最大限度地去提高质量。

    在图1的全面软件质量管理模型中，我们可以看出质量管理有三大类：技术评审、过程检查、软件测试，项目实施中的软件质量管理仍然围绕着这三类工作来开展。 由于很多项目实施中没有专门的质量人员，这个时候项目经理应该更多地去组织技术评审和安排人员进行过程检查，可以考虑让软件测试人员承担一些质量保证工 作，因为测试人员通常是必不可少的。

    下面探讨一下每类工作如何开展。

    ·项目实施中的技术评审
   
    技术评审可以把一些软件缺陷消灭在代码开发之前，尤其是一些架构方面的缺陷。在项目实施中，为了节省时间应该优先对一些重要环节进行技术评审，这些环节主 要有：项目计划、软件架构设计、数据库逻辑设计、系统概要设计等。如果时间和资源允许，可以考虑适当增加评审内容。

    项目实施中技术评审如表1所示：

表1 项目实施中技术评审

 
    很多软件项目由于性能等诸多原因最后导致失败，实际上都是由于设计阶段技术评审做的不够。一味地节省时间、关键工作仅由某几个人执行、整个项目的成败依赖于某些“个人英雄”等做法是十分错误的，重要的技术评审工作是不可以忽略的。

    ·项目实施中的过程检查

    项目经常延期是中国软件企业实施很多项目时候的特点，因此项目实施中的过程检查重点是“进度检查”。在实际工作中，很多项目都是启动一段时间后就开始不停 地加班，使整个团队处于疲惫状态，导致工作效率低下，最后把项目计划丢在一边。对于这种情况，比较好的做法是不断地检查项目计划与实际进度是否存在偏差， 如果存在偏差则找出问题的根源，然后消除引起问题的因素，例如可以调整进度安排或者增加人力投入，这样就避免了问题不断放大。

    版本检查在项目实施中也需要特别注意，因为版本混乱会带来很大麻烦，尤其进行测试的时候。此外，项目实施时候也应该注意文档检查，尤其是一些关键文档的质量，例如接口文档、用户手册等。

    ·项目实施中的软件测试

    项目实施相关的全部质量管理工作中，软件测试的工作量最大。由于很多项目在实施中非常不规范，因此软件测试一定要把好关。软件测试应该重点做好测试用例设计、功能测试、性能测试、缺陷管理等工作。

    测试用例设计：虽然项目实施中没有太多时间来设计测试用例，但是这个环节是必不可少的。项目实施中设计测试用例应该根据进度安排，优先设计核心应用模块或 核心业务相关的测试用例。设计测试用例的时候可以不设计的特别完善，基本目标是列出测试重点，对测试执行起良好地指导作用，这个时候的测试用例更像是“测 试大纲”。

    能测试：软件首先应该从功能上满足用户需求，因此功能测试是质量管理工作中的重中之重。功能测试在产品试运行前一定要开展好，否则将会发生“让用户来执行测试”的情况，后果非常严重。

    性能测试：性能测试是经常容易被忽略的测试。在实施项目过程中，应该充分考虑软件地性能，运行较慢的软件仍然不会为用户所接受。性能测试可以根据用户对软 件的性能需求来开展，通常系统软件和银行、电信等特殊行业应用软件对性能要求较高，应该尽早进行，这样更易于早解决问题。

    缺陷管理：缺陷跟踪与管理工作也经常被忽略，很多问题会被遗忘，直到客户再次发现。建议测试人员在项目实施中仍然采用一些工具进行缺陷管理与跟踪，保证任何缺陷都得到妥善的处理。

    此外，对于一些项目，如果实在没有测试人员，可以考虑让开发人员互相进行测试，这样也可以发现很多缺陷。

    项目实施中的质量管理工作是非常复杂的，存在很多不可以控制的因素，例如没有质量人员、测试环境不具备等。因此，项目实施中的质量管理原则应该是“最大限度地去提高质量”。只有这样，才能更好地利用现有资源尽可能地提高质量。

本文主要从CMM和CMMI的要求出发，介绍了标准主要涉及的配置管理内容，并对相应内容进行初步地说明，最后提供了一个配置管理在项目实施的指南和一个在组织中部署配置管理的模型。

1 配置管理内容的逻辑关系

在CMM和CMMI中，将配置管理的目的定义为“建立和维护产品的完整性”，这个目标没有提到对项目管理的支持，也就是说，它定义的配置管理的目标 比当前业界对配置管理的认识有些缩小。但是，仔细分析可以发现“建立和维护产品的完整性”是其他配置管理目标的基础。下面就从这个目标出发进行分析。逻辑 关系见下图：

配置完整性（对标准的理解）

1. 产品完整性：就是项目提交的工作成果是“产品集合完整、子产品的正确”的

2. 产品集合完整：产品包含的子产品（配置项）是完整的

3. 子产品的正确：子产品（配置项）达到了需求要求，满足标准、规程的要求

逻辑关系分析

1. “基线管理”支持“产品集合完整”，明确产品的“子产品”（配置项）集合，并进行管理和控制
    2. “配置项管理”，提供了了对子产品（配置项）的控制管理，支持“子产品的正确”
    3. “变更管理”，同时支持“产品集合完整、子产品的正确”，用于控制子产品（配置项）和产品（基线）的变更
    4. “配置标示”，建立对配置项（子产品）的识别、命名，支持“配置项管理”
    5. “版本控制”，控制配置项（子产品）生命历程，保留配置项（子产品）演进历史
    6. “过程管理”，就是对配置项、基线的建立、变更的状态标示、过程控制，保证产品（或子产品）按照规定的流程进行了操作；例如“配置项”进入“基线”的过程包括：配置项标示、产品验证、进入配置、配置审计等
    7. “配置计划”、“配置库管理”、“配置审计”、“配置报告”等是整个配置管理得支持系统。提供了配置管理“可视性”和监督管理

2 配置和配置项

在配置管理中，“配置”和“配置项”是重要的概念，“配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置”包括了即将受 控的所有产品特性，其内容及相关文档，软件版本，变更文档，软件运行的支持数据，以及其他一切保证软件一致性的组成要素，相对与硬件类配置，软件产品的 “配置”包括更多的内容并具有易变性。
    受控软件经常被划分为各类配置项（Configuraion items, CIs），这类划分是进行软件配置管理的基础和前提，CIs是逻辑上组成软件系统的各组成部分。比如一个软件产品包括几个程序模块，每个程序模块及其相关 文档和支撑数据可能被命名为一个CI。一个系统包括的CIs的数目是一个与设计密切相关的问题。一个纯软件的CI通常也称之为软件配置项（CSCI）。
    现在所有的配置管理工具均提供对配置项的管理工具，包括(Check in和Check out机制的 )版本管理和版本标号功能。由于版本和标号管理比较繁琐，一般推荐使用配置管理工具，减少事务性工作。

3 基线

在配置管理系统中，基线就是一个CI或一组CIs在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态，而这个过程被称为“基线化”。 每一个基线都是其下一步开发的出发点和参考点。基线确定了元素（配置项）的一个版本，且只确定一个版本。一般情况下，基线一般在指定的里程碑处创建，并与 项目中的里程碑保持同步。

一般地，第一个基线包含了通过评审的软件需求，因此称之为“需求基线”，通过建立这样一个基线，受控的系统需求成为进一步软件开发的出发点，对需求的变更被正式初始化、评估。受控的需求还是对软件进行功能评审的基础。
    每个基线都将接受配置管理的严格控制，对其的修改将严格按照变更控制要求的过程进行，在一个软件开发阶段结束时，上一个基线加上增加和修改的基线内容形成下一个基线，这就是“基线管理”的过程。

4 基线、配置、配置项的关系

基线的组成，以及配置项和配置的关系如下图：

针对某个具体得项目，可以根据基线的内容，建立一个基线信息的跟踪表，例如如下：

[注]：被色块覆盖的表示，此配置项属于对应列的基线
[注]：在色块的栏目填写对应配置项的版本号

5 变更管理

在有效标示了配置并进行了管理之后，如何保证它们在复杂多变得开发过程中真正的处于受控的状态，并在任何情况下都能迅速的恢复到任一历史状态就要依赖有下的变更管理。

为了更好的指导变更范围的影响分析，可以通过两种表格来帮助发现受到变更影响的内容，一种是《需求跟踪表》，一种是《配置项依赖关系表》，分别如下：

6 配置库管理

在实际的开发活动中系统中，为了让每个开发人员和各个开发团队能更好的分工合作，同时又互不干扰，必须规划好工作空间的管理。主要的手段是设置配置库（即文件夹设置），和设置版本的分支，来实现对配置项权限管理。

设置版本分支

基本上要为每个配置项从建立开始就划分成3个不同的分支：私有分支、集成分支、公共（主干）分支。让它们分别对应3类工作空间。

上面定义的3类工作空间（分支）由配置管理员统一管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基线的推进。

配置库的设置

决定配置库的结构是配置管理活动的重要基础。一般常用的是两种组织形式：按配置项类型分类建库和按任务建库。

按配置项的类型分类建库的方式经常为一些咨询服务公司所推荐，它适用于通用的应用软件开发组织。这样的组织一般产品的继承性较强，工具比较统一，对 并行开发有一定的需求。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。但由于这样的库结构并不是面向和各个开发团队的 开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦。

而按任务建立相应的配置库则适用于专业软件的研发组织。在这样的组织内，使用的开发工具种类繁多，开发模式以线性发展为主，所以就没有必要把配置项严格的分类存储，人为增加目录的复杂性。因此，笔者认为特别是对于研发性的软件组织来说，还是采用这种设置策略比较灵活。

配置库的日常工作

配置库的日常工作是一些事务性的工作，主要保证配置库的安全性，包括：

对配置库的定期备份

清除无用的文件和版本

检测并改进配置库的性能等

7 配置报告

配置状态报告就是根据配置项操作的记录来向管理者报告软件开发活动的进展情况。这样的报告应该是定期进行，并尽量通过CASE工具自动生成，用数据库中的客观数据来真实的反映各配置项的情况。

配置状态报告应着重反映当前基线配置项的状态，以作为对开发进度报告的参照。为了说明项目状态对变更的情况也应当进行报告。有时，对配置库的情况也 进行说明，例如备份次数，磁盘占用空间等等。只要是关心的信息，均可作为状态报告的内容。这些信息进行有效记录，往往可以作为项目度量的重要数据来源。

8 配置审计

配置审计的主要作用是作为变更控制的补充手段，来确保某一变更需求已被切实实现。在某些情况下，它被作为正式的技术复审的一部分，但当软件配置管理 是一个正式的活动时，该活动由SQA人员单独执行。 审计机制保证修改的动作被完整地记录，也就是说，记录了谁修改了这个工件，什么时候做的修改，为什么原因做出这个改动，以及修改了哪些地方。 在版本控制过程中，如果利用一些配置管理工具（或者版本控制工具）的支持，则可以自动地记录审计工作所需的四个“W”（Who、When、Why、 What）。 同时配置审计工作应当可以说明如下信息。

9 项目实施指南

一个软件研发项目一般可以划分为三个阶段：计划阶段、开发阶段和维护阶段。然而从软件配置管理的角度来看，后两个阶段所涉及的活动是一致，所以就把它们合二为一，成为“项目开发和维护”阶段。

一个项目设立之初项目经理首先需要制定整个项目的计划，它是项目研发工作的基础。在有了总体研发计划之后，软件配置管理的活动就可以展开了，因为如 果不在项目开始之初制定软件配置管理计划，那么软件配置管理的许多关键活动就无法及时有效的进行，而它的直接后果就是造成了项目开发状况的混乱并注定软件 配置管理活动成为一种“救火”的行为。所以及时制定一份软件配置管理计划在一定程度上是项目成功的重要保证。

在“开发阶段和维护阶段”，软件配置管理活动主要分为三个层面，这三个层面是彼此之间既独立又互相联系的有机的整体。

（1） 主要由配置人员完成的管理和维护工作；

（2） 由系统集成员和开发人员具体执行软件配置管理策略；

（3） 变更流程。

10 配置管理部署模型

基本过程

相应操作文件

对应过程：2.2了解员工对配置管理的态度建立一个CHECKLIST，来进行调研，如下

对应过程：2.3了解组织的配置管理技术水平建立一个CHECKLIST，来进行调研，如下

对应过程：3.2评估配置工具供应商建立一个CHECKLIST，来进行调研，如下

对应过程：3.2评估配置工具供应商建立一个CHECKLIST，来进行调研，如下

对应过程：4.2制定新的过程1. 配置管理过程至少应当包括的内容：配置标示、配置控制、报告、审计2. 在考虑工具纳入配置过程中应当考虑下表内容

对应过程：6.1组建相应部门和团队负责配置管理部署和实施的团队必须包括

对应过程：6.2制定各个项目的实施计划计划应当包括的内容：

http://bbs.scmlife.com/thread-16353-1-1.html k/ o3 Y6 g) j" ^0 z2 E) o( v9 L5 O
我在做配置管理以前做过两年的测试，期间做过两家公司的iso 9000的内审员，然后老板觉得我比较有耐心，所以赶鸭子上架，和前任学习拉一周，我就是配置管理拉，然后不知不觉，已经6年拉，总结一下，看看会需要些什么呢？
1、软件公司的开发流程，对软件工程一定要熟悉，尤其是开发模型，你不能保证公司的所有项目使用一个模型。比如：瀑布、迭代或者极限编程。只有熟悉这些开发模型，你才能参与到公司的流程制定中去。
2、 熟悉一些标准，比如：iso 9000和cmmi。一个公司想要发展大，想要稳定，就一定会有一套稳定的流程。而熟悉标准，会更有利于你理解和说服你的同事。记得以前一个同事说过这样 一句话，一个公司想要长大，那一定必须是一头小象而不能是一只大蚂蚁。而一个做有流程，愿意将公司的事情流程化的公司才能保证不因人成事，才能长大。. @5 "9 E: Q( L0 j1 ~
3、沟通能力。配置管理员的工作就是沟通协助需求、开发及测试人员工作。而一个新的项目的建立意味这大家都是新人，来自不同的行业不同的公司，公司文化不 同，做事的方法也不同，你只有有好的沟通能力，才能说服项目经理支持你的工作，才只能说服开发测试人员按你要求的流程工作。
4、编程能力。想做好配置管理，你就不得不编写一些配置脚本，以方便开发测试人员，同时减少自己的工作量。
5、数据库知识。一般来说配置管理员，同时要管理BUG跟踪或需求管理的系统，那免不了老板会让你提供一些统计数据，所以数据库知识也是必不可少的。
6、系统知识。多说公司的配置管理员还要负责开发测试环境的维护，那么有系统知识，无疑可以减少你求助的机会。
现在说说我做过什么？& g! @2 `9 [: f+ ]5 g! z4 "/ f. q
一、上海项目的时候，只是负责系统的配置管理，包括代码编译，上线，这个系统比较大，但是还好，我是从别人手上接手的，所以还在顺序。
二、集团项目的的时候，我同时维护9个省的测试上线环境。
由于用户一直是用unix系统，所以顺便学会拉shell ，学会来在ibm，hp，sun的小型机上安装配置软件。
尤其是bes521的安装，简直是无言啊？宝 蓝从总部派人过来，现场安装，配置、测试，美国总部修改bug，然后打补丁，终于，我写了一本安装手册，两年后公司同事还在用。安装ibm的 websphere的时候，我发现需要打操作系统补丁，于是比较傻瓜的我，安装拉最新版的补丁，要命的是这个websphere比较变态，尽然只能用它指 定版本，所以到现在我都恨websphere啊。
要说最大的收获，就是在压力下面，我做事情很负责，我的努力让公司项目经理面对甲方也很硬气。! b  ^/ I7 E/ s" V
三、做公司的openboss系统。这个系统对我的锻炼很大，工作如下：/ d2 ?% d/ f1 K& d0 Y) I
1、写cvs脚本，保证代码能在提交的时候,同时建立开发和构建分支，同时不能是分支之上建立分支。
2、和一个没有任何配置管理经验的开发团队扯皮，扯开发流程，扯目录结构，扯Makefile模板，扯代码命名规范，然后想办法让他们执行。9 U1 J- G8 r0 ^2 D% i+ N6 Z
这个系统很大，到今天，已经有11个移动，3个网通，3个电信在使用。分出来的系统现在也有15个拉，仅仅营业和账务两个系统，unix后台就有500多个动态库，当时扯皮，现在受益。
3、和总工办 一起搞unix主机下的编译选项，由于用户的环境复杂，所以要求做到，代码写出来后，可以跨cpu，跨操作系统、跨中间件、跨数据库。所以这个过程让我对 unix下的编译器熟悉起来，不然无法做到。让我自豪的是到现在，开发人员只要修改Makefile模板很少的地方，就可以跨平台编译拉。
4、编写自动编译脚本。通过我们开发的自动编译系统，开发人员只要在浏览器中提交编译单就可以自动编译拉。而如果开始的时候，如果没有将目录规划好，我想自动编译就是无源之水。6 H& H1 ?% b; n5 N
这个系统我们web部分用jsp，unix用tcl/tk脚本。现在已经集成到QCS的源码管理中，还在改进，还在使用。7 r) H# K. ~- i6 r

四、公司的QCS系统（质量控制系统）。
这是一个配置管理系统，通过rsh将CVS和QCS结合在一起，用jsp和oracle的存储过程开发，其中包括：需求管理、功能点管理、任务管理、源码管理、bug管理、工程故障管理、接口管理、数据库变更管理、版本管理、发布管理、回退管理等模块的系统。2 z( T! {' a7 c* J: A0 v" M

五、参加公司的EPG小组，并且以配置管理员的身份参与评审。+ E* F) S  j( B' |# F# u  ^
公司两年前已经通过CMMI 5的认证。我加入公司的公司只是通过拉CMM 2级。后来由于甲方的要求，公司开始CMMI的认证。这中间有大量的文档要写。尤其是配置管理员，在几乎所有的过程中，都要参与评审，所以准备工作做拉好 久。到 CMMI 5级的时候，就要提供大量的统计数据来说明持续改进的结果，所以对QCS就需要不少地方做改动，来收集数据。还好公司一直注意这块，我们的各种脚本，模 板，都是尽量的优化以满足开发测试人员的需要。所以后来的评审中基本没有费什么事就过拉。* G6 J3 w5 "# z
( [" N- P( V% F4 "$ d, `
在这个项目中，让我对配置管理中的很多概念理解很深。尤其是在评审的时候，将自己平时做的工作用CMMI的语言讲解，感觉的确是锻炼人。
- a% k3 H% s/ Q5 S# ^, |+ T
这中间的很多事情，我的感谢我的师傅，虽然他比我年龄还小，而且也没有带我很久，但是很多问题都是和他讨论中加深理解的，不管是从技术上，还是为人都让我学之不尽啊。
1 h( "  C) "8 r  t- @7 C
要做好配置管理，一定要耐心、细心、恒心。
冰冻三尺非一日之寒。, H3 N' z: f+ I  y' V) K
* j; V, r: J* w, x; P9 p! ]
希望以上内容能给新入行的同行一点帮助。
原文：

原文：http://bbs.scmlife.com/thread-16603-1-1.html

一个项目想要成功，那配置管理的努力是必不可少的。如何做一个好的配置管理，同时减轻自己的负担，那就是一个值得认真思考的问题拉。+ Z, Z7 d1 W/ J/ e) Q0 A* O1 J# i+ X
一个产品想要实现持续集成及日创建，那么非得有一套好的自动编译系统支撑才可以，否则对于一个庞大的系统而言，一个配置管理就算累死也无法满足需求的。
下面以我的经验说说任何构建一个自动编译系统。
$ E( i$ {4 U: N
为了更好的自动编译，我想应该建立一个这样的系统，那就是：
1、开发人员或定时触发。
2、自动更新编译环境。- P$ e; s  `% ^" c* U2 A0 L
3、自动编译。
( b: C$ m* F  t: W9 w  l4、自动分析编译结果。. U5 A! [6 X4 h6 Z2 ]+ |4 V9 v
5、自动通知开发、测试及配置管理员。$ C+ ~9 h& D! y4 m" c% d

下面我假设情况如下：
1、操作系统：平台包括：HP-UX、SunOS、AIX、Linux 、Windows （均包括多个版本）、。  M! c$ t9 ": k
2、数据库包括：oracle 8i、9i、10G
3、编译器包括：aCC、CC、xlC、gcc、bcb(windows 上的集成开发环境) 、java（包括多个版本）/ R" N3 J* F$ "% L- R, D' b
4、项目规模超过千万行代码、模块众多、调用复杂。# H! A# y: "8 J% f7 C, G! j" `( E
那么在这样一个情况下，如果我们考虑用一般的商用工具做，显然成本是很高的。0 y; l( I* Y: x
对于这样一个庞大，复杂的系统，我想在项目启动后，首先要做的是：
1、定义编码规范。0 L# S* D9 |' y2 @3 @1 G  h
2、定义C++及java的编译选项（由于C++语言中编译器及平台版本不同，32、64位要求及数据库的版本等不同要求，所以编译选项显然要提取出来单独处理）。
3、定义Makefile 规范。
4、定义模块目录结构。
5、定义接口提供方式。
4 C( J  w$ v1 n* _  {, {+ m在定义以上内容的时 候，一定要遵循一个原则，符合命名规范、尽量可配置、易懂、易于理解。最后组合出的编译命令的字符串不要太长（unix操作系统下，不同版本的shell 对一个命令的长度有不同要求、同时由于Makefile中如果有很多shell 脚本的话，编译性能也会受影响）。3 U& P* h8 Q6 x& A8 E+ P
在我用过的系统中，make 工具，unix 平台我们使用的是 GNU make 版本3.80，java 用的是 ant，windows 平台C++用的是bcb 自带的make，不过在编译前先要将bcb的工程文件bpr文件转换为Makefile文件，使用的工具是bpr2make（之所以不用bcb直接编译， 主要是为拉自动编译，自动分发编译结果）。
2 [3 `" W; x% d- O
为了更好的跟踪代码及需求、bug变更情况，自动编译系统，应该从开发人员提交代码开始，到发布结束。( W- J% J4 O4 O/ E, a" m% s
流程如下：( V+ t: ~4 G+ }3 V* e' H; G8 ": k
1、开发人员提交代码。
2、编译脚本触发，从版本库更新代码到编译服务器。
3、设置编译需要的环境变量。
4、构造编译需要的Makefile。6 z% i( G5 ~. U2 l( q# I3 ^+ z9 ~
5、执行编译。
6、分析编译结果、记录编译结果。* N2 |9 P5 d% i: N. L
7、发邮件通知开发、配置管理、测试人员等相关人。# k5 |$ u9 ]2 `1 L2 ]0 I
8、更新到测试环境测试。  t, {9 D4 y3 ?7 v( Y5 q8 H- @
9、配置管理员发布。
2 ]2 b# _: ]5 q5 S# G! S* F
下面我以cvs或svn为源码版本库做作说明，需要写一些适当的脚本，并且需要数据库的配合才能工作的比较顺利。
1、建议用户表
( z  q  O: |- F0 R6 r2、在数据库中建立产品表。
3、在数据库中建立模块表（需要记录模块优先级、模块路径、Makefile 文件的名称等功能）。/ w* n9 y' D3 y3 R( L3 u9 x
4、建立需求表、任务单表、bug表、编译记录表。, s' t5 N4 m5 L& t) N- Q* X* [
5、编写代码提交脚本。实现提交代码的同时，在编译记录表中增加记录，并关联需求单、任务单、BUG单功能。3 O+ N0 n3 e2 p' f
6、编写自动编译脚本。实现定时查询数据库，根据编译单，进行编译的功能。需要实现，获取编译单后，自动生成编译环境所需的环境变量，构造编译用 Makefile，更新待编译代码，编译完成后分析编译结果，给被编译代码打tag，获取编译结果的特征串，然后记录到数据库中，并发邮件通知开发人员、 测试人员及配置管理人员。

如果以上脚本实现，那么，不管你是要日创建还是随时编译，还是全系统编译，都是轻松的事情拉。
虽然windows 平台和unix 平台差别很大，c++和java的差异也很大，但是如果大家将以上要求都用函数实现。我想迁移还是很方便的。1 t" v+ t  U' U* `" N% ~. L
尤其是脚本语言，多数是支持跨平台的。
2 _* W: V3 t/ Q0 _0 C' q/ k" @) j) T& m这里主要可能碰到的问题是。7 r8 O- u! R2 t6 B% @
1、模块结构规划不合理。
: ?# j  z: ?' |* g. |0 w. T* E9 n  m2、公共调用文件的安装问题。
3、模块编译顺序的问题。对于复杂的系统，那么调用关系就决定了编译顺序，可能要多次调整。
4、编译结果的安装问题。最好是编译完成通知测试人员，让他们自己安装。否则你自动杀掉他们正在测试的进程，他们会找你算账的。( k/ |( ?$ e' {$ T: q
5、编译结果的分析问题。编译结果的分析就需要自己写正则表达式来分析日志了，级联编译中是无法通过失败信号获取编译失败的，只能分析日志。
6、邮件发送问题。unix 平台，配置好DNS和sendmail就好啦，windows平台，如果没有找到你所用脚本语言的邮件发送函数，那么你就的自己用telnet 加 smtp 协议实现拉。- h5 F! e" h1 R3 N% F5 e

6 `! g" j" Q- l$ f, U8 ^) W0 @# y# y可能有人奇怪我为什么要设计一个数据出来，我想如果有数据库的话，方便维护人员根据编译目标文件的特征串，查找出，这是那一次编译的，生成他的源码有那些，具体版本是什么。/ n3 i& _+ p9 n5 N) V& D  w
同时也可以查找出是为那个需求或BUG而修改代码的，修改了那些地方等。同时也可以通过数据库统计，分析出，模块代码的变更情况和工作量，进度等。8 W/ |; s& w& x* v( |
同时也可以分析出那些人老是提交错，经常容易犯那些错误，编译流程改进，作为cmmi 5级的数据提供。1 P/ e5 r$ D8 u0 j7 x' q' R0 ?
拉拉杂杂写啦一大堆，希望对大家有用。

看到论坛里面有很多人询问，工具的选择和使用问题。个人建议：如果没有采购的想法。那么我建议使用SVN做版本管理工具。理由如下：
一、SVN的开发团队就是当初CVS的开发团队。( q3 "9 K- W( V" O* i/ n/ S" D
1、正式由于CVS的很多缺陷，所以才放弃CVS，改开发SVN的。
2、CVS以后只会修改BUG，不会在出新功能拉。
3、CVS的权限功能很不完全，犹如鸡肋。
二、SVN相对于CVS有很多优点。) o+ p; C1 M3 f
SVN的优点如下：
1、天然支持web。SVN服务器是可以和apache集成的，所以天然就支持HTTP协议，就可以通过互联网访问，同时可以使用apache的权限系统。而CVS只能通过CVSWEB来通过浏览器访问。4 ^1 h3 V2 ]0 P( Z# [  q, `; "$ q
2、SVN支持文件的移动，支持文件的改名，支持目录版本。
3、SVN提供拉API，提供拉各种语言的开发库，这个是CVS所不支持的。CVS的二次开发，只能通过命令行的方式做脚本，否则你就要在CVS的C代码中做接口，才能增加或修改功能。
4、SVN便于和自己开发的配置管理工具集成。原因如上。8 |3 g7 P  o/ _
5、SVN可以通过LDAP和公司的域结合起来，实现单点认证。
三、相对于CVS和SVN，VSS有几个个很大的缺点。
1、VSS是基于CHECKOUT、锁模式的，而SVN和CVS及基于CHECKOUT、合并模式的。后者显然更适合协同开发，适合多人修改同一份代码。而且作为配置管理员，也不用疲于奔命的去删除锁。
2、VSS只支持windows平台，而CVS和SVN是跨平台的。也许一时无所谓，但是如果有一天公司转向类unix平台，你就得迁移配置库，重新编写使用手册，并且做培训，为什么不把问题消灭在萌芽状态呢。* }0 x4 `" `4 e2 `7 Q5 `% _
3、VSS是要共享目录以便访问。这样在网络病毒猖獗的日子里，你就和病毒做斗争去吧。同时代码安全和是一个大问题啊。
4、VSS是不支持web访问的。9 V5 b: _" E1 U# ?1 X" o
5、权限配置也不够友好。" S. y$ J, X8

我想如果看过《Git历险记》的前面三篇文章的朋友可能已经知道怎么用git add，git commit这两个命令了；知道它们一个是把文件暂存到索引中为下一次提交做准备，一个创建新的提交（commit）。但是它们台前幕后的一些有趣的细节大家不一定知晓，请允许我一一道来。

Git 索引是一个在你的工作目录（working tree）和项目仓库间的暂存区域(staging area)。有了它, 你可以把许多内容的修改一起提交(commit)。 如果你创建了一个提交(commit)，那么提交的一般是暂存区里的内容, 而不是工作目录中的内容。

一个Git项目中文件的状态大概分成下面的两大类，而第二大类又分为三小类：

1. 未被跟踪的文件（untracked file）
2. 已被跟踪的文件（tracked file）
   1. 被修改但未被暂存的文件（changed but not updated或modified）
   2. 已暂存可以被提交的文件（changes to be committed 或staged）
   3. 自上次提交以来，未修改的文件(clean 或 unmodified)

看到上面的这么多的规则，大家早就头大了吧。老办法，我们建一个Git测试项目来试验一下：

我们先来建一个空的项目：

$rm -rf stage_proj

$mkdir stage_proj

$cd stage_proj

$git init

Initialized empty Git repository in /home/test/work/test_stage_proj/.git/

我们还创建一个内容是“hello, world”的文件：

$echo "hello,world" > readme.txt

现在来看一下当前工作目录的状态，大家可以看到“readme.txt”处于未被跟踪的状态（untracked file）：

$git status

# On branch master

#

# Initial commit

#

# Untracked files:

#   (use "git add <file>..." to include in what will be committed)

#

#   readme.txt

nothing added to commit but untracked files present (use "git add" to track)

把“readme.txt"加到暂存区： $git add readme.txt

现在再看一下当前工作目录的状态：

$git status

# On branch master

#

# Initial commit

#

# Changes to be committed:

#   (use "git rm --cached <file>..." to unstage)

#

#   new file:   readme.txt

#

可以看到现在"readme.txt"的状态变成了已暂存可以被提交（changes to be committed），这意味着我们下一步可以直接执行“git commit“把这个文件提交到本地的仓库里去了。

暂存区（staging area）一般存放在“git目录“下的index文件（.git/index）中，所以我们把暂存区有时也叫作索引（index）。索引是一个二进制格 式的文件，里面存放了与当前暂存内容相关的信息，包括暂存的文件名、文件内容的SHA1哈希串值和文件访问权限，整个索引文件的内容以暂存的文件名进行排 序保存的。

但是我不想马上就把文件提交，我想看一下暂存区（staging area）里的内容，我们执行git ls-files命令看一下：

$git ls-files --stage

100644 2d832d9044c698081e59c322d5a2a459da546469 0   readme.txt

我们如果有看过上一篇文章里 的"庖丁解牛", 你会发现“git目录“里多出了”.git/objects/2d/832d9044c698081e59c322d5a2a459da546469”这 么一个文件，再执行“git cat-file -p 2d832d” 的话，就可以看到里面的内容正是“hello,world"。Git在把一个文件添加暂存区时，不但把它在索引文件(.git/index)里挂了号，而 且把它的内容先保存到了“git目录“里面去了。

如果我们执行”git add“命令时不小心把不需要的文件也加入到暂存区中话，可以执行“git rm --cached filename" 来把误添加的文件从暂存区中移除。

现在我们先在"readme.txt"文件上做一些修改后：

$echo "hello,world2" >> readme.txt

再来看一下暂存区的变化:

$git status

# On branch master

#

# Initial commit

#

# Changes to be committed:

#   (use "git rm --cached <file>..." to unstage)

#

#   new file:   readme.txt

#

# Changed but not updated:

#   (use "git add <file>..." to update what will be committed)

#   (use "git checkout -- <file>..." to discard changes in working directory)

#

#   modified:   readme.txt

#

大家可以看到命令输出里多了一块内容：“changed but not updated ...... modified: readme.txt”。大家可能会觉得很奇怪，我前面不是把"readme.txt"这个文件给添加到暂存区里去了吗，这里怎么又提示我未添加到暂存区 （changed but not updated）呢，是不是Git搞错了呀。

Git 没有错，每次执行“git add”添加文件到暂存区时，它都会把文件内容进行SHA1哈希运算，在索引文件中新加一项，再把文件内容存放到本地的“git目录“里。如果在上次执行 “git add”之后再对文件的内容进行了修改，那么在执行“git status”命令时，Git会对文件内容进行SHA1哈希运算就会发现文件又被修改了，这时“readme.txt“就同时呈现了两个状态：被修改但未 被暂存的文件（changed but not updated），已暂存可以被提交的文件（changes to be committed）。如果我们这时提交的话，就是只会提交第一次“git add"所以暂存的文件内容。

我现在对于“hello,world2"的这个修改不是很满意，想要撤消这个修改，可以执行git checkout这个命令：

$git checkout -- readme.txt

现在再来看一下仓库里工作目录的状态：

$git status

# On branch master

#

# Initial commit

#

# Changes to be committed:

#   (use "git rm --cached <file>..." to unstage)

#

#   new file:   readme.txt

#

好的，现在项目恢复到我想要的状态了，下面我就用git commit 命令把这个修改提交了吧：

$git commit -m "project init"

[master (root-commit) 6cdae57] project init   1 files changed, 1 insertions(+), 0 deletions(-)    create mode 100644 readme.txt

现在我们再来看一下工作目录的状态：

$git status

# On branch master

nothing to commit (working directory clean)

大家可以看到“nothing to commit (working directory clean)”；如果一个工作树（working tree）中所有的修改都已提交到了当前分支里（current head），那么就说它是干净的（clean），反之它就是脏的(dirty)。

SHA1值内容寻址

正如Git is the next Unix 一文中所说的一样，Git是一种全新的使用数据的方式（Git is a totally new way to operate on data）。Git把它所管理的所有对象（blob，tree，commit，tag……），全部根据它们的内容生成SHA1哈希串值作为对象名；根据目 前的数学知识，如果两块数据的SHA1哈希串值相等，那么我们就可以认为这两块数据是相同 的。这样会带来的几个好处：

1. Git只要比较对象名，就可以很快的判断两个对象的内容是否相同。
2. 因为在每个仓库（repository）的“对象名”的计算方法都完全一样，如果同样的内容存在两个不同的仓库中，就会存在相同的“对象名”。
3. Git还可以通过检查对象内容的SHA1的哈希值和“对象名”是否匹配，来判断对象内容是否正确。

我们通过下面的例子，来验证上面所说的是否属实。现在创建一个和“readme.txt“内容完全相同的文件”readme2.txt“，然后再把它提交到本地仓库中：

$echo "hello,world" > readme2.txt

$git add readme2.txt

$git commit -m "add new file: readme2.txt"

[master 6200c2c] add new file: readme2.txt

1 files changed, 1 insertions(+), 0 deletions(-)

create mode 100644 readme2.txt

下面的这条很复杂的命令是查看当前的提交（HEAD）所包含的blob对象：

$git cat-file -p HEAD | head -n 1 | cut -b6-15 | xargs git cat-file -p

100644 blob 2d832d9044c698081e59c322d5a2a459da546469    readme.txt

100644 blob 2d832d9044c698081e59c322d5a2a459da546469    readme2.txt

我们再来看看上一次提交（HEAD^）所包含的blob对象：

$git cat-file -p HEAD^ | head -n 1 | cut -b6-15 | xargs git cat-file -p

100644 blob 2d832d9044c698081e59c322d5a2a459da546469    readme.txt

很明显大家看到尽管当前的提交比前一次多了一个文件，但是它们之间却是在共用同一个blob对象：“2d832d9”。

No delta, just snapshot

Git 与大部分你熟悉的版本控制系统，如Subversion、CVS、Perforce 之间的差别是很大的。传统系统使用的是： “增量文件系统” （Delta Storage systems），它们存储是每次提交之间的差异。而Git正好与之相反，它是保存的是每次提交的完整内容（snapshot）；它会在提交前根据要提交 的内容求SHA1哈希串值作为对象名，看仓库内是否有相同的对象，如果没有就将在“.git/objects"目录创建对应的对象，如果有就会重用已有的 对象，以节约空间。

下面我们来试验一下Git是否真的是以“snapshot”方式保存提交的内容。

先修改一下"readme.txt"，给里面加点内容，再把它暂存，最后提交到本地仓库中：

$echo "hello,world2" >> readme.txt

$git add readme.txt

$git commit -m "add new content for readme.txt"

[master c26c2e7] add new content for readme.txt   1 files changed, 1 insertions(+), 0 deletions(-)

我们现在看看当前版本所包含的blob对象有哪些：

$git cat-file -p HEAD | head -n 1 | cut -b6-15 | xargs git cat-file -p

100644 blob 2e4e85a61968db0c9ac294f76de70575a62822e1    readme.txt

100644 blob 2d832d9044c698081e59c322d5a2a459da546469    readme2.txt

从上面的命令输出，我们可以看到"readme.txt"已经对应了一个新的blob对象：“2e4e85a”，而之前版本的"readme.txt“对应的blob对象是：“2d832d9”。下面我们再来看一看这两个”blob“里面的内容和我们的预期是否相同：

$git cat-file -p 2e4e85a

hello,world

hello,world2

$git cat-file -p 2d832d9

hello,world

大家可以看到，每一次提交的文件内容还是全部保存的（snapshot）。

小结

Git内在机制和其它传统的版本控制系统（VCS）间存在本质的差异，所以Git的里"add"操作的含义和其它VCS存在差别也不足为奇，“git add“不但能把未跟踪的文件（untracked file）添加到版本控制之下，也可以把修改了的文章暂存到索引中。

同时，由于采用“SHA1哈希串值内容寻值“和”快照存储（snapshot）“，让Git成为一个速度非常非常快的版本控制系统（VCS）。

参考

• GitCommunityBook 中文版
• ProGit 中文版

致谢

感谢上帝对我的眷顾，让我可以有写作专栏的这样一个机会。

感谢朋友们在写作过程的无私帮助：张凯峰，刘炜，许晓斌，Fenng……

特别要感謝家人默默支持：）

原文：http://www.infoq.com/cn/news/2011/03/git-adventures-index-commit

如果我们要把一个项目加入到Git的版本管理中，可以在项目所在的目录用git init命令建立一个空的本地仓库，然后再用git add命令把它们都加入到Git本地仓库的暂存区（stage or index）中，最后再用git commit命令提交到本地仓库里。

创建一个新的项目目录，并生成一些简单的文件内容：

$ mkdir test_proj

$ cd test_proj

$ echo “hello,world” > readme.txt

在项目目录创建新的本地仓库，并把项目里的所有文件全部添加、提交到本地仓库中去：

$ git init #在当前的目录下创建一个新的空的本地仓库

Initialized empty Git repository in /home/user/test_proj/.git/

$ git add . #把前目录下的所有文件全部添加到暂存区

$ git commit -m 'project init' #创建提交

[master (root-commit) b36a785] project init

1 files changed, 1 insertions(+), 0 deletions(-)

create mode 100644 readme.txt

Git目录的结构

git init命令在项目的顶层目录中建了一个名为：“.git”的目录，它的别名是 “Git目录”（Git directory）。这时”Git目录”中虽然有一些文件，但是没有任何提交（commit）在里面，所以我们叫它是空仓库（empty Git repository）。

和 SVN不同，一个Git项目一般只在项目的根目录下建一个“.git”目录，而SVN则会在项目的每一个目录下建一个”.svn”目录；这也我喜欢Git的原因之一：）

Git把所有的历史提交信息全部存储在“Git目录”里，它就是一个Git项目的仓库；你对本地的源代码进行编辑修改后创建的提交也都会先保存在这 里面，然后再推送到远端的服务器。当我们我把项目目录和“Git目录”一起拷到其它电脑里，它能马上正常的工作（所有的提交信息全都保存在Git目录 里）；甚至可以只把“Git目录”拷走也行，但是要再签出（checkout）一次。

Git为了 调试的方便，它可以指定项目的Git目录的位置。有两种办法：一是设置“GIT_DIR”环境变量，二是在命令行里设定“--git-dir--git-dir”参数指定它的位置，大家可以看一下这里(git(1) Manual Page)。

庖丁解牛

前面的这些东东我在第一篇里也大概的讲过一些，但是今天我们想不但要开动这辆叫“Git”的跑车，还想看看它里面有些什么样的零件，是怎么构成的。

OK，我们来看看“test_proj”项目里的“Git目录”的结构：

$cd test_proj/.git

$ ls | more

branches/ # 新版的Git已经不再使用这个目录，所以大家看到它 #一般会是空的

COMMIT_EDITMSG # 保存着上一次提交时的注释信息

config # 项目的配置信息

description # 项目的描述信息

HEAD # 项目当前在哪个分支的信息

hooks/ # 默认的“hooks” 脚本文件

index # 索引文件，git add 后把要添加的项暂存到这里

info/ # 里面有一个exclude文件，指定本项目要忽略的文件 #，看一下这里

logs/ # 各个refs的历史信息

objects/ # 这个目录非常重要，里面存储都是Git的数据对象

# 包括：提交(commits), 树对象(trees)，二进制对象 #（blobs）,标签对象（tags）。

#不明白没有关系，后面会讲的。

refs/ # 标识着你的每个分支指向哪个提交（commit）。

我先用git log命令来看一下这个Git项目里有哪些提交：

$ git log

commit 58b53cfe12a9625865159b6fcf2738b2f6774844

Author: liuhui998 <liuhui998@nospam.com>

Date: Sat Feb 19 18:10:08 2011 +0800

project init

大家可以看到目前只有一个提交（commit）对象，而它的名字就 是：”58b53cfe12a9625865159b6fcf2738b2f6774844”。这个名字就是对象内容的一个SHA签名串值，只要对象里面 的内容不同，那么我们就可以认为对象的名字不会相同，反之也成立。我在使用时一般不用把这个40个字符输全，只要把前面的5~8个字符输完就可以（前提是 和其它的对象名不冲突）。为了方便表示，在不影响表达的情况下，我会只写SHA串值的前6个字符。

我们可以用git cat-file来看一下这个提交里的内容是什么:

$ git cat-file -p 58b53c

tree 2bb9f0c9dc5caa1fb10f9e0ccbb3a7003c8a0e13

author liuhui998 <liuhui998@nospam.com> 1298110208 +0800

committer liuhui998 <liuhui998@nospam.com> 1298110208 +0800

project init

大家可以看到：提交“58b53c” 是引用一个名为“2bb9f0”的树对象（tree）。一个树对象（tree）可以引用一个或多个二进制对象（blob）, 每个二进制对象都对应一个文件。 更进一步, 树对象也可以引用其他的树对象，从而构成一个目录层次结构。我们再看一下这个树对象（tree）里面有什么东东：

$ git cat-file -p 2bb9f0

100644 blob 2d832d9044c698081e59c322d5a2a459da546469 readme.txt

不难看出，2bb9f0”这个树对象（tree）包括了了一个二进制对象（blob），对应于我们在前面创建的那个叫 ”readme.txt”的文件。现在我们来看看这个”blob”里的数据是不是和前面的提交的内容一致：

$ git cat-file -p 2d832d

hello,world

哈哈，熟悉的“hello,world”又回来了。

想不想看看提交对象、树对象和二进制对象是怎么在”Git目录“中存储的；没有问题，执行下面的命令，看看”.git/objects”目录里的内容：

$ find .git/objects

.git/objects

.git/objects/2b

.git/objects/2b/b9f0c9dc5caa1fb10f9e0ccbb3a7003c8a0e13

.git/objects/2d

.git/objects/2d/832d9044c698081e59c322d5a2a459da546469

.git/objects/58

.git/objects/58/b53cfe12a9625865159b6fcf2738b2f6774844

.git/objects/info

.git/objects/pack

如果大家仔细看上面命令执行结果中的粗体字，所有的对象都使用SHA签名串值作为索引存储在”.git/objects”目录之下；SHA串的前两个字符作为目录名，后面的38个字符作为文件名。

这些文件的内容其实是压缩的数据外加一个标注类型和长度的头。类型可以是提交对象（commit）、二进制对象（blob）、 树对象（tree）或者标签对象（tag）。

如何clone一个远程项目

我身边的很多朋友是因为要得到某个开源项目的代码，所以才开始学习使用Git。而获取一个项目的代码的一般的做法就是用git clone命令进行直接复制。

例如，有些朋友可能想看一下最新的linux内核源代码，当我们打开它的网站时，发现有如下面的一段提示：

URL

git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

URL下面的三行字符串表示三个地址，我们可以通过这三个地址得到同样的一份Linux内核源代码。

也就是说下面这三条命令最终得到的是同一份源代码：

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

git clone http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

git cone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

我们先来看一下URL，git://、http://、https://这些代表是传输git仓库的协议形式，而“git.kernel.org“则代表了Git仓库存储的服务器名字（域名），“/pub/scm/linux/kernel/git/torvalds/linux-2.6.git” 则代表了Git仓库在服务器上位置。

Git 仓库除了可以通过上面的git、http、https协议传输外还可以通过ssh、ftp(s)、rsync等协议来传输。git clone的本质就是把“Git目录”里面的内容拷贝过来，大家想想看，一般的“Git目录”里有成千上万的各种对象（提交对象，树对象，二进制对象......)，如果逐一复制的话，其效率就可想而知。

如果通过git、ssh协议传输，服务器端会在传输前把需要传输的各种对象先打好包再进行传输；而http（s）协议则会反复请求要传输的不同对 象。如果仓库里面的提交不多的话，前者和后者的效率相差不多；但是若仓库里有很多提交的话，git、ssh协议进行传输则会更有效率。

不过现在Git对http（s）协议传输Git仓库做了一定的优化，http（s）传输现在也能达到ssh协议的效率，有兴趣的朋友可以看一下这里（Smart HTTP Transport）。

好的，现在我们执行了下面这条命令，把linux-2.6的最新版源代码clone下来：

$cd ~/

$mkdir temp

$git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

Initialized empty Git repository in /home/liuhui/temp/linux-2.6/.git/

remote: Counting objects: 1889189, done.

remote: Compressing objects: 100% (303141/303141), done.

Receiving objects: 100% (1889189/1889189), 385.03 MiB | 1.64 MiB/s, done.

remote: Total 1889189 (delta 1570491), reused 1887756 (delta 1569178)

Resolving deltas: 100% (1570491/1570491), done.

Checking out files: 100% (35867/35867), done.

当我们执行了“git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git”这条命令后大家可以看到这条输出：

Initialized empty Git repository in /home/user/temp/linux-2.6/.git/

这就是意味着我们在本地先建了一个“linux-2.6”目录，然后在这个目录建了一个空的Git本地仓库（Git目录）；里面将会存储从网上拉下来的历史提交。

下面两条输入代表服务器现在调用 git-pack-objects 对它的仓库进行打包和压缩：

remote: Counting objects: 1888686, done.

remote: Compressing objects: 100% (302932/302932), done.

然后客户端接收服务器端发过送过来的数据：

Receiving objects: 100% (1889189/1889189), 385.03 MiB | 1.64 MiB/s, done.

在我们执行完上面的clone linux-2.6代码的的操作后，Git会从“Git目录”里把最新的代码到签出（checkout）到“linux-2.6”这个目录里面。我们一般 把本地的“linux-2.6”这个目录叫做”工作目录“（work directory），它里面保存着你从其它地方clone（or checkout）过来的代码。当你在项目的不同分支间切换时，“工作目录”中的文件可能会被替换或者删除；“工作目录”只是保存着当前的工作，你可以修 改里面文件的内容直到下次提交为止。

大家还记得前面的“庖丁解牛”吗，是不是觉得只杀一头叫“hello,world”的小牛太不过瘾了。没有问题，拿起前面的那把小刀，来剖析一下现在躺在你硬盘里这头叫“linux-2.6”大牛看看，我想一定很好玩。

在写篇文章的过程中，我要感谢在那些关心我并提出真诚意见的朋友，如果没有你们真诚的意见，我也许没有这么强烈的紧迫感，也不会深深的感到自己的不足。我是第一次写专栏，张凯锋同学给了我很大的帮助。最后还是要感谢我的家人，是他们让我有时间来进行写作：）

原文：http://www.infoq.com/cn/news/2011/02/git-adventures-local-repository

从这一篇开始，我就将比较“啰嗦”的和大家一起从零开始经历Git使用的每一步，当然对我而言这也是一个重新认识Git的过程。

使用Git的第一步肯定是安装Git，因为在多数平台上Git是没有预装的。我平时主要的工作环境是windows和Linux（ubuntu），我想看这篇文章的同学多半也是在这两个平台下工作；下面我讲一下如何在这两个平台下安装和配置Git。

BTW:如果是苹果平台的用户的安装可以参看一下这里(1,2)，配置和命令行的使用与windows、Linux（*nix）平台差别不大。

Linux (*nix) 平台

Linus开发Git的最初目的就是为了开发Linux内核服务的，自然它对Linux的平台支持也是最棒的。在Linux下安装Git大约有几种方法：

从源代码开始(这种方法也适合于多数*nix平台)

从Git官网的下载页面下载它最新稳定版的源代码，就可以从源代码开始编译、安装：

$ wget http://kernel.org/pub/software/scm/git/git-1.7.3.5.tar.bz2

$ tar -xjvf git-1.7.3.5.tar.bz2

$ cd git-1.7.3.5

$ make prefix=/usr all ;# prefix设置你的Git安装目录

$ sudo make prefix=/usr install ;# 以root权限运行

为了编译Git的源代码，我们还需要一些库: expat、curl、 zlib 和 openssl； 除了expat 外，其它的库可能在你的机器上都安装了。

使用安装包管理器（apt 或 yum）

在 fedora 等系统下用yum ：

$ yum install git-core 

在debian, ubuntu等系统下用apt ：

$ apt-get install git-core

有时候，你系统里的安装包管理器出现了问题，或是要安装Git的机器不能上网、没有编译器的话，你可以从下面的站点去下载 “.deb” 或 “.rpm”的安装包：

• RPM Packages
• Stable Debs

Windows平台

windows平台有两个模拟*nix like运行环境的工具：cygwin，msys；Git在cygwin，msys下都有相应的移植版本。我个人觉得msys平台下的msysGit最好用，现在我在windows下也是用的这个版本。

很多同学可能要问，现在windows下有那多Git用户，为什么Git不直接出一个windows native版。俺当年翻看了一下Git的源代码，它里面使用了大量的*nix平台的native api，而这些api在windows下是没有的，所以必须要用cygwin、msys这样的一个中间层来满足软件移植的要求。

下面我“啰嗦”一下如何在windows下安装msysGit。

下载

到它的下载页面去下载一个最新的完整安装包，笔者在撰写本文时下载的是这个。

安装

安装的过程没有什么好说的，一般是开始安装后，一路的点击“下一步”。由于windows平台的换行符（CRLF）和Linux(*nix)平台的换行符（LF）不同，那么在windows下开发其它平台软件的朋友有一个地方要注意（见下图)：

在这里一最好选“Checkout as-is, commit as-is”这个选项，这样，Git就不会修改你代码的换行符风格。

以前有个朋友因为选错了这个选项，以致他在windows平台下的一签出（checkout）其它平台的代码，就会显示”已修改“（modified），不过后来可能msysGit也认识到这个问题了，就把默认选项改成了这个选项。

BTW: 其实前面两项也是有用的，如果对windows和Linux(*nix)平台如何处理换行符很熟悉的话，也可以尝试一下前面两个选项：）

配置Git

在Linux下和windows下配置Git的方法差不多，只是在Linux下，可以在命令行里直接使用git config进行配置, 而在windows下则要先打开“Git Bash”，进入msysGit命令行界面，再用git config命令进行相应的配置操作。

好了，前面安装好了Git，现在我们开始配置：

第一个需要配置的就是用户的用户名和email，因为这些内容会出现在你的每一个提交（commit）里面的，像下面这样：

$ git log #我们用git log查看当前仓库的提交（commit）日志

commit 71948005382ff8e02dd8d5e8d2b4834428eece24

Author: author <author@corpmail.com>

Date: Thu Jan 20 12:58:05 2011 +0800

Project init

下面的这两行命令就是设置用户名和email：

$ git config --global user.name author #将用户名设为author

$ git config --global user.email author@corpmail.com #将用户邮箱设为author@corpmail.com

Git的配置信息分为全局和项目两种，上面命令中带了“--global"参数，这就意味是在进行全局配置，它会影响本机上的每个一个Git项目。

大家看到，上面我们用的是@corpmail（公司邮箱）；但是有时候我们可能也参与了一些开源项目，那么就需要新的用户名和自己的私人邮箱，Git 可以为每个项目设定不同的配置信息。

在命令行环境，进入Git项目所在目录，执行下面的命令：

$ git config　user.name nickname#将用户名设为nickname

$ git config　user.email nickname@gmail.com #将用户邮箱设为nickname@gmail.com

Git的设计哲学和Linux（*nix）一样，尽量的使用“文本化”（Textuality）；它里面尽量用文本化的形式存储信息，对于配置信息也更是如此，用户的这些配置信息全部是存储在文本文件中。Git的全局配置文件是存放在"~/.gitconfig"（用户目录下的.gitconfig）文件中：

我们用cat、head命令查看全局配置信息文件，并假设相关配置信息存储在文件的前3行（当然也有可能不在前3行，这里只是为了方便表示）

$ cat ~/.gitconfig | head -3 

[user]

name = author

email = author@corpmail.com

而项目配置文件是存放在Git项目所在目录的".git/config"文件中，这里也像上面一样用cat、head命令查看一下：

$ cat .git/config | head -3

[user]

name = nickname

如果大家对于Git熟悉后，可以直修改”~/.gitconfig”,”.git/config”这两个文件进行配置。

Git里还有很多可以配置的地方，大家可以参考一下git config 和 定制git。

这一篇写起来有点平淡无奇，但这是一个Git用户迈出的第一步。后面我还会有一系列的文章出来，都是我个人使用过程中的感悟。

有朋友问我：“为什么把文章叫作：‘Git历险记’”。这是因为在使用Git的历程中，我碰到过N多的问题；同时也觉得它有点小复杂。但是当这些问题解开后，就有时不得不赞叹它设计的巧妙之处。

如果大家对于我的文章有什么问题和建议，欢迎给我写邮件：

之前我建立了一个 git中文用户组 ，如果大家在使用Git的过程中碰到什么麻烦事，欢迎你在这个用户组里提问。

参考资料：

• GitCommunityBook 中文版
• ProGit 中文版
• git config

感谢张凯峰对本文的策划及无比耐心的审校。

感谢家人在我的写作过程中的默默支持。

原文：http://www.infoq.com/cn/news/2011/01/git-adventures-install-config

email = nickname@gmail.com