持续集成方案_.NET_编程开发_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 编程开发 > .NET > 持续集成方案

持续集成方案

 2015/3/3 22:39:32  芥子茉  程序员俱乐部  我要评论(0)
  • 摘要:大纲构建版本控制部署单元测试架构文档化命名约定数据库伸缩性自动化反馈实践引言:持续集成的前身:在使用持续集成之前,很多开发团队都是用每日构建(nightlybuild)。当时,微软使用这个实践很多年了。谁破坏了构建,就要负责监视后续的构建构成,直至发现下一个破坏了构建的人。为什么要使用持续集成?对于大多数项目来说,采纳持续集成实践是向高效率和高质量迈进的一大步。它保证那些创建大型复杂系统的团队具有高度的自信心和控制力。一旦代码提交引入了问题,持续集成就能为我们提供快速的反馈
  • 标签:

大纲

 

  1. 构建
  2. 版本控制
  3. 部署
  4. 单元测试
  5. 架构文档化
  6. 命名约定
  7. 数据库伸缩性
  8. 自动化
  9. 反馈
  10. 实践
引言:
持续集成的前身:

在使用持续集成之前,很多开发团队都是用每日构建(nightly build)。当时,微软使用这个实践很多年了。谁破坏了构建,就要负责监视后续的构建构成,直至发现下一个破坏了构建的人。

为什么要使用持续集成?
    对于大多数项目来说,采纳持续集成实践是向高效率和高质量迈进的一大步。它保证那些创建大型复杂系统的团队具有高度的自信心和控制力。一旦代码提交引入了问题,持续集成就能为我们提供快速的反馈,从而确保我们作为一个团队所开发的软件是可以工作的。
    持续集成的主要关注对象是开发团队。持续集成系统的输出通常作为手工测试流程和后续发布流程的输入。在软件的发布过程中,很多浪费来自于测试和运维环节。
    例如:我们常常看到:
  • 构建和运维团队的人员一直在等待说明文档或缺陷修复
  • 测试人员等待"好的"版本构建出来
  • 在新功能开发完成一段时间后,才收到缺陷报告
  • 开发完成时,才发现当前的软件架构无法满足该系统的一些非功能需求
持续集成的一些实践:

采取一种更完整的端到端的方法来交付软件。我们通过一键式方式把软件的某个版本部署好,甚至可以将其一键式部署到生成环境中,这样就可以建立了一个非常有效的反馈环--由于很容易将应用程序部署到测试环境中,所以团队可以同时得到软件功能和部署流程两个方面的快速反馈。因为部署流程(无论是测试,集成)都是自动化的,所以可以频繁且有规律的运行并被测试,从而降低发布风险,也降低了向开发团队传递有关部署流程的知识时的风险。

从精益的角度来看,我们实现了一个"拉式系统",测试团队只要自己单击按钮,就能轻松部署。管理人员也能容易得到一些关键的度量指标,比如周期时间,吞吐量以及代码质量。

持续集成主要内容包括:
  • 将软件构建、集成、测试和部署全面实现自动化
  • 在团队和组织级别实现部署流水线
  • 改进开发人元、测试人员和运维人员间的协作
  • 在大型分布式团队中增量并发开发软件功能
  • 实施高效的配置管理策略
  • 分析并实现自动化验收测试
  • 容量测试和其他非功能需求的测试
  • 实现持续部署和零停机发布
  • 管理基础设施、数据、组件和依赖
  • 风险管理、符合度和审计
一.构建

什么是构建
在现代软件学中,可能经常听到CMMI,ISO(大型团队)、中小型团队(敏捷开发、XP编程)


1417326311657

构建工具:MSBuild、MavenAnt、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 最基本的部署流水线

1417340015222

这个流程的起点是开发人员向版本控制库提交代码。此时,持续集成系统对这次提交做出响应,触发该流水线的一个实例。
第一个阶段会编译代码,运行单元测试,执行代码分析,创建软件二进制包。如果所有的单元测试都通过了,并且代码符合编码标准,就将可执行代码打包成可执行文件,并放到一个制品库里中。有些在提交而极端,还会执行另外一些任务,比如为验收测试准备数据库。
第二个阶段由运行时间较长的自动化验收测试组成。所以持续集成服务器最好支持将测试分成多组的做法,以便在构建网络中并行执行任务,提高执行效率。这个阶段在第一个阶段完成后自动触发的。
部署流水线可能有分支出现,这样就可以将该构建版本独立部署到多个不同的环境中,比如部署到用户验收环境、容量测试环境和生成环境。这时,部署到相应的环境,就需要用到自动化部署脚本来执行这种部署过程。测试人员应当能看到需要测试的所有构建版本,以及他们的状态。
目的:最快的得到反馈

3.2部署流水线的相关实践
  • 只生成一次二进制包
    我们将所有可执行代码的集合称作二进制包,例如.NET程序集。有时候代码不需要编译,那么这种情况下,二进制是所有文件的集合。一种相关的反模式就是一直使用源代码而不是二进制包。因此,每次讲一个修改部署时,需要自己亲自从发布分支迁出源代码并重新编译二进制包。同时,还可能因编译器和某个依赖的不同版本产生差异。

部署的可视化

四.单元测试(TDD)

测试分类:

1417342844178

BDD,TDD,ATDD
BDD主要是基于场景、面向需求的,ATDD面向验收的,这里不做过多介绍了。
这里主要介绍TDD的一些开发

什么是TDD?

测试驱动开发

TDD的优点
TDD从一开就保证了代码的质量:鼓励开发人员只开发”最小化“的代码完成特定测试功能。
遵循SOLID原则: SOLID (单一功能、开闭原则、里氏替换、接口隔离以及依赖反转)
TDD确保了代码与业务需求之间的高度一致性。
TDD鼓励创建更简单,针对性更强的API
TDD鼓励更多的沟通,与企业,与团队内部。
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标志的方法,当我们运行测试实例时,可以忽略
1417356530715
Category
1417355849884
可以只运行指定目录的测试用例
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时所要遵循的工作流。

  • 红灯阶段
    在开始使用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;
    }
    其实不然,返回false是我们的期望,我们希望在输入60的时候,返回false,明显只要返回false就足够了。后面增加的测试会让我们扩展方法。原则是,不要向代码引入不必要的复杂度。
  • 重构阶段:
    给我们的代码添砖加瓦,使代码具有可维护性、可读性或整体代码质量。
    重构示例
    我们用一个闯三关的游戏来简单介绍
    规则:胜方标记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.简化文档编写
  • 开发文档:GhostDoc有收费版,免费版,Free版,平时就够用了。
    GHost可以基于策略的,给注释添加规则,自定义
    随代码提交到版本库
    1417334310049
  • 需求文档:

  • 测试用例的导出

3.文档的整合

1417344914786

知识库
Wiki:
新闻:
1417338569296

1417338499681

  • 现在的方式
    OneNote+SharePoint+TFS+Project 协同办公
    OneNote:用户手册、技术手册
    SharePoint:需求文档,侧重于文件
    TFS:开发文档、用例(需求用例,测试用例)
    Project:项目管理,多维度
    实例:
    SharePoint+TFS集成
    SharePoint+OneNote集成,OneNote更改调用SharePoint的邮件提醒
    研究Project2010+TFS2010项目需求管理功能
    TFS-Project Server 集成的同步过程概述
4.文档的持续更新

很多项目忽视了文档,主要是因为团队大了以后,一个函数、方法会有很多人修改,无法保证注释文档的持续更新。

5.文档自动化发布

OneNote

6.文档的检索要方便

API函数、方法生成HTML文档
支持目录、索引、搜索

例子
1417336789443


1417336897465

新闻、维科的搜索
1417338720421

7.文档的权限控制
8.需求变更管理

实例:

  • 需求变更管理
    需求的变更要被记录下来
    历史记录应可以查询,并且结果清晰可见。
    1417334925821
    项目跟进
  • 可以邮件提醒给相关人员
    1417346208292
  • 需求变更的审核
    新建的需求,都是未审核需求,开发和测试人员都不可见,只有经过审核的需求才能看得到
8.实践
六.命名约定
主要内容:
  • 扩展型设计
  • 错误定义:
  • 类型设计规范
  • 成员设计规范
  • 框架设计规范
七.数据库伸缩性

采用分库的方法,可以把一个库的压力分担在若干不同的库上;这种方法很适用数据爆增的系统,只需要增加硬件就可以线性的解决性能和存储的问题;如果考虑以后增长会很快,可在在分库中增加分表;在分库的基础上可以在按功能或其他方式在分库

分库的几个原则:

  1. 按功能分割
  2. 水平切分
  3. 避免分布式事务
  4. 异步策略解耦程序
  5. 将过程转变为异步的流
  6. 虚拟化所有层次
  7. 适当地使用缓存
八.自动化

SCRUM软件开发过程的创始人曾经说过:
如果某个过程能够确定下来(即能偶了解过程所涉及的所有细节,从而将其设计为可以重复地多次运行,并且安全能够预测其结果),那么该过程就被称为“确定过程”。从理论上讲,一切确定的工程都可以被自动完成。另一方面,人们并未了解某个过程中的所有细节,只是知道到在某些初始条件下,通过某些调节和控制就能得到想要的结果,这样的过程称为“经验过程”。

我们可以通过构建工具按照预定的设置,自动化运行,把错误信息报告给关键开发者,从而减少工作量。同时,自动化构建也是项目安全的保证。谁破坏了构建,一目了然。每当项目的核心代码被修改时,整个应用程序就会被重新构建,随后自动运行回归测试,已确保这次修改没有造成任何破坏。

  • 自动化脚本
  • 钩子
九.反馈

常用的持续集成平台:jenkins、Teamcity
反馈平台:jenkins&sonarqube、TFS&Project&Sharepoint、Teamcity&NotCover

目的:发现潜在的bug,分析找出项目里的坏味道等,从而提高代码质量

简单介绍下sonarqube

Sonar是一个用于代码质量管理的开源平台,用于管理源代码的质量,可以从七个维度检测代码质量
通过插件形式,可以支持包括java,C#,C/C++,PL/SQL,Cobol,JavaScrip,Groovy等等二十几种编程语言的代码质量管理与检测
为什么选择Sonar
1417331539622

Developers' Seven Deadly Sins
1.糟糕的复杂度分布
文件、类、方法等,如果复杂度过高将难以改变,就会难以理解。同时,一般来说代码越复杂,就越容易出错。而且如果没有自动化的单元测试,对于程序中的任何组件的改变都将可能导致需要全面的回归测试。
1417331808057
2.重复
显然程序中包含大量复制粘贴的代码是质量低下的。
sonar可以展示源码中重复严重的地方
1417331842140
3.缺乏单元测试
sonar可以很方便地统计并展示单元测试覆盖率
1417331932006
4.代码覆盖
5.代码标准
sonar可以通过PMD,CheckStyle,Findbugs等等代码规则检测工具规范代码编写。
sonar还支持多种语言C#,Java,Python,Android等
6.潜在问题代码
7.设计及注释架构
1417332324322
8.比较
可以根据基于指标,项目间的比较
1417333166557

1417332851029
9.扩展性
sonar的集成是通过插件来扩展的。跟其他工具的集成

1417332473801


sonar支持的开发扩展

简单介绍下Jenkins

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
1417351747340

十.实践

工具:TFS+jenkins+sonar
TFS 作为版本控制的核心
jenkins 自动化构建的关键
sonar 静态检测的执行者,代码质量反馈的中心
NUnit(推荐)或MSTEST 作为单元测试工具
依赖管理
工具:Nuget

  • 相关文章
发表评论
用户名: 匿名