持续集成术语解释
Continuous Integration(持续集成):持续集成要求开发人员频繁地提交他们的所完成的工作产品,这个频率通常是至少每天一次,有时候可以多次。每次集成会通过自动化构建(automated build)的方式进行尽量快速地验证,以确保新提交的变化不会造成新的问题。如果在集成的过程中出现异常,则应当快速的反馈给相关的人员。
Build(构建):构建是将源代码放在一起,并验证软件可以作为一个一致的单元运行的过程;验证活动一般包括编译、测试、审查和部署。
Build Tool(构建工具):用于执行构建过程的工具称为构建工具,它通过执行构建脚本实现自动化的编译、测试、审查和部署。Make是所有构建工具之祖,它向我们展示了依赖关系检查和增量式构建,Make可以通过选项用于构建任何语言编写的软件;其他常见的构建工具往往和语言相关,例如Ant:Java、NAnt:.NET、Maven:java、Rake:Rake。
Daily Build / Nightly Build/Weekly Build:每天/每晚/每周 做一次构建。
Daily Run(每日执行):每天都对系统的某一个或几个版本运行自动化的测试。
Build Verification Testing:验证Build是否成功,它是进行后续测试工作的前提。 随着软件功能越来越完整和稳定,BVT会逐步加入一些成熟的自动化测试脚本。
Single BranchTrunkMainline:对于一个产品的源代码测试代码配置数据,在配置库中以单一主干(truck)的方式统一管理。
Release Branch(发布分支):当开发主干中含有某个发布版本所计划的特性时,便可以从主干中拉出一个发布分支用于支持该特定发布版本。一般来说,在发布分支中主要是进行bug修复以及版本发布元数据(例如版本号,构建日期等等)的准备工作,不允许增加新的功能代码。
Hotfix branch(热补丁分支):当已发布或上线的版本出现重大bug需要立即解决的时候,便可以从对应版本的标签创建出一个热补丁分支。热补丁分支和发布分支十分类似,它的目的也是发布一个新的产品版本,尽管是不在计划中的版本发布。使用热补丁分支的主要作用是让在热补丁分支上进行快速的产品bug修复的同时,尽可能减少对其他开发人员的影响。
Feature branch(特性分支)/topic branch(主题分支):特性分支(有时也被称作topic分支)是用于开发某一个特性集而从主干中拉出的分支; 特性分支的重点是,只要特性还在开发,该分支就会一直存在,不过它最终会被合并回主干(将该特性加入到某个计划发布版本中),或者被丢弃(如果试验的结果令人失望)。
Local Build(本地构建):将变更提交到版本控制库之前,在RD开发机上执行的本地构建,目的是尽可能避免因为check in动作而导致主干被破坏。
Build Pipeline (构建管道)/staged build(分阶段构建):构建管道,即多个构建按一定顺序执行。一般先运行轻量级的构建,再运行更大范围、耗时更长的构建,通常是指那些较慢的功能/集成/系统测试。
Version Control System(版本控制系统):提供一个受控的访问库来管理源代码和其他软件资产(如文档)的变更,让开发者以及项目相关人员能够有效管理软件版本。版本控制系统能够让您按时间回溯,取得源代码和其他文件的不同版本。常用的版本控制软件有SVN,CVS,GIT等。
Continuous Integration Server(持续集成服务器):CI Server自动完成软件代码的构建过程。CI服务器可以根据设定的触发机制(代码变更、定时等)自动地去完成构建过程。目前已知的各种CI Server不下几十种,其中比较常见有Hudson、CruiseControl、TeamCity、Pulse、Anthill, Bamboo等。
抱歉,暂停评论。