我正在尝试将持续集成添加到项目中。
根据Wikipedia的介绍，CI的一项主要内容是自动构建。但是，由于CI和构建自动化文章似乎不同意，我对确切的含义感到困惑。
特定的混淆点：在以下情况下， “自动构建”是什么意思：
- 使用解释性语言（例如Python或Perl）的项目？
- 在最终用户的计算机上从源代码构建？
- 具有不能简单地预编译和分发的依赖项的应用程序，例如用户计算机本地的RDBMS中的数据库？
我正在尝试将持续集成添加到项目中。
根据Wikipedia的介绍，CI的一项主要内容是自动构建。但是，由于CI和构建自动化文章似乎不同意，我对确切的含义感到困惑。
特定的混淆点：在以下情况下， “自动构建”是什么意思：
Answers:
您正确地指出，对于某些技术，不需要编译步骤。但是，我建议您在解释“构建自动化”一词时放宽眼界。将“构建”考虑为包括以下两个主要组件：
因此，自动化只是指使所有这些操作（即使不是全部）自动进行（即不需要人工干预）。根据您的技术，这可能包括很多步骤：
转换步骤：
质量保证步骤：
这些天来，好的CI工具将使您解决所有这些问题。最初，大多数商店都对自动编译代码感兴趣，因为这是常规软件开发中第一个也是最明显的问题来源。
自动化构建是对过程的描述，应涵盖以下基本知识：
这是一个无需人工干预的过程，应在零人工干预下运行。
在我看来，自动化构建是
目的是要有一个可以重复的部署过程-阅读：经过测试-以便在部署到生产环境时，您可以肯定地确定事情不会出错。在构建和部署过程中人与人之间的互动越少，发布就越安全。
如果您使用的是非编译语言，则仍然可以构建网站并将其压缩以创建单个文物。
一个好的CI工具将使您可以将许多任务编写脚本到构建过程中，包括运行单元测试。它还会保留您成功和不成功的构建，测试覆盖率等的记录。但是这些都不是我定义为自动构建的一部分。（即，一个好的自动构建过程具有这些东西，但是一个糟糕的过程不会被称为“自动构建”，因为它缺少这些东西。）
我建议将集成/回归测试作为部署过程的一部分而不是构建过程来运行（尽管，如果您有方便的环境，则可以在每个构建过程中进行部署）。
a project using an interpreted language, such as Python or Perl?
在使用解释语言的情况下，可能会遇到麻烦。某些互穿语言具有编译器，但使用它们的可能性通常不是很大。在那种情况下，我通常只扫描代码中的语法和解析错误以代替编译，或者直接跳过对代码运行测试。
在最终用户的计算机上从源代码构建？
对我来说，这意味着您可以提供一个命令，最终用户可以运行该命令来获取程序的最新版本，对其进行编译，根据需要进行配置和部署。
具有不能简单地预编译和分发的依赖项的应用程序，例如用户计算机本地的RDBMS中的数据库？
这些将属于持续集成的测试部分，因为您可以自动销毁和重建数据库，以确保脚本正确并且程序可以正确地对其进行测试。
您在问题中讨论的实际上是3个不同的概念：
持续集成的核心是进行小的更改，并经常将这些更改与“全局真相”同步。开发人员应该执行一天之内可以完成的任务，而不是进行检出并坚持一个星期，以使他的代码永远不会与主存储库太不同步。
为了做到这一点而又不会引起团队的痛苦（即检入未构建或破坏现有功能的源代码）。开发人员必须验证他的代码没有“破坏构建”。如果手动完成，这会增加开发过程的额外开销（例如，一个项目需要很长时间才能构建和/或具有许多相互依赖关系，其中一行代码的更改会以意想不到的方式影响应用程序）。
为了减轻这种情况，我们使用其他技术来消除这种开销。
我们使用自动化构建来签出源代码并构建它（可选），运行自动化测试来验证应用程序是否应该正常工作（此步骤仅与测试套件一样有用）。
持续交付的又一个步骤解决了数据库和其他问题。这里的想法是为数据库和环境的其他因素提供某种程度的版本控制，以便我们可以尽快确认应用程序在尽可能接近生产环境中工作。
builds和build，因为我不知道该用哪一个。