问候,同事们!厌倦了强迫您的计算机不断构建项目?那么这篇文章适合您! 在这篇文章中,我将尝试简要而清晰地介绍有关持续集成(以下简称 CI)的材料,我将回答诸如“它是什么?”、“为什么?”之类的简单问题。为什么?” 我将给出一个测试项目的例子。本文面向有经验的用户,至少熟悉构建系统:Maven,知道如何使用Git,并知道如何将项目推送到GitHub;
“什么是持续集成?”
让我们看看Wiki是如何回答这个问题的: 持续集成(CI,英文 Continuous Integration)是一种软件开发实践,包括每天多次将工作副本合并到公共主开发分支中,并为早期项目执行频繁的自动化构建。检测潜在缺陷并解决集成问题。 很可怕,不是吗?让我们尝试用简单的语言解释这个术语: 持续集成是一种用于在某些机器上使用某些配置构建和自动测试软件的系统,以检测错误和不兼容性。 好吧,没问题,我们已经弄清楚了,但是出现了以下逻辑问题:为什么我们需要 CI?
让我们假设您正在编写一个大型项目,并且需要添加/更改功能。您成功编写了它,编写了测试,启动了它,一切似乎都很好,但事实并非如此。在某些情况下,一个功能的更改会影响另一个功能,另一个功能会影响第三个功能,依此类推,直到错误出现在某个地方并发生错误。是的,你可以说这很可能是一个设计糟糕的项目,你可能是对的,但如果不是,而且这些连接真的应该存在呢?如果您多次编写和创建一个项目(这种情况经常发生)怎么办?您对新编写的功能进行了测试,并且得到了积极的结果。你很快就做出了承诺,然后推到了某个地方,并且已经在考虑如何在家抽雪茄,喝昂贵的威士忌,但没有。唉,你的同事或老板,无论是谁,都会说由于你的提交,整个构建崩溃了。你一脸茫然地说你是一名程序员,你什么都测试过。但通常根本没有时间不断测试整个项目,并且您只测试了所做更改的代码段,而不是整个程序集。这就是 CI 为我们提供帮助的地方。每次推送任何资源时,CI 都会从头开始构建您的项目,运行所有测试,并且只有当所有测试通过并且项目构建完成时,构建才会收到通过状态。否则你就有机会东山再起,看看到底出了什么问题。因此,是时候问一个问题“为什么是这样而不是其他情况?” 并看看软件的实现。 示例 正如我已经说过的,本文面向那些熟悉 Maven 和 Git 的人。因此,我希望你知道除了设置 CI 等之外我是如何做的以及做什么。-
首先,让我们创建一个简单的 Maven 测试项目,并在其中创建一个打印“Hello World!”的类。并执行一些简单的操作,让我们为这个类编写最简单的测试。
因此,我们应该有一个原始的项目结构:
所有来源都将在我的 GitHub 上。你在 Main 中写什么以及会有什么测试并不重要。
-
我们将项目推送到 GitHub。
-
有趣的来了。对于 CI,我选择了Travis CI,因为它的可用性和可靠性。Travis 使用 GitHub 托管其源代码。
因此,访问Travis CI网站并通过 GitHub 登录。在配置文件中我们连接我们的项目:
每次按下按钮时,一切都已准备好进行组装,但问题是如何组装?
-
我们回到我们心爱的 IDEA 并创建一个.travis.yml文件
该文件负责 Travis 构建配置。让我们看看最流行的设置:
- 您需要指定项目实施的语言;
- 指定目录的路径以使构建更快;
- 指定有关组装成功或不成功的通知方法。
典型的 Travis 配置应该是这样的:
# https://docs.travis-ci.com/user/languages/java/ language: java jdk: oraclejdk9 # Improve Build Speed https://dzone.com/articles/travis-ci-tutorial-java-projects cache: directories: - $HOME/.m2 # Notifications https://docs.travis-ci.com/user/notifications/ notifications: email: recipients: - qThegamEp@gmail.com on_success: always # default: change on_failure: always # default: always
为了清楚起见,我添加了带有链接的评论。
-
我们再次推送到 GitHub 并打开Travis网站,选择项目并监控构建。结果,我们收到有关构建成功的通知:
另外,在该网站上,我们可以看到一个徽章,其中包含我们项目的成功组装,我们可以将其插入到我们的 README.md 中:
GO TO FULL VERSION