使用自动构建系统时，它通常是执行测试的源代码控制条目（但我假设这可以配置为不在大型团队中的每个条目上）。构建应用程序如何具有源代码签入操作。有这个必要吗？总而言之，构建脚本是由源代码控制条目执行还是在每天的某个时间执行？
此外，术语“中断构建” - 这是否意味着代码放置了源代码控制，并且在执行构建时，由于代码未通过单元测试/代码覆盖率应用程序返回低于某个阈值的否定结果而失败？
最后，一步是什么意思？ （例如一步构建）？
谢谢
【问题讨论】：
标签： build-process build-automation development-environment
总而言之，构建脚本是由源代码控制条目执行还是在每天的某个时间执行？
这取决于。一些团队使用版本控制系统中的提交作为触发器，一些团队使用时间事件作为触发器（例如每小时）。如果您在每次更改后运行构建，您会立即获得反馈。如果您在两次构建之间留出一些时间，您会延迟该反馈，并且在构建失败的情况下，更难确定导致的更改。这可能需要更多调查。
只是为了澄清词汇，对我来说，“构建”实际上是自动化所有需要完成的事情（编译、运行测试等）的脚本/工具。然后连续运行这个自动构建就是人们所说的“continuous integration”。并且触发a构建事件（基于时间或提交），从存储库中提取源，运行构建脚本，在失败时通知人们是“持续集成引擎”的责任.
此外，术语“中断构建” - 这是否意味着代码放置了源代码控制，并且在执行构建时，由于代码未通过单元测试/代码覆盖率应用程序返回低于某个阈值的否定结果而失败？
这确实是非常二进制：构建通过，或者它没有。如果没有，可能有很多原因：代码未编译、测试失败、质量检查失败（编码标准、代码覆盖率等）。如果您提交了一些代码而不是导致构建失败（无论原因是什么），那么您“破坏了构建”。
最后，一步是什么意思？ （例如一步构建）？
在我看来，一步构建意味着您可以使用一个命令构建整个应用程序、运行测试、运行质量检查、生成报告、组装应用程序、部署它等等.这是自动化构建的同义词（如果您不能一步运行构建，即如果它需要人工干预，则它不是完全自动化的）。
【讨论】：
此外，术语“破坏构建” - 这是否意味着代码放了源代码控制 并且在执行构建时，它 由于代码未通过而失败 单元测试/代码覆盖率应用返回 低于一定的阴性结果 阈值？
这可能意味着不同的事情，具体取决于公司、项目或团队。 通常“构建”是一些参考（通常是自动化的）过程，它要么成功，要么不成功。 因此，“破坏构建”正在做一些导致此参考过程失败的事情。
它可以包括或排除运行的单元测试、运行的回归测试、产品的部署，或者你的团队认为永远不会失败的任何事情。
【讨论】：