weex社区@IT·互联网

持续集成系统使用说明

2016-09-08  本文已影响439人  cpu_driver

概述

1.说明

本文档共有四部分组成:

2.什么是持续集成

持续集成是一种软件开发实践,即团队开发成员经常集成它们的工作,通过每个成员每天至少集成一次,也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建(包括编译,发布,自动化测试)来验证,从而尽早地发现集成错误【百度百科】。

持续集成是敏捷软件开发工作当中的一大组成部分。从一轮冲刺到下一轮冲刺,技术团队在“不断前进”的同时持续推出各类增量化功能。不过当开发人员高度专注于添加功能的同时,代码错误有时候也会不期而至、并导致软件无法正常使用。为了阻止此类错误被集成至软件配置管理(简称SCM)方案当中,持续集成服务器则扮演守门人的角色,帮助我们对代码质量进行把关。即使糟糕代码已经被集成到SCM当中,持续集成服务器仍然能够快速告诉我们是哪里出了问题。

虽然持续集成工具能够扮演守门员的角色,但是还是希望开发人员在开发的时候,尽量避免error级的错误被提交进集成工具中。避免这一问题的唯一办法是,当我们提交代码到svn时,至少在本地是测试通过的。

关于更广泛的阅读,可以看一下阮老师的博客 http://www.ruanyifeng.com/blog/2015/09/continuous-integration.html

3.持续集成能给我们的好处

3.1. 减少风险

一天中进行多次的集成,并做了相应的测试,这样有利于检查缺陷,了解软件的健康状况,减少假定。

3.2. 减少重复过程

通过自动化的持续集成可以将集成中重复的动作都变成自动化的,无需太多人工干预,让人们的时间更多的投入到动脑筋的、更高价值的事情上。

3.3. 任何时间、任何地点生成可部署的软件

持续集成开发可以在任何时间发布可以部署的软件。利用持续集成,可以经常对源代码行一些小改动,并将这些改动和其他的代码进行集成。如果出现问题,项目成员马上就会被通知到,问题会第一时间被修复。不采用持续集成的情况下,这些问题有可能到交付前的集成测试的时候才发现,有可能会导致延迟发布产品,而在急于修复这些缺陷的时候又有可能引入新的缺陷,最终可能导致项目失败。

3.4. 增强项目的可见性

持续集成让我们能够注意到趋势并进行有效的决策。

持续集成可以带来两点积极效果:

4.持续集成的一般步骤(适用于咱们公司)

4.1 开发者端的测试

开发者自检,排除明显的bug,语法错误

4.2 提交svn代码库

把代码提交到相应的svn库上

4.3 sonar检测代码

利用sonar的java语言检测工具,检测开发者所写java代码的质量。

4.4 hudson自动部署

Hudson利用maven工具进行打包,并把打好的包交给tomacat进行部署

5.持续集成的工具

6.技术负债

术语”技术债务“是由Ward Cunningham首次提出,指的是开发团队在设计或架构选型时从短期效应的角度选择了一个易于实现的方案,但从长远来看,这种方案会带来更消极的影响,亦即开发团队所欠的债务。敏捷专家们就技术债务到底是什么以及如何对其进行分类给出了自己的看法。

Martin Fowler认为下面的定义最能表现技术债务的含义:

技术债务类似于金融债务,它也会产生利息,这里的利息其实就是指由于鲁莽的设计决策导致需要在未来的开发中付出更多努力的后果。我们可以选择继续支付利息,也可以通过重构之前鲁莽的设计来将本金一次付清。虽然一次性付清本金需要代价,但却可以降低未来的利息。

Steve McConnell将技术债务分为两类:

  • 无意的——由于经验的缺乏导致初级开发者编写了质量低劣的代码。

Bob大叔补充到,有时人们将坏味道也看作是技术债务,但这是错误的,他说:

坏味道并非技术债务。坏味道就是坏味道。技术债务的评价标准是真实的项目约束,这些约束是风险和好处并存的。坏味道的产生永远都不是理性的结果,而是由懒惰和外行导致的,未来也没有机会偿还了。坏味道总是意味着损失。
Bob大叔说技术债务让人们时刻牢记保持代码的整洁,就好像一个人在背负巨大的抵押债务时需要时刻保持警醒一样。他又说一旦团队决定采纳技术债务,那就意味着保持代码的整洁将变得空前的重要。如果不这样,情况很快就会变得糟糕不堪,偿还这些债务的代价也变得越来越大。

Martin Fowler认为坏味道也是技术债务,只不过是另一种形式的技术债务而已。

他觉得坏味道是一种不计后果(reckless)的债务,相对于根据精确计算而得来的谨慎的(prudent)债务而言,坏味道会让问题变得更加严重。他又加上了故意(deliberate)以及无意(inadvertent)从而将技术债务划分为四个象限。

Martin通过如下示例将技术债务划分为4个象限:

  • 1.不计后果,故意的——团队没有时间做设计,仅仅给出了一个匆忙做出的方案,缺乏对质量的预见。

自动化代码质量管理工具sonarqube

1. Sonarqube是什么?

SonarQube is an open platform to manage code quality. As such, it covers the 7 axes of code quality:

相关名词

2. Sonarqube在持续集成系统中的作用

对于团队管理人员来说,它能够发现bug,给出修改bug相关的评估,比如用时。

3. Sonarqube 查看代码缺陷

持续集成工具hudson

1.Hudson是什么?

Hudson 是一款能够执行在软件工程过程中出现的一些重复的工作。比如,频繁的编译和打包。

2.Hudson在持续集成系统中的作用

整个系统的中枢地位:
(1 负责发现svn版本变化
(2 负责调取sonar进行代码质量检查
(3 负责执行调取maven构建
(4 负责进行工程部署
(5 负责通知相关人员是否部署ok
(6 如果部署失败,负责回滚部署

3.Hudson 用于自动化编译与构建

1.添加工程

2.配置工程

3.核心配置参数讲解(供管理人员参考)

A 构建触发策略配置

第一个选项,是指当此工程依赖别的工程的时候,如果别的工程重建后,里面重建这个工程。
第二个选项,是指由脚本文件控制控制构建机制,
第三个选项,是指指定时间进行构建,如:每周4,0点0分进行构建

第四个选项,是指当svn版本变化后多长时间进行构建,如:当svn有变化时,立马执行构建

B Hudson中sonar的配置

一个自动化代码检查-编译-部署的例子

演示一个工程如何加进持续集成系统。

演示步骤要点:

上一篇 下一篇

猜你喜欢

热点阅读