标签：
在使用持续集成之前，很多开发团队都是用每日构建(nightly build)。当时，微软使用这个实践很多年了。谁破坏了构建，就要负责监视后续的构建构成，直至发现下一个破坏了构建的人。
对于大多数项目来说，采纳持续集成实践是向高效率和高质量迈进的一大步。它保证那些创建大型复杂系统的团队具有高度的自信心和控制力。一旦代码提交引入了问题，持续集成就能为我们提供快速的反馈，从而确保我们作为一个团队所开发的软件是可以工作的。
持续集成的主要关注对象是开发团队。持续集成系统的输出通常作为手工测试流程和后续发布流程的输入。在软件的发布过程中，很多浪费来自于测试和运维环节。
例如：我们常常看到：
采取一种更完整的端到端的方法来交付软件。我们通过一键式方式把软件的某个版本部署好，甚至可以将其一键式部署到生成环境中，这样就可以建立了一个非常有效的反馈环--由于很容易将应用程序部署到测试环境中，所以团队可以同时得到软件功能和部署流程两个方面的快速反馈。因为部署流程(无论是测试，集成)都是自动化的，所以可以频繁且有规律的运行并被测试，从而降低发布风险，也降低了向开发团队传递有关部署流程的知识时的风险。
从精益的角度来看，我们实现了一个"拉式系统"，测试团队只要自己单击按钮，就能轻松部署。管理人员也能容易得到一些关键的度量指标，比如周期时间，吞吐量以及代码质量。
什么是构建：
在现代软件学中，可能经常听到CMMI，ISO(大型团队)、中小型团队(敏捷开发、XP编程)
构建工具：MSBuild、Maven、Ant、NAnt、Gradle
Unit是整个金字塔的基石（在建筑行业，基石是做建筑物基础的石头），如果基石不稳，Service和UI何谈有构建意义呢？只有基石稳如磐石，上层建筑才够坚固。
本来想拿瑞士做钟表的例子来说明下，但同事说的汽车例子更好。一辆汽车由许多配件组成，如果有以下两种选择，你会选择哪个呢？
1. 所有单元配件没有测试过，在4S店，销售人员告诉你：刚组装好，已经开了一天，能跑起来，你可以试试；
2. 所有单元配件在生产过程已经经过严格测试，在4S点，销售人员告诉你，已经通过国家认证，出厂合格，有质量保证，你可以试试；
MSBuild 是 Microsoft 和 Visual Studio的生成系统。它不仅仅是一个构造工具，应该称之为拥有相当强大扩展能力的自动化平台。MSBuild平台的主要涉及到三部分：执行引擎、构造工程、任务。其中最核心的就是执行引擎，它包括定义构造工程的规范，解释构造工程，执行“构造动作”；构造工程是用来描述构造任务的，大多数情况下我们使用MSBuild就是遵循规范，编写一个构造工程；MSBuild引擎执行的每一个“构造动作”就是通过任务实现的，任务就是MSBuild的扩展机制，通过编写新的任务就能够不断扩充MSBuild的执行能力。所以这三部分分别代表了引擎、脚本和扩展能力。
MSBuild的简单介绍与使用
配置管理：使用版本控制
版本控制系统（源代码控制管理系统）是保存文件多个版本的一种机制。一般来说，包括Subversion、Git在内的开源工具就可以满足绝大多数团队的需求。所有的版本控制系统都需要解决这样一个基础问题: 怎样让系统允许用户共享信息，而不会让他们因意外而互相干扰？
如果没有版本控制工具的协助，在开发中我们经常会遇到下面的一些问题：
一、 代码管理混乱。
二、 解决代码冲突困难。
三、 在代码整合期间引入深层BUG。
四、 无法对代码的拥有者进行权限控制。
五、 项目不同版本发布困难。
对所有内容都进行版本控制
版本控制不仅仅针对源代码，每个与所开发的软件相关的产物都应该被置于版本控制下，应当包括：源代码、测试代码、数据库脚本、构建和部署脚本、文档、web容器（tomcat的配置）所用的配置文件等。
保证频繁提交可靠代码到主干
频繁提交可靠、有质量保证的代码（编译通过是最基本要求），能够轻松回滚到最近可靠的版本，代码提交之后能够触发持续集成构建，及时得到反馈。
提交有意义的注释
强制要求团队成员使用有意义注释，甚至可以关联相关开发任务的原因是。当构建失败后，你知道是谁破坏了构建，找到可能的原因及定位缺陷位置。这些附加信息，可以缩短我们修复缺陷的时间。示例：团队使用了svn和redmine。
有可以加强的部分
- Git要求每次提交都必须写提交说明，可以借鉴
- 测试代码、数据库脚本单独分支
- 构建脚本化
这个流程的起点是开发人员向版本控制库提交代码。此时，持续集成系统对这次提交做出响应，触发该流水线的一个实例。
第一个阶段会编译代码，运行单元测试，执行代码分析，创建软件二进制包。如果所有的单元测试都通过了，并且代码符合编码标准，就将可执行代码打包成可执行文件，并放到一个制品库里中。有些在提交而极端，还会执行另外一些任务，比如为验收测试准备数据库。
第二个阶段由运行时间较长的自动化验收测试组成。所以持续集成服务器最好支持将测试分成多组的做法，以便在构建网络中并行执行任务，提高执行效率。这个阶段在第一个阶段完成后自动触发的。
部署流水线可能有分支出现，这样就可以将该构建版本独立部署到多个不同的环境中，比如部署到用户验收环境、容量测试环境和生成环境。这时，部署到相应的环境，就需要用到自动化部署脚本来执行这种部署过程。测试人员应当能看到需要测试的所有构建版本，以及他们的状态。
目的：最快的得到反馈3.2部署流水线的相关实践
- 只生成一次二进制包
我们将所有可执行代码的集合称作二进制包，例如.NET程序集。有时候代码不需要编译，那么这种情况下，二进制是所有文件的集合。一种相关的反模式就是一直使用源代码而不是二进制包。因此，每次讲一个修改部署时，需要自己亲自从发布分支迁出源代码并重新编译二进制包。同时，还可能因编译器和某个依赖的不同版本产生差异。
部署的可视化
测试分类：
BDD,TDD,ATDD
BDD主要是基于场景、面向需求的,ATDD面向验收的，这里不做过多介绍了。
这里主要介绍TDD的一些开发
测试驱动开发
TDD的优点
TDD从一开就保证了代码的质量：鼓励开发人员只开发”最小化“的代码完成特定测试功能。
遵循SOLID原则： SOLID (单一功能、开闭原则、里氏替换、接口隔离以及依赖反转)
TDD确保了代码与业务需求之间的高度一致性。
TDD鼓励创建更简单，针对性更强的API
TDD鼓励更多的沟通，与企业，与团队内部。
TDD有助于清除冗余代码
TDD提供了内置的回归测试。如果没有单元测试来帮助查找和诊断缺陷时，大多数开发人员会使用调试器，在他们认为出现缺陷的地方设置断点，有时将这种方法称为"散弹枪方法"。
单元测试的特征：
- 与其他代码隔离
- 有针对性
- 与其他开发人员隔离
- 可重复
- 可预测
提交代码、运行测试的重点是什么？快速捕获那些因修改向系统中引入的最常见错误，并通知开发人员，以便他们能快速修复他们。提交阶段提供反馈的价值在于，对它的投入可以让系统高效且更快地工作。
常规
一个加密、解密方法的测试
[Test] [Ignore("这个测试有问题!")] public void TestEncrypt() { FileEncrypt fileEncrypt = new FileEncrypt(); String ii = fileEncrypt.EncryptContext("Hello World", "123"); ii = fileEncrypt.DecryptContext(ii, "123"); Assert.Pass(ii); }
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时所要遵循的工作流。
[Category("simple")] [Test] public bool MyMEthod(int inputParameter) { throw new NotImplementedException(); }
[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; }
重构阶段：
给我们的代码添砖加瓦，使代码具有可维护性、可读性或整体代码质量。
重构示例：
我们用一个闯三关的游戏来简单介绍
规则:胜方标记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; } }
开发文档、测试文档、需求文档、用户手册、技术手册等
需求文档：
测试用例的导出
知识库：
Wiki：
新闻：
很多项目忽视了文档，主要是因为团队大了以后，一个函数、方法会有很多人修改，无法保证注释文档的持续更新。
OneNote
API函数、方法生成HTML文档
支持目录、索引、搜索
例子：
新闻、维科的搜索
实例：
采用分库的方法，可以把一个库的压力分担在若干不同的库上；这种方法很适用数据爆增的系统，只需要增加硬件就可以线性的解决性能和存储的问题；如果考虑以后增长会很快，可在在分库中增加分表；在分库的基础上可以在按功能或其他方式在分库
分库的几个原则：
SCRUM软件开发过程的创始人曾经说过：
如果某个过程能够确定下来(即能偶了解过程所涉及的所有细节，从而将其设计为可以重复地多次运行，并且安全能够预测其结果)，那么该过程就被称为“确定过程”。从理论上讲，一切确定的工程都可以被自动完成。另一方面，人们并未了解某个过程中的所有细节，只是知道到在某些初始条件下，通过某些调节和控制就能得到想要的结果，这样的过程称为“经验过程”。
我们可以通过构建工具按照预定的设置，自动化运行，把错误信息报告给关键开发者，从而减少工作量。同时，自动化构建也是项目安全的保证。谁破坏了构建，一目了然。每当项目的核心代码被修改时，整个应用程序就会被重新构建，随后自动运行回归测试，已确保这次修改没有造成任何破坏。
常用的持续集成平台：jenkins、Teamcity
反馈平台：jenkins&sonarqube、TFS&Project&Sharepoint、Teamcity&NotCover
目的：发现潜在的bug，分析找出项目里的坏味道等，从而提高代码质量
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的集成是通过插件来扩展的。跟其他工具的集成
Jenkins，之前叫做Hudson，是基于Java开发的一种持续集成工具，用于监控持续重复的工作，包括：
1、持续的软件版本发布/测试项目。
2、监控外部调用执行的工作。
- 备份和恢复
备份和恢复非常简单，就是简单的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.- 自动运行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，这个方式尤其适用于那些检查是否代码改变会花费很长时间的情况。- 因为性能问题，将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需要的所有因素。- 创建一个Project
因为Jenkins可以用于运行各种CI，测试，批处理任务等等，所以在Jenkins中将这些任务统称为“free-style software project”.
目前：低成本的集成方案
Jenkins+MSTEST+MSBuild
工具：TFS+jenkins+sonar
TFS 作为版本控制的核心
jenkins 自动化构建的关键
sonar 静态检测的执行者，代码质量反馈的中心
NUnit(推荐)或MSTEST 作为单元测试工具
依赖管理
工具：Nuget
标签：
原文地址：http://www.cnblogs.com/Jiemomoon/p/4311935.html
