21、持续集成对本科团队项目构建健康的影响

持续集成对本科团队项目构建健康的影响

1. 持续集成系统与相关指标

在软件开发中，持续集成（CI）系统有一些明确提及的指标，如构建失败的时间比例和夜间失败构建的数量。不过，这些指标通常用于评估学生的项目表现，而非评估课程的实用性。

还有一个有趣的提议是 Prof. CI 系统，它用 CI 工具取代了常见的基于浏览器的编码环境，主要用于教授测试驱动开发（TDD）。该系统的作者通过比较两组学生的数据来了解这种方法的优缺点，但他们更关注编写测试的数量和质量相关指标，而非构建健康状况。目前，还没有人尝试评估学生在使用和不使用 CI 工具的情况下管理构建健康的能力。

2. 曼彻斯特大学课程中的工具选择

在曼彻斯特大学的软件工程课程中，大二第一学期的课程要求学生对一个大型开源代码库进行多次更改，并使用一系列最佳实践工具和技术，以确保发布的代码没有明显缺陷。经过与学校行业俱乐部成员的协商，为学生选择了以下工具集：
- 分布式版本控制系统（Git，git-scm.com）
- 问题跟踪器（GitLab 问题跟踪器，gitlab.com）
- 自动化测试工具（JUnit，junit.org）
- 代码覆盖率工具（JaCoCo，jacoco.org）
- 代码审查工具（GitLab，gitlab.com）
- 自动化构建工具（Ant，因为使用的开源软件基于它，ant.apache.org）
- 持续集成服务器（Jenkins，jenkins.io）

为了管理引入众多新技术给大量学生带来的风险，决定分三个连续的学生群体逐步引入 CI 系统，具体如下：
| 学生群体 | 引入情况 |
| ---- | ---- |
| 第一组 | 为每个学生团队设置了 CI 构建，但不对本科生可见，仅由课程工作人员和助教使用，用于评估团队的构建健康状况并提供反馈。 |
| 第二组 | 为每个学生团队设置相同的构建任务模式，并允许他们在截止日期前查看结果，以便在评分前进行最终修改以解决重大构建健康问题。 |
| 第三组 | 从每个课程作业开始就为所有团队提供 CI 构建作业结果的访问权限，还提供了真正的持续集成，即设置构建将功能分支与开发分支合并并报告结果。 |

3. 构建任务设置

对于每个团队和每个课程作业，设置了以下几种构建任务：
- 标记练习起始提交的标签构建：帮助团队查看练习开始时构建是否存在问题，避免早期练习的问题影响当前练习和最终发布构建。
- 练习发布标签的构建：学生需确保该构建干净编译并通过所有测试，否则会扣分。
- 开发分支的构建：学生应尽量保持该构建干净编译并通过测试，但由于很多学生是首次考虑构建健康，只要不影响发布构建健康，未达要求不扣分。
- 每个功能分支的构建：学生需确保功能分支干净编译并通过所有测试，仅在功能分支合并到开发分支时，未达要求会影响评分。

使用 Jenkins 持续集成服务器，构建任务的状态通过图标表示：
- 圆圈中的感叹号图标：表示构建失败，通常是编译错误导致无法创建可执行代码。
- 三角形中的感叹号图标：表示构建不稳定，可执行代码已创建并执行，但某些质量指标显示存在问题，如自动化测试失败。
- 圆圈中的对勾图标：表示构建成功，可创建可执行文件，且所有测试和质量检查都通过。

4. 实验设计

课程中逐步引入 CI 工具为研究 CI 对本科生构建健康的影响提供了自然实验的条件。在所有三个学生群体中，发布构建健康状况都纳入了作业评分体系（约占每个作业评分的 10%），开发分支和功能分支在合并时的构建健康状况也有一定考量。

早期群体的学生需要在将代码提交到 Git 仓库之前，通过在本地仓库运行构建脚本和测试来检查代码健康状况。虽然学生使用集成开发环境（IDE）管理代码时会有编译错误的自动警告，但其他构建错误和失败测试只能通过手动运行自动化构建脚本来发现。

而最新群体的 CI 服务器会在每次推送到远程仓库时检查构建健康状况，并为学生团队提供各阶段的清晰报告。学生只需在推送代码后登录检查结果，且团队成员的推送结果对整个团队可见，只要有一名成员定期检查结果，团队就能提前收到问题预警。第二组学生只能在截止日期前查看 CI 报告，仅能对发布构建的健康状况进行最终管理。

通过比较不同群体的构建健康模式，希望了解对 CI 构建报告的访问程度与构建健康之间的相关性，以及为 200 多名学生配置和运行 CI 服务器的努力是否带来了有用的教育效益。

5. 数据收集流程

为了理解引入 CI 工具对学生的影响，需要比较有 CI 访问权限和没有 CI 访问权限的学生群体的详细构建健康记录。第三组学生的构建健康数据可以通过 Jenkins 提供的 API 轻松提取。但对于没有全程使用 CI 的群体，需要重建他们如果从一开始就使用 CI 会看到的构建健康报告。

数据提取流程如下：

graph LR
    A[确定应构建的提交] --> B[创建标签]
    B --> C[生成 Jenkins 作业 DSL 脚本]
    C --> D[运行构建]
    D --> E[提取构建结果并分析]

具体步骤为：
1. 确定如果当时设置了 CI 服务器，哪些提交会被构建，即每个团队成员推送到远程 Git 仓库的每个分支的尖端提交。对于部分群体，可以从学校 GitLab 服务器自动维护的活动日志中提取此信息；对于早期群体，由于系统升级日志丢失，第二组的日志因作业自动评分软件缓存得以保留，第一组则通过 Git 数据库对象的时间戳重建推送信息。
2. 使用后端脚本在每个提交处创建标签，标签格式为“SELA/<提交 SHA>”，以唯一标识每个推送点。
3. 创建标签后，使用第二个脚本读取每个仓库，搜索标签，并使用 Jenkins Job DSL 为每个标签创建脚本，从而自动创建大量 Jenkins 构建作业。
4. 由于要运行的构建数量众多（超过 20,000 个），分阶段运行构建。完成一个群体的构建后，运行另一个脚本从 CI 服务器提取构建结果（使用提供的 API）并加载到电子表格中进行分析。

6. 实验结果

6.1 整体构建健康管理能力

通过观察每个群体在每个练习中创建的构建总数，并按构建结果（失败、不稳定和成功）分类，可以发现以下趋势：
- 所有群体在整个学期中的推送次数都增加，这可能是因为练习规模逐渐增大，学生对使用 Git 进行团队编码的信心也有所提高。
- 所有群体在整个学期中成功构建的比例都有所增加，尤其是至少部分访问 CI 的群体，全程访问 CI 的群体效果最为明显。这表明学生在看到 CI 构建结果之前就已经学会更好地管理构建健康，而不仅仅是被动修复 CI 服务器报告的问题。
- 即使在最后一个练习和完全访问 CI 的群体中，仍然存在大量失败和不稳定的构建。这是因为 CI 工具只能在代码到达远程 Git 仓库时检测到失败构建，不能从根本上防止这些问题，而且学生需要主动访问 CI 构建系统报告。对于最后一组，虽然提供了构建失败的电子邮件通知，但只有少数团队使用。

6.2 整体构建健康管理能力的分布

之前的构建总数数据只能提供各群体在整个学期中构建健康管理的总体情况，无法显示群体内能力的分布。为了了解这一点，创建了图表展示每个群体中各个团队创建的不成功构建（包括中止、失败或不稳定的构建）的百分比。

从图表中可以看出，随着学期的推进，每个群体的平均不成功构建百分比都有所下降，学生在管理构建健康方面逐渐熟练（无论是否使用 CI）。有 CI 访问权限的群体有所改善，但可能没有达到预期。第三组的平均不成功构建数量在所有练习中约为 50% 或更低，但仍然有很多失败的构建，而且表现最好的团队与第一组表现最好的团队相比，提升并不显著。

6.3 发布构建健康管理能力

综合前面的结果，CI 工具似乎有助于学生管理构建健康，但仍有许多不成功的构建。当关注学生在每个练习结束时发布的代码的健康状况时，情况更加清晰。

比较不同群体的发布构建结果可以发现，与没有 CI 设施时相比，提供 CI 设施后有明显改善。虽然所有群体都有一些团队发布了有问题的代码，但在学期结束时能够发布干净代码库的团队比例在有 CI 时显著提高。对于第三组学生，这种改善尤为明显。

6.4 结果总结与分析

综合上述各方面的结果，我们可以对 CI 工具在本科团队项目中对构建健康的影响有一个较为全面的认识。以下是对各项结果的总结与分析：

评估维度	结果表现	分析
整体构建健康管理能力	- 推送次数随学期增加 - 成功构建比例上升，CI 群体更明显 - 仍存在大量失败和不稳定构建	- 练习规模增大和学生信心提升导致推送增加 - CI 有助于学生主动提升构建健康管理能力 - CI 不能完全防止构建问题，学生需主动使用
整体构建健康管理能力分布	- 各群体平均不成功构建百分比下降 - CI 群体有改善但未达预期 - 最佳团队提升不显著	- 学生逐渐适应构建健康管理 - CI 引入效果有限，可能受多种因素影响
发布构建健康管理能力	- 提供 CI 设施后有明显改善 - 第三组学生改善尤为明显	- CI 对最终发布代码的健康状况有积极影响 - 持续且全面的 CI 访问更有利于提升发布构建质量

从这些结果可以推测，CI 工具在一定程度上帮助学生提高了构建健康管理能力，但并没有带来革命性的变化。可能的原因包括学生对 CI 工具的使用不够主动、CI 工具本身的局限性以及课程中其他因素的影响等。

6.5 对教学的启示

基于实验结果，对于在本科软件工程教学中使用 CI 工具有以下几点启示：
- 加强教育引导 ：学生对 CI 工具的主动使用不足，需要在教学中加强对 CI 工具重要性的教育，引导学生养成主动查看 CI 报告、及时处理构建问题的习惯。例如，可以在课程中设置专门的环节讲解 CI 工具的使用方法和优势，布置相关的作业让学生实践。
- 优化工具配置 ：CI 工具虽然能检测问题，但不能完全防止问题的发生。可以进一步优化 CI 工具的配置，增加更多的预检查机制，在代码提交到远程仓库之前就发现潜在问题。比如，在本地开发环境中集成一些简单的静态代码分析工具，与 CI 工具形成互补。
- 结合其他教学方法 ：CI 工具只是教学中的一部分，不能完全依赖它来提升学生的构建健康管理能力。可以结合其他教学方法，如代码审查、小组讨论等，让学生在多方面的学习和实践中提高能力。例如，定期组织小组代码审查活动，让学生互相发现和解决构建问题。

7. 结论

通过本次研究，我们对 CI 工具在本科团队项目中对构建健康的影响有了深入的了解。逐步引入 CI 工具为研究提供了自然实验的机会，通过对三个不同学生群体的构建健康数据进行收集和分析，得出以下结论：
- CI 工具在一定程度上有助于学生管理构建健康，提高成功构建的比例，尤其是在发布构建的健康管理方面有明显改善。
- 然而，CI 工具并没有带来预期的革命性变化，仍然存在大量失败和不稳定的构建，学生对 CI 工具的主动使用不足是一个重要原因。
- 在教学中，需要加强对 CI 工具的教育引导，优化工具配置，并结合其他教学方法，以更好地提升学生的构建健康管理能力。

未来的研究可以进一步探索如何提高学生对 CI 工具的使用积极性，以及如何结合更多的技术和教学方法来优化 CI 工具在本科教学中的应用，从而更好地培养学生的软件工程实践能力。

graph LR
    A[引入 CI 工具] --> B[数据收集与分析]
    B --> C[评估构建健康影响]
    C --> D[得出结论与启示]
    D --> E[指导教学改进]

以上流程图展示了本次研究的整体流程，从引入 CI 工具开始，经过数据收集和分析，评估其对构建健康的影响，得出结论和启示，最终用于指导教学的改进。通过这样的研究和实践，有望不断提高本科软件工程教学的质量，培养出更具实践能力的学生。