您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  要资料 文章 文库 Lib 视频 Code iProcess 课程 认证 咨询 工具 火云堂 讲座吧   成长之路  
会员   
 
   
 
  
每天15篇文章
不仅获得谋生技能
更可以追随信仰
 
     
   
 订阅
  捐助
持续集成方案
 
238 次浏览     评价:  
 2017-12-5 
 
编辑推荐:
本文来自于博客园,文中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的实践。与需要组装所有的依赖和状态相比,使用模拟技术的测试运行起来通常是非常快,这样子开发人员在提交代码之后,可以在持续集成平台快速得到反馈。

实践

常规

Hello World!

一个加密、解密方法的测试

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 作为单元测试工具

   
 订阅
  捐助
相关文章

为什么要做持续部署?
剖析“持续交付”:五个核心实践
集成与构建指南
持续集成工具的选择-装载
相关文档

持续集成介绍
使用Hudson持续集成
持续集成之-依赖管理
IPD集成产品开发管理
相关课程

配置管理、日构建与持续集成
软件架构设计方法、案例与实践
单元测试、重构及持续集成
基于Android的单元、性能测试
每天2个文档/视频
扫描微信二维码订阅
订阅技术月刊
获得每月300个技术资源
 
 

关于我们 | 联系我们 | 京ICP备10020922号 京公海网安备110108001071号