持续集成基础-丁晓刚.pptVIP

* 推荐读物和网站 /display/HUDSON/Home 《maven实战》 pro?git(中文版) /progit/ 开源社区： / / /hosting/ 软件构建、构建检查、构建测试、生成文档、打包软件、部署构件等。 减少风险（一天中进行多次的集成，并做了相应的测试，这样有利于检查缺陷，了解软件的健康状况，减少假定。） 减少重复过程（节省时间、费用和工作量，包括代码编译、数据库集成、测试、审查、部署及反馈） 任何时间、任何地点生成可部署的软件（出错代码容易找到负责人并修复，避免引入新的缺陷） 增强项目的可见性（(1)有效决策：持续集成系统为项目构建状态和品质指标提供了及时的信息，有些持续集成系统可以报告功能完成度和缺陷率。 (2)注意到趋势：由于经常集成，我们可以看到一些趋势，如构建成功或失败、总体品质以及其它的项目信息。） 私有构建是由开发人员个人在他们自己的工作区中手工执行的，以对他们正在开发的组件进行构建和单元测试。 集成构建是由集成员在一个集中工作区执行的，通常是手工的。在持续集成中，要促进频繁的变更集成，构建有必要是自动的，并且是由工具来执行的。通常，持续集成构建的结果并不部署到顾客或产品环境中；相反，要手工执行一个额外的发布构建，并且要十分小心。 集成环境的操作系统、服务器、容器、IP地址等都和本地不同，所以测试是必须的； 发布构建通常是必须的，你可以准确地到构建的输入（例如变更请求，故障），并且在一个单独的受控环境（例如，一个单独的工作区）中执行构建。这使你能在同一时间继续集成构建，并为了审计和追踪的目的，记录发布构建的准确内容。 中央储存库：必威体育精装版的代码（至少）、必威体育精装版的可执行程序 集成构建服务器：包含CI应用程序和工作版本执行的地方，构建仓库里的代码 只要把hudson.war部署到servlet容器，不需要数据库支持。 通过RSS发布构建结果或当构建失败时通过e-mail实时通知。 能多台计算机一起构建/测试 Hudson能够跟踪哪次构建生成哪些jar，哪次构建使用哪个版本的jar等。 只需要会编写构建文件，就可以很轻松地让其完成持续集成 任务。 换言之，hudson 的使用并不难掌握，真正需要学习的是一些如ant 或maven 等基本的工具。 1、你的IDE能运行，项目到别人那里就会各种报错：找不到java sdk 找不到类库 2、网上下载一个开源项目，不清楚文件结构、不知道哪些是源码、测试代码，导入不了IDE，运行不了…… 3、引用的第三方类库更新了，然后你下载下来，麻烦吗？然后下载下来发现运行项目报错，找了半天，发现是这个类库还要依赖其他类库，然后把其他类库下载下来… Maven鼓励使用标准目录布局，这样就不需要进行额外的配置，而且有助于各个不同工程之间的联接。 软件项目一般都有相似的开发过程：准备，编译，测试，打包和部署，Maven将上述过程称为Build Life Cycle 工作目录，它持有实际文件； 缓存区（Index），它像个缓存区域，临时保存你的改动； HEAD，指向你最近一次提交后的结果。 (Eclipse的配置针对于workspace，改workspace就要改相应配置) * 持续集成基础 MF1332011 丁晓刚 * 集成软件过程 小规模 大规模 如个人项目； 外部依赖小； 集成需求小； 配置过程少； 结构相对简单 如大型网站； 复杂度高； 配置繁琐； 项目间依赖多； 集成频繁； 集成要求高； 项目风险和质量要求； 开发周期长 * 持续集成 (Continuous Integration) 由工具支持的集成软件过程，全自动化和可再生的构建，包括编译、发布、自动化测试。以减少集成问题，每次集成都通过自动化的构建来验证，尽快地发现集成错误。 * 环境中的持续集成 * * Hudson(Jenkins) 一个开源的可扩展的持续集成引擎 主要用于： 持续、自动地构建/测试软件项目 监控一些定时执行的任务 * 优点 易于安装 WEB界面易配置 集成RSS/E-mail/IM，反馈方便 自动生成JUnit/TestNG测试报告 支持分布式构建 文件识别 可扩展，插件丰富 * * 程序员的时间都去了哪儿？ 数据显示，开发者20%的时间花在了....“等”上： 等代码编译完成； 等测试流程跑完； 等同事帮他们买可乐和零食..... 所以，自动化构建是相当重要的。。。 * Maven 一个能够帮我们自动化构建过程，从清理、编译、测试到生成报告，再到打包和部署的构建工具。 * 标准目录布局 目录 目的 根目录 存放 pom.xml和所有的子目录