持续集成方案(一)大纲
构建版本控制部署单元测试架构文档化命名约定数据库伸缩性自动化反馈实践引言：持续集成的前身：在使用持续集成之前，很多开发团队都是用每日构建(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.1 最基本的部署流水线
这个流程的起点是开发人员向版本控制库提交代码。此时，持续集成系统对这次提交做出响应，触发该流水线的一个实例。第一个阶段会编译代码，运行单元测试，执行代码分析，创建软件二进制包。如果所有的单元测试都通过了，并且代码符合编码标准，就将可执行代码打包成可执行文件，并放到一个制品库里中。有些在提交而极端，还会执行另外一些任务，比如为验收测试准备数据库。第二个阶段由运行时间较长的自动化验收测试组成。所以持续集成服务器最好支持将测试分成多组的做法，以便在构建网络中并行执行任务，提高执行效率。这个阶段在第一个阶段完成后自动触发的。部署流水线可能有分支出现，这样就可以将该构建版本独立部署到多个不同的环境中，比如部署到用户验收环境、容量测试环境和生成环境。这时，部署到相应的环境，就需要用到自动化部署脚本来执行这种部署过程。测试人员应当能看到需要测试的所有构建版本，以及他们的状态。目的：最快的得到反馈
3.2部署流水线的相关实践只生成一次二进制包我们将所有可执行代码的集合称作二进制包，例如.NET程序集。有时候代码不需要编译，那么这种情况下，二进制是所有文件的集合。一种相关的反模式就是一直使用源代码而不是二进制包。因此，每次讲一个修改部署时，需要自己亲自从发布分支迁出源代码并重新编译二进制包。同时，还可能因编译器和某个依赖的不同版本产生差异。部署的可视化
四.单元测试(TDD)测试分类：
BDD,TDD,ATDDBDD主要是基于场景、面向需求的,ATDD面向验收的，这里不做过多介绍了。这里主要介绍TDD的一些开发
什么是TDD？测试驱动开发
TDD的优点TDD从一开就保证了代码的质量：鼓励开发人员只开发”最小化“的代码完成特定测试功能。遵循SOLID原则： SOLID (单一功能、开闭原则、里氏替换、接口隔离以及依赖反转)TDD确保了代码与业务需求之间的高度一致性。TDD鼓励创建更简单，针对性更强的APITDD鼓励更多的沟通，与企业，与团队内部。TDD有助于清除冗余代码TDD提供了内置的回归测试。
如果没有单元测试来帮助查找和诊断缺陷时，大多数开发人员会使用调试器，在他们认为出现缺陷的地方设置断点，有时将这种方法称为"散弹枪方法"。
单元测试的特征：
与其他代码隔离有针对性与其他开发人员隔离可重复可预测自动化单元测试原则：提交代码、运行测试的重点是什么？快速捕获那些因修改向系统中引入的最常见错误，并通知开发人员，以便他们能快速修复他们。提交阶段提供反馈的价值在于，对它的投入可以让系统高效且更快地工作。
隔离UI操作UI应当作为更高层次的测试Level，需要花费大量时间准备数据，业务逻辑复杂，过早进入UI阶段，容易分散开发的单元测试精力。隔离数据库以及文件读写网络开销等操作自动化测试中如果需要将结果写入数据库，然后再验证改结果是否被正确写入，这种验证方法简单、容易理解，但是它不是一个高效的方法。这个应当从集成测试的Level去解决。首先：与数据库的交互，是漫长的，甚至有可能要投入维护数据库的时间，那将成为快速测试的一个障碍，开发人员不能得到及时有效的反馈。假设，我需要花费一个小时，才能验证完毕与数据库交互的结果，这种等待是多么漫长呀。其次，数据管理需要成本，从数据的筛选（线上数据可能是T级）到测试环境的M级别，如何把筛选合适的大小，这都使得管理成本增加（当然在集成测试中可以使用DBUnit来解决部分问题）。最后，如果一定要有读写操作才能完成的测试，也要反思代码的可测试性做的如何？是否需要重构。单元测试决不要依赖于数据库以及文件系统、网络开销等一切外部依赖。使用隔离框架和依赖框架可以使用模拟工具集：Rhino.Mock、Moq、Type Mock等来解决，研发团队主要是基于Mockito的实践。与需要组装所有的依赖和状态相比，使用模拟技术的测试运行起来通常是非常快，这样子开发人员在提交代码之后，可以在持续集成平台快速得到反馈。实践常规一个加密、解密方法的测试
[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)