CI如何用于解释语言?


23

我以前从未使用过持续集成系统(CI)。我主要使用MATLAB,Python或PHP进行编码。这些都没有构建步骤,我看不到如何将CI用于我的工作。一家大型公司的大型项目中的一位朋友告诉我,语言并不重要。

如果没有构建步骤,我看不到CI对我有什么用。我可以将CI视为可以运行单元测试的测试环境。我想念什么吗?



14
这是否成立取决于您认为“构建步骤”是什么。您似乎将其视为最低限度的编译,以使您可以运行。在我的团队中,我们认为构建是编译,静态分析和单元测试(还有更多任务的余地)。此定义的优点在于,无法通过单元测试的提交不会“构建”,并且不允许从开始就进入仓库。
克里斯·海斯

基于Chris的观点,CI系统可以并且应该测试任何和所有自动化测试-编译和链接可以看作是自动化测试的一种形式。如果您有资源限制,则某些较慢的测试可能仅在夜间构建或周末构建上运行,但CI将运行它们。问问自己:为什么要自动化测试,但仍要手动运行自动化测试?
彼得-Unban罗伯特·哈维

Answers:


32

持续集成这个术语是指两个不同的想法。

首先是工作流:不是团队中的每个人都在自己的分支上工作,而是经过几周的编程尝试将其更改合并到主线中,然后才(几乎)连续地集成更改。这样可以使问题尽早出现,并避免不兼容的更改。但是,这要求我们可以轻松地检查更改是否“有效”。

这是第二个想法出现的地方,事实证明它更受欢迎。CI服务器是一个干净的环境,在该环境中尽快对更改进行了测试。干净的环境是必需的,以便可复制该构建。如果它可以一次工作,那么它应该总是可以工作。这样可以避免“但它对我的机器有效”的问题。当您的软件在不同的系统或不同的配置上运行并且您需要确保一切正常时,CI服务器尤其有用。

缺少构建步骤是无关紧要的。但是,只有在拥有测试套件的情况下,CI才有意义。该测试套件必须是自动的,并且必须没有故障。如果测试失败,则适当的开发人员应收到通知,以便他们可以解决所引入的问题(即使没有编译版本,也“破坏了构建”)。

事实证明,这样的服务器不仅对测试有用,还具有更多的价值。实际上,大多数CI软件都无法在各种配置下运行测试,但是擅长管理各种作业。例如,除了“连续”单元测试外,每晚还可能需要进行完整的测试。该软件可以使用多个Python版本和不同的库版本进行测试。可以对网站进行无效链接测试。我们可以在代码上运行静态分析,样式检查器,测试覆盖率工具等。可以生成文档。当所有测试套件通过时,可以启动打包过程,以便您准备发布软件。这在您始终需要可部署(可演示)产品的敏捷设置中很有用。随着Web应用程序的兴起,还有不断部署的想法:如果所有测试都通过,我们可以自动将更改推入生产阶段。当然,这要求您对测试套件非常有信心(如果没有,则存在更大的问题)。


3
“只有在拥有测试套件的情况下,CI才有意义”-请注意,对于已编译的语言,编译器本身是一个基本的测试套件,可捕获许多常见错误。
user253751 '16

@immibis我认为这与编译与解释无关,而与静态类型有关。具有静态类型系统的语言可以自动证明某些正确性属性。这甚至比仅通过示例工作的测试更好。CI服务器在进行编译时发现的唯一常见问题是开发人员忘记提交新文件。在所有其他情况下,我们实际上并不需要CI服务器,而只需在本地编译以检查错误。
阿蒙

1
@amon不正确。进行最后一分钟的更改,然后在提交之前忘记测试编译,这种情况并不少见。当您对本地已全局安装但未在其他任何地方安装的内容添加依赖项时,也会遇到问题。
jpmc26 2016年

24

的确,您并不需要CI系统来执行构建并检查那些构建是否正确,但这只是CI的一部分。

CI的目的是尽快发现错误,因为通常来说,越早发现错误,修复它的成本就越低。为此,在不需要构建步骤的情况下,CI系统仍可以自动使用代码分析工具,部署到测试环境,可以自动化的单元/集成/回归/其他测试以及任何其他步骤您可以自动执行以检查错误。


8
我要补充:自动测试系统的最明显方法是自动执行它。例如,您可以使用JMeter或Selenium等工具测试网站。
reinierpost

7

持续集成不仅仅执行代码的编译。如果仅此而已,那么我们将不需要那么多的工具!

我可以想到的一些其他任务是持续集成管道经常执行的:

  • 执行自动测试。(Python有大量的自动化测试库,而PHP至少有一些。我不能与MATLAB对话。)
  • 捆绑分发软件。通过使该过程自动化,可以确保每次都以精确,一致,可重复的方式完成该过程。没有任何步骤会被遗忘;生成这样的分发程序包最多只需单击一下。(将Python应用程序捆绑在一起是一个好主意!)
  • 标记里程碑提交。每当您构建用于生产的软件包时,您可能都希望对其进行标记。
  • 自动递增版本号。通常,这只是“内部版本号”,而不是更有意义的部分,但是最好唯一地标识一个特定内部版本,这样您就可以知道部署在何处。

从严格意义上讲,在“持续集成”的边界上走得更远,您还可以执行以下操作:

  • 具有用于设置操作系统和安装依赖项的自动化过程。
  • 自动部署软件副本(主要用于Web应用程序或程序包管理器分发的软件)。有些团队实际上使用它来部署到生产(连续交付),但是即使您不这样做,您仍然可以利用它来部署额外的非生产代码副本。对于我工作的某些项目,我们有一个供开发人员在将其代码提供给QA之前测试其代码的副本,一个供QA进行测试的副本,以及一个用于演示目的的更“稳定”的副本。

重点很简单:除了编写代码外,在开发软件的过程中还必须定期执行一些任务。通过自动化这些任务并使它们在服务器上运行,您将获得

  • 一致的流程(您不会让Stan和Sally以不同的方式做事。)
  • 了解代码中记录的流程(任何能够阅读脚本的人都可以学习部署所涉及的步骤,而不是由Sally成为唯一做到这一点或知道如何做的人。)
  • 简化流程重复(易于部署网站的多个副本:您只需提供新的配置即可!)
  • 进行更彻底的测试(Bob仅测试了他的页面,但他的更改破坏了Sally的页面。Sally忘记提交文件。Stan添加了一个新的依赖项,该依赖项必须与应用程序一起安装,但未实现,因为它是由IDE自动安装的我已经以某种形式看到了所有这些。)

可能还没有想到其他一些好处。


谢谢你的回答。例子很好。我希望我可以投票接受一个以上的答案:-/
卢勋爵。

@LordLoh。别担心。我很高兴能为您提供帮助。=)感谢您告诉我。
jpmc26 '02

1
推荐,很好的答案。像任何事情一样,如果做得不好,您可能无法获得广告宣传的收益。如果过度构建,EG一致性,过程知识,简单性可能会受到影响。所以...切实评估您的需求,然后选择Godspeed!
brian_o

1

您可能不需要编译解决方案,但是CI仍然可以通过更改配置文件/文件夹路径等来帮助您,如果您在团队中,则可以促进对产品状态的更改并部署它们

假设您将Python代码部署到5个不同的QA服务器,并需要它指向不同的QA数据库,然后在自动测试运行(由CI触发)之后,将构建升级到生产环境,并在其中对每个生产服务器进行适当的配置更改。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.