| 编辑推荐: |
| 本文来自于博客园,文中ant和svn的持续集成环境搭建的图文详解，部署流程及jenkins服务的管理介绍较为详细。 |
|
持续集成的前身：
在使用持续集成之前，很多开发团队都是用每日构建(nightly build)。当时，微软使用这个实践很多年了。谁破坏了构建，就要负责监视后续的构建构成，直至发现下一个破坏了构建的人。
为什么要使用持续集成？
对于大多数项目来说，采纳持续集成实践是向高效率和高质量迈进的一大步。它保证那些创建大型复杂系统的团队具有高度的自信心和控制力。一旦代码提交引入了问题，持续集成就能为我们提供快速的反馈，从而确保我们作为一个团队所开发的软件是可以工作的。
持续集成的主要关注对象是开发团队。持续集成系统的输出通常作为手工测试流程和后续发布流程的输入。在软件的发布过程中，很多浪费来自于测试和运维环节。
例如：我们常常看到：
1.构建和运维团队的人员一直在等待说明文档或缺陷修复
2.测试人员等待"好的"版本构建出来
3.在新功能开发完成一段时间后，才收到缺陷报告
4.开发完成时，才发现当前的软件架构无法满足该系统的一些非功能需求
持续集成的一些实践：
采取一种更完整的端到端的方法来交付软件。我们通过一键式方式把软件的某个版本部署好，甚至可以将其一键式部署到生成环境中，这样就可以建立了一个非常有效的反馈环--由于很容易将应用程序部署到测试环境中，所以团队可以同时得到软件功能和部署流程两个方面的快速反馈。因为部署流程(无论是测试，集成)都是自动化的，所以可以频繁且有规律的运行并被测试，从而降低发布风险，也降低了向开发团队传递有关部署流程的知识时的风险。
从精益的角度来看，我们实现了一个"拉式系统"，测试团队只要自己单击按钮，就能轻松部署。管理人员也能容易得到一些关键的度量指标，比如周期时间，吞吐量以及代码质量。
持续集成主要内容包括：
1.将软件构建、集成、测试和部署全面实现自动化
2.在团队和组织级别实现部署流水线
3.改进开发人元、测试人员和运维人员间的协作
4.在大型分布式团队中增量并发开发软件功能
5.实施高效的配置管理策略
6.分析并实现自动化验收测试
7.容量测试和其他非功能需求的测试
8.实现持续部署和零停机发布
9.管理基础设施、数据、组件和依赖
风险管理、符合度和审计
一.构建
什么是构建：
在现代软件学中，可能经常听到CMMI，ISO(大型团队)、中小型团队(敏捷开发、XP编程)
构建工具：MSBuild、Maven、Ant、NAnt、Gradle
Unit是整个金字塔的基石（在建筑行业，基石是做建筑物基础的石头），如果基石不稳，Service和UI何谈有构建意义呢？只有基石稳如磐石，上层建筑才够坚固。
本来想拿瑞士做钟表的例子来说明下，但同事说的汽车例子更好。一辆汽车由许多配件组成，如果有以下两种选择，你会选择哪个呢？
1. 所有单元配件没有测试过，在4S店，销售人员告诉你：刚组装好，已经开了一天，能跑起来，你可以试试；
2. 所有单元配件在生产过程已经经过严格测试，在4S点，销售人员告诉你，已经通过国家认证，出厂合格，有质量保证，你可以试试；
MSBuild 是 Microsoft 和 Visual Studio的生成系统。它不仅仅是一个构造工具，应该称之为拥有相当强大扩展能力的自动化平台。MSBuild平台的主要涉及到三部分：执行引擎、构造工程、任务。其中最核心的就是执行引擎，它包括定义构造工程的规范，解释构造工程，执行“构造动作”；构造工程是用来描述构造任务的，大多数情况下我们使用MSBuild就是遵循规范，编写一个构造工程；MSBuild引擎执行的每一个“构造动作”就是通过任务实现的，任务就是MSBuild的扩展机制，通过编写新的任务就能够不断扩充MSBuild的执行能力。所以这三部分分别代表了引擎、脚本和扩展能力。
二.版本控制
配置管理：使用版本控制
版本控制系统（源代码控制管理系统）是保存文件多个版本的一种机制。一般来说，包括Subversion、Git在内的开源工具就可以满足绝大多数团队的需求。所有的版本控制系统都需要解决这样一个基础问题:
怎样让系统允许用户共享信息，而不会让他们因意外而互相干扰？
如果没有版本控制工具的协助，在开发中我们经常会遇到下面的一些问题：
一、 代码管理混乱。
二、 解决代码冲突困难。
三、 在代码整合期间引入深层BUG。
四、 无法对代码的拥有者进行权限控制。
五、 项目不同版本发布困难。
对所有内容都进行版本控制
版本控制不仅仅针对源代码，每个与所开发的软件相关的产物都应该被置于版本控制下，应当包括：源代码、测试代码、数据库脚本、构建和部署脚本、文档、web容器（tomcat的配置）所用的配置文件等。
保证频繁提交可靠代码到主干
频繁提交可靠、有质量保证的代码（编译通过是最基本要求），能够轻松回滚到最近可靠的版本，代码提交之后能够触发持续集成构建，及时得到反馈。
提交有意义的注释
强制要求团队成员使用有意义注释，甚至可以关联相关开发任务的原因是。当构建失败后，你知道是谁破坏了构建，找到可能的原因及定位缺陷位置。这些附加信息，可以缩短我们修复缺陷的时间。示例：团队使用了svn和redmine。
有可以加强的部分
1.Git要求每次提交都必须写提交说明，可以借鉴
2.测试代码、数据库脚本单独分支
3.构建脚本化
三.部署
3.1 最基本的部署流水线
这个流程的起点是开发人员向版本控制库提交代码。此时，持续集成系统对这次提交做出响应，触发该流水线的一个实例。
第一个阶段会编译代码，运行单元测试，执行代码分析，创建软件二进制包。如果所有的单元测试都通过了，并且代码符合编码标准，就将可执行代码打包成可执行文件，并放到一个制品库里中。有些在提交而极端，还会执行另外一些任务，比如为验收测试准备数据库。
第二个阶段由运行时间较长的自动化验收测试组成。所以持续集成服务器最好支持将测试分成多组的做法，以便在构建网络中并行执行任务，提高执行效率。这个阶段在第一个阶段完成后自动触发的。
部署流水线可能有分支出现，这样就可以将该构建版本独立部署到多个不同的环境中，比如部署到用户验收环境、容量测试环境和生成环境。这时，部署到相应的环境，就需要用到自动化部署脚本来执行这种部署过程。测试人员应当能看到需要测试的所有构建版本，以及他们的状态。
目的：最快的得到反馈
3.2部署流水线的相关实践
只生成一次二进制包
我们将所有可执行代码的集合称作二进制包，例如.NET程序集。有时候代码不需要编译，那么这种情况下，二进制是所有文件的集合。一种相关的反模式就是一直使用源代码而不是二进制包。因此，每次讲一个修改部署时，需要自己亲自从发布分支迁出源代码并重新编译二进制包。同时，还可能因编译器和某个依赖的不同版本产生差异。
部署的可视化
四.单元测试(TDD)
测试分类：
BDD,TDD,ATDD
BDD主要是基于场景、面向需求的,ATDD面向验收的，这里不做过多介绍了。
这里主要介绍TDD的一些开发
什么是TDD？
测试驱动开发
TDD的优点
TDD从一开就保证了代码的质量：鼓励开发人员只开发”最小化“的代码完成特定测试功能。
遵循SOLID原则： SOLID (单一功能、开闭原则、里氏替换、接口隔离以及依赖反转)
1.TDD确保了代码与业务需求之间的高度一致性。
2.TDD鼓励创建更简单，针对性更强的API
TDD鼓励更多的沟通，与企业，与团队内部。
TDD有助于清除冗余代码
TDD提供了内置的回归测试。
如果没有单元测试来帮助查找和诊断缺陷时，大多数开发人员会使用调试器，在他们认为出现缺陷的地方设置断点，有时将这种方法称为"散弹枪方法"。
单元测试的特征：
1.与其他代码隔离
2.有针对性
3.与其他开发人员隔离
4.可重复
5.可预测
自动化单元测试原则：
提交代码、运行测试的重点是什么？快速捕获那些因修改向系统中引入的最常见错误，并通知开发人员，以便他们能快速修复他们。提交阶段提供反馈的价值在于，对它的投入可以让系统高效且更快地工作。
隔离UI操作
UI应当作为更高层次的测试Level，需要花费大量时间准备数据，业务逻辑复杂，过早进入UI阶段，容易分散开发的单元测试精力。
隔离数据库以及文件读写网络开销等操作
自动化测试中如果需要将结果写入数据库，然后再验证改结果是否被正确写入，这种验证方法简单、容易理解，但是它不是一个高效的方法。这个应当从集成测试的Level去解决。
首先：与数据库的交互，是漫长的，甚至有可能要投入维护数据库的时间，那将成为快速测试的一个障碍，开发人员不能得到及时有效的反馈。假设，我需要花费一个小时，才能验证完毕与数据库交互的结果，这种等待是多么漫长呀。
其次，数据管理需要成本，从数据的筛选（线上数据可能是T级）到测试环境的M级别，如何把筛选合适的大小，这都使得管理成本增加（当然在集成测试中可以使用DBUnit来解决部分问题）。
最后，如果一定要有读写操作才能完成的测试，也要反思代码的可测试性做的如何？是否需要重构。
单元测试决不要依赖于数据库以及文件系统、网络开销等一切外部依赖。
使用隔离框架和依赖框架
可以使用模拟工具集：Rhino.Mock、Moq、Type Mock等来解决，研发团队主要是基于Mockito的实践。与需要组装所有的依赖和状态相比，使用模拟技术的测试运行起来通常是非常快，这样子开发人员在提交代码之后，可以在持续集成平台快速得到反馈。
实践
常规
一个加密、解密方法的测试
Ignore标志的方法，当我们运行测试实例时，可以忽略
Category
可以只运行指定目录的测试用例
Rhino.Mocks的简单实用
| [Test]
[Category("模拟对象")]
public void TestCustomer()
{
MockRepository mocks = new MockRepository();
ICustomer customer = mocks.StrictMock<ICustomer>();
customer.Expect(c => c.ShowTitle("")).Return("567");
Expect.Call(customer.Pid).Return(30);
customer.Replay();
Assert.AreEqual(customer.ShowTitle(""),
"567");
}
[Test]
public void SayHelloWorld()
{
MockRepository mocks = new MockRepository();
INameSource nameSource = mocks.DynamicMock<INameSource>();
Expect.Call(nameSource.CreateName(null, null))
.IgnoreArguments()
.Do(new NameSourceDelegate(Formal));
mocks.ReplayAll();
const string expected = "Hi, my name is
Ayende Rahien";
string actual = new Speaker("Bright",
"Gong", nameSource).Introduce();
Assert.AreEqual(expected, actual);
}
delegate string NameSourceDelegate(string first,
string surname);
public class Speaker
{
private readonly string _firstName;
private readonly string _surname;
private readonly INameSource _nameSource;
public Speaker(string firstName, string surname,
INameSource nameSource)
{
this._firstName = firstName;
this._surname = surname;
this._nameSource = nameSource;
}
public string Introduce()
{
string name = _nameSource.CreateName(_firstName,
_surname);
return string.Format("Hi, my name is {0}",
name);
}
} |
红灯、绿灯、重构
"红灯、绿灯、重构"明确了开发人员在实施TDD时所要遵循的工作流。
1.红灯阶段
在开始使用TDD时，许多开发人员会问："我怎么能为不存在的代码编写测试呢？"事实上，许多测试都是针对当期不存在的类或方法的。这意味着这些测试甚至不能编译通过，其效果基本上与失败测试相同。这没问题，记住，这是因为有了这些测试，才需要有相应的代码存在。
红灯阶段，主要是编写一个会测试失败的代码，
比如
| [Category("simple")]
[Test]
public bool MyMEthod(int inputParameter)
{
throw new NotImplementedException();
} |
2.绿灯阶段
仅编写适量的代码，是新测试通过而不导致任何测试失败。
| [Category("simple")]
[Test]
public bool MyMEthod(int inputParameter)
{
return false;
} |
有些人觉得是不是代码太少了，至少需要明白说什么，至少像
| [Category("simple")]
[Test]
public bool MyMEthod(int inputParameter)
{
if(inputParameter=60)
{
return false;
}
return true;
} |
其实不然，返回false是我们的期望，我们希望在输入60的时候，返回false，明显只要返回false就足够了。后面增加的测试会让我们扩展方法。原则是，不要向代码引入不必要的复杂度。
3.重构阶段：
给我们的代码添砖加瓦，使代码具有可维护性、可读性或整体代码质量。
重构示例：
我们用一个闯三关的游戏来简单介绍
规则:胜方标记X或O，没有玩家获胜，则返回空字符
我们创建了一个测试方法
如下图
| private
IGameWinnerService _gameWinnerService;
private char[,] _gameBoard;
[SetUp]
public void SetupUnitTests()
{
_gameWinnerService = new GameWinnerService();
_gameBoard = new char[3, 3]
{
{' ', ' ', ' '},
{' ', ' ', ' '},
{' ', ' ', ' '}
};
}
[Test]
public void NeitherPlayerHasThreeInARow()
{
const char expected = ' ';
var actual = _gameWinnerService.Validate(_gameBoard);
Assert.AreEqual(expected, actual);
} |
传递一个空数组，即没有一个玩家在一行中放入了3个标记，我们的期望是返回空字符，即没有人获胜
但上面的代码不会编译通过，因为我们没有定义接口，IGameWinnerService
| public
interface IGameWinnerService
{
char Validate(char[,] gameBoard);
} |
但还是会失败，因为我们没有定义实现的类，GameWinnerService
| public
class GameWinnerService : IGameWinnerService
{
public char Validate(char[,] gameBoard)
{
throw new NotImplementedException();
}
} |
编译可以通过了，但运行报错，接下来完善这个方法
| public
class GameWinnerService : IGameWinnerService
{
private const char SymbolForNoWinner = ' ';
public char Validate(char[,] gameBoard)
{
return SymbolForNoWinner;
}
} |
五.架构代码的文档化
1.文档有哪些
开发文档、测试文档、需求文档、用户手册、技术手册等
2.简化文档编写
1.开发文档：GhostDoc有收费版，免费版，Free版，平时就够用了。
2.GHost可以基于策略的，给注释添加规则，自定义宏
3.随代码提交到版本库
需求文档：
测试用例的导出
3.文档的整合
知识库：
Wiki：
新闻： 
现在的方式
1.OneNote+SharePoint+TFS+Project
协同办公
2.OneNote：用户手册、技术手册
3.SharePoint：需求文档，侧重于文件
4.TFS:开发文档、用例(需求用例，测试用例)
5.Project：项目管理，多维度
实例：
1.SharePoint+TFS集成
2.SharePoint+OneNote集成，OneNote更改调用SharePoint的邮件提醒
3.研究Project2010+TFS2010项目需求管理功能
4.TFS-Project Server 集成的同步过程概述
4.文档的持续更新
很多项目忽视了文档，主要是因为团队大了以后，一个函数、方法会有很多人修改，无法保证注释文档的持续更新。
5.文档自动化发布
OneNote
6.文档的检索要方便
API函数、方法生成HTML文档
支持目录、索引、搜索
例子： 
新闻、维科的搜索
7.文档的权限控制
8.需求变更管理
实例：
需求变更管理
需求的变更要被记录下来
历史记录应可以查询，并且结果清晰可见。 
项目跟进
可以邮件提醒给相关人员
需求变更的审核
新建的需求，都是未审核需求，开发和测试人员都不可见，只有经过审核的需求才能看得到
9.实践
六.命名约定
主要内容：
扩展型设计
错误定义：
1.类型设计规范
2.成员设计规范
3.框架设计规范
七.数据库伸缩性
采用分库的方法，可以把一个库的压力分担在若干不同的库上；这种方法很适用数据爆增的系统，只需要增加硬件就可以线性的解决性能和存储的问题；如果考虑以后增长会很快，可在在分库中增加分表；在分库的基础上可以在按功能或其他方式在分库
分库的几个原则：
1.按功能分割
2.水平切分
3.避免分布式事务
4.用异步策略解耦程序
5.将过程转变为异步的流
6.虚拟化所有层次
7.适当地使用缓存
八.自动化
SCRUM软件开发过程的创始人曾经说过：
如果某个过程能够确定下来(即能偶了解过程所涉及的所有细节，从而将其设计为可以重复地多次运行，并且安全能够预测其结果)，那么该过程就被称为“确定过程”。从理论上讲，一切确定的工程都可以被自动完成。另一方面，人们并未了解某个过程中的所有细节，只是知道到在某些初始条件下，通过某些调节和控制就能得到想要的结果，这样的过程称为“经验过程”。
我们可以通过构建工具按照预定的设置，自动化运行，把错误信息报告给关键开发者，从而减少工作量。同时，自动化构建也是项目安全的保证。谁破坏了构建，一目了然。每当项目的核心代码被修改时，整个应用程序就会被重新构建，随后自动运行回归测试，已确保这次修改没有造成任何破坏。
自动化脚本
钩子
九.反馈
1.常用的持续集成平台：jenkins、Teamcity
2.反馈平台：jenkins&sonarqube、TFS&Project&Sharepoint、Teamcity&NotCover
3.目的：发现潜在的bug，分析找出项目里的坏味道等，从而提高代码质量
4.简单介绍下sonarqube
Sonar是一个用于代码质量管理的开源平台，用于管理源代码的质量，可以从七个维度检测代码质量
通过插件形式，可以支持包括java,C#,C/C++,PL/SQL,Cobol,JavaScrip,Groovy等等二十几种编程语言的代码质量管理与检测
为什么选择Sonar
Developers' Seven Deadly Sins
1.糟糕的复杂度分布
文件、类、方法等，如果复杂度过高将难以改变，就会难以理解。同时，一般来说代码越复杂，就越容易出错。而且如果没有自动化的单元测试，对于程序中的任何组件的改变都将可能导致需要全面的回归测试。
2.重复
显然程序中包含大量复制粘贴的代码是质量低下的。
sonar可以展示源码中重复严重的地方 
3.缺乏单元测试
sonar可以很方便地统计并展示单元测试覆盖率
4.代码覆盖
5.代码标准
sonar可以通过PMD,CheckStyle,Findbugs等等代码规则检测工具规范代码编写。
sonar还支持多种语言C#，Java,Python,Android等
6.潜在问题代码
7.设计及注释架构
8.比较
可以根据基于指标，项目间的比较
9.扩展性：
sonar的集成是通过插件来扩展的。跟其他工具的集成
sonar支持的开发扩展
简单介绍下Jenkins
Jenkins，之前叫做Hudson，是基于Java开发的一种持续集成工具，用于监控持续重复的工作，包括：
1、持续的软件版本发布/测试项目。
2、监控外部调用执行的工作。
1.备份和恢复
备份和恢复非常简单，就是简单的copy Jenkins的目录就好了：
| All
the settings, build logs, artifact archives
are stored under the JENKINS_HOME directory.
Simply archive this directory to make a back
up. Similarly, restoring the data is just replacing
the contents of the JENKINS_HOME directory from
a back up. |
2.自动运行Build
触发一个build有三种方式：
Builds in Jenkins can be triggered periodically (on
a schedule, specified in configuration) 这里定义schedule的语法是unix常见的cron语法。
Or when source changes in the project have been
detected |
可以设置Jenkins定时检查SVN或TFS 是否发生了变化，也可以手动检查：http://YOURHOST/jenkins/job/PROJECTNAME/pollong。也可以设置Jenkins为post-commit，这个方式尤其适用于那些检查是否代码改变会花费很长时间的情况。
3.因为性能问题，将build分布到多个slave节点去。
到Jenkins的管理界面，就可以方便的添加节点。配置节点时，需要提供节点所在的机器，登陆用户名密码，使用的目录等。
但是slave并不需要再安装Jenkins。jenkins会自动启用slave agent，将build需要tools考到远程机器上。
需要注意的是：the build results and artifacts will always
end up on the master server. 因此不需要跑到各个节点去查看build产生的文件，log等。
其实在slave节点，会创建一个本地的workspace，并在运行时使用这个workspace。因为毕竟build运行在slave节点上，所以这个节点肯定要有运行build需要的所有因素。
4.创建一个Project
因为Jenkins可以用于运行各种CI，测试，批处理任务等等，所以在Jenkins中将这些任务统称为“free-style
software project”.
目前：低成本的集成方案
Jenkins+MSTEST+MSBuild
十.实践
工具：TFS+jenkins+sonar
TFS 作为版本控制的核心
jenkins 自动化构建的关键
sonar 静态检测的执行者，代码质量反馈的中心
NUnit(推荐)或MSTEST 作为单元测试工具 |
