持续集成调研报告（1）
持续集成（CI）调研报告
⼀． 持续集成的价值
1. 持续集成中的任何⼀个环节都是⾃动完成的，⽆需太多的⼈⼯⼲预，有利于减少重复过程以节省时间、费⽤和⼯作量。
2. 持续集成保障了每个时间点上团队成员提交的代码是能成功集成的。换⾔之，任何时间点都能第⼀时间发现软件的集成问题，使任意时间发布可部署的软件成为了可能。
3. 持续集成还能利于软件本⾝的发展趋势，这点在需求不明确或是频繁性变更的情景中尤其重要，持续集成的质量能帮助团队进⾏有效决策，同时建⽴团队对开发产品的信⼼。
4. 在⼀天中进⾏多次集成，可以减少项⽬的风险，这样做有利于检查缺陷，了解软件的健康状况，减少假定。
5. 增强项⽬的可见性。
6. 使开发团队建⽴起更强⼤的产品信⼼。
⼆． ⼯作机制与⼯作过程
2.1 ⼯作机制图表
2.2 ⼯作步骤如下
1. 开发者向版本控制库提交代码，与此同时，集成构建计算机上的CI服务器正在轮询检查版本控制库中的变更（可以设置为实时轮询或定时监控）。
2. 在提交发⽣之后，CI服务器检测到版本控制库中发⽣了变更，所以CI服务器会从库中取得最新的代码副本，执⾏构建的脚本，该脚本将对软件进⾏集成。包括⼀系列的编译，数据库集成，测试，审查，打包，部署。
3. CI服务器向项⽬组成员提供构建结果反馈信息（EMAIL，SMS等）
4. CI服务器继续轮询版本控制库中的变更。
2.3 ⼦过程描述
1. 源代码编译：持续的源代码编译是CI系统最基本、最常见的特征之⼀。
2. 数据库集成：在CI系统的构建过程中进⾏持续的数据库集成。当项⽬成员修改了数据库脚本并提交到SVN中时，集成源代码的构建脚本将重建数据库和数据，作为集成构建的⼀部分。
3. 测试：可以通过CI进⾏⾃动化的持续的测试。这些测试分类包括：单元测试，组件测试，系统测试，负载/性能测试，安全测试和其他测试。
4. 审查：⾃动化的代码审查（例如静态和动态分析），可以通过强制遵守规则来增加软件的品质。
5. 部署：CI可以将⽂件⾃动部署或安装到相应的环境中去。
6. ⽂档与反馈：定期⽣成⽂档，并及时向开发者和项⽬风险承担者提供反馈信息。
三． 持续集成遵循的原则
1. 经常提交代码：每天⾄少向版本控制库提交⼀次代码。
2. 不要提交⽆法构建的代码：不要提交⽆法编译或不能通过测试的代码。
持续集成的概念3. ⽴即修复⽆法集成的构建：修复构建过程中的错误是优先级最⾼的⼯作。
4. 编写⾃动化的开发者测试：利⽤⾃动化的开发者测试来验证软件。
5. 必须通过所有的测试与审查。
6. 执⾏私有构建：为了防⽌集成失败，先从版本控制库中取出其他开发者提交的最新变更，然后在本地执⾏完整的集成构建，这被称为私有系统的构建。
7. 避免签出⽆法构建的代码：如果集成构建失败，等待新的变更，帮助开发者修复⽆法集成的构建，然后再取出最新的代码。
四． 搭建CI环境说明
4.1 CI环境基本结构图
4.2 所需环境与⼯具
l 操作系统
l JDK
l Web服务器版本管理⼯具
l 构建⼯具
l CI服务器
l 构建管理仓库
环境的配置与搭建⽅式会进⼀步讨论与实践，在此不赘述。
初步决定具体采⽤的⼯具为：
Linux + JDK +Tomcat + Ant + Maven + Nexus + SVN + Jenkins。
五． 调研结果与下⼀步计划
已经初步对持续集成的概念，⼯作⽅式有了了解，如何利⽤持续集成提⾼软件开发的质量与效率是需要我们验证的，对于⾃动构建，持续的数据库集成，持续测试，持续审查，持续部署，持续反馈的具体实现⽅式也需进⼀步研究与实践，由测试和质量管控的⾓度来衡量，测试与审查是需要主要关注的部分。会在这⼀⽅⾯多加关注。
下⼀步会先搭建起CI的环境。
针对本项⽬利⽤CI想达到四个⽬的：
1. 集成组件（从版本控制库取得最新的变更并进⾏编译）
2. 完成⾃动化测试，执⾏所有单元测试集，并⾃动化执⾏回归测试，包括功能测试、集成测试、负载测试和性能测试。
3. 执⾏其他⾃动化的过程：重建数据库，审查和部署。
4. 利⽤CI降低本项⽬风险，并做到辅助项⽬管理的⼯作。
部分内容参考《持续集成软件质量改进和风险降低之道》《持续集成在软件项⽬管理中的作⽤》《基于jenkins的持续集成使⽤指南》等书籍或⽂章。
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论