有关设置自动构建的问题

Question

使用自动构建系统时，它通常是执行测试的源控件条目（但我认为这可以配置为不在大型团队的每个条目上）。构建应用程序如何为源代码签入提供操作。这有什么需要吗？总而言之，是源控件条目还是每天某个时间执行的构建脚本？

此外，术语“打破构建” - 这是否意味着代码放置了源代码控制，并且在执行构建时，由于代码未通过单元测试/代码覆盖率应用程序返回低于某个阈值的负面结果而失败？

最后，一步是什么意思？ （例如一步构建）？

由于

Answer 1

  

总而言之，是源控件条目还是每天某个时间执行的构建脚本？

这取决于。一些团队在版本控制系统中使用提交作为触发器，一些团队使用时间事件作为触发器（例如每小时）。如果您在每次更改后运行构建，则会立即获得反馈。如果您在两个构建之间运行一段时间，则会延迟该反馈，并且在构建失败的情况下，更难以识别导致的更改。可能需要更多的调查。

为了澄清词汇，对我来说，“构建”实际上是一个脚本/工具，可以自动完成所有需要完成的事情（编译，运行测试等）。然后，持续运行此自动构建是人们称之为“continuous integration”的内容。并触发 构建事件（基于时间或提交时），从存储库中提取源代码，运行构建脚本，在发生故障时通知人员是“持续集成引擎”的责任

  

此外，术语“打破构建” - 这是否意味着代码放置了源代码控制，并且在执行构建时，由于代码未通过单元测试/代码覆盖率应用程序返回低于某个阈值的负面结果而失败？

这确实非常二元化：构建通过，或者不通过。如果没有，可能有很多原因：代码未编译，测试失败，质量检查失败（编码标准，代码覆盖率等）。如果您提交一些代码而不是导致构建失败（无论原因是什么），那么您“破坏了构建”。

  

最后，一步是什么意思？ （例如一步构建）？

在我看来，一步构建意味着您可以使用一个命令构建整个应用程序，运行测试，运行质量检查，生成报告，组装应用程序，部署它等等 。这是自动构建的同义词（如果您无法一步完成构建，即如果需要人工干预，那么它就不是完全自动化的。）

Answer 2

  

此外，“破坏构建”一词 -   这是否意味着代码放置源代码控制   当构建执行时，它   因代码未通过而失败   单元测试/代码覆盖应用返回   负面结果低于一定水平   阈值ε

根据公司，项目或团队的不同，这可能意味着不同的事情。 通常“构建”是一些参考（通常是自动化的）程序，该程序要么成功要么不成功。 因此，“破坏构建”正在做一些导致此参考过程失败的事情。

它可以包括或排除运行的单元测试，或回归测试运行，或产品部署，或者团队认为永远不会失败的任何内容。