关于设置自动化构建的问题
使用自动构建系统时，通常是执行测试的源代码控制条目（但我认为可以将其配置为不在大型团队中的每个条目上）。构建应用程序为何具有源代码签入操作。有这个必要吗？总而言之，构建脚本是由源代码控制条目执行还是在每天的某个时间执行？
另外，术语“中断构建”-这是否意味着代码放置了源代码控制，并且当执行构建时，由于代码未通过单元测试/代码覆盖率应用程序返回低于特定阈值的负结果而失败？
最后，一步是什么意思？ （例如一步构建）？
谢谢
When using an automated build system, it is usually a source control entry which executes tests (but I assume this can be configured to not be on every entry in a large team). How comes build applications have actions for source code checkins. Is there any need for this? So to summarise, is a build script executed by a source control entry or at a certain time everyday?
Also, the term "break the build" - does this mean code put source control and when the build is executed, it fails due to the code not passing a unit test/code coverage app returns negative results below a certain threshold?
Finally, what does a step mean? (Eg one step build)?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这取决于。有些团队使用版本控制系统中的提交作为触发器，有些团队使用临时事件作为触发器（例如每小时）。如果您在每次更改后运行构建，您会立即得到反馈。如果在两次构建之间留出一些时间，则会延迟反馈，并且在构建失败的情况下，很难确定导致原因的更改。可能需要更多调查。
只是为了澄清词汇，对我来说，“构建”实际上是自动化所有需要完成的事情（编译、运行测试等）的脚本/工具。然后持续运行这个自动化构建就是人们所说的“持续集成”。根据事件（基于时间或提交）触发构建、从存储库中提取源代码、运行构建脚本、在失败时通知人员是“持续集成引擎”的职责。
这确实是非常二元的：构建通过，或者不通过。如果没有，可能有很多原因：代码未编译、测试失败、质量检查失败（编码标准、代码覆盖率等）。如果您提交的某些代码导致构建失败（无论原因是什么），那么您就“破坏了构建”。
在我看来，一步构建意味着您可以使用一个命令构建整个应用程序、运行测试、运行质量检查、生成报告、组装应用程序、部署应用程序等。这是自动化构建的同义词（如果您无法一步运行构建，即如果它需要人工干预，那么它就不是完全自动化的）。
This depends. Some teams use a commit in the version control system as trigger, some teams use a temporal event as trigger (e.g. each hour). If you run the build after each change, you get immediate feedback. If you let some time run between two builds, you delay that feedback and, in case of a build failure, it's harder to identify the change(s) that are the cause. It may require more investigation.
Just to clarify the vocabulary, for me, "the build" is actually the script/tool that automates all the things that needs to be done (compiling, runing tests, etc). Then running this automated build continuously is what people call "continuous integration". And triggering a build on an event (time based or on commit), pulling the sources from the repository, running the build script, notifying people in case of failure is the responsibility of a "continuous integration engine".
This is very binary indeed: the build passes, or it doesn't. When it doesn't, there can be many reasons: the code didn't compile, a test failed, a quality check failed (coding standards, code coverage, etc). If you commit some code than causes a build failure (whatever the reason is), then you "broke the build".
In my opinion, a one step build means that you can build your entire application, run the tests, run the quality checks, produce reports, assemble the application, deploy it, etc with one command. This is a synonym of automated build (if you can't run your build in one step, i.e. if it requires human intervention, then it isn't fully automated).
根据公司、项目或团队的不同，这可能意味着不同的事情。
通常“构建”是一些参考（通常是自动化的）过程，要么成功，要么失败。
因此，“破坏构建”正在做一些导致此参考过程失败的事情。
它可以包括或排除运行的单元测试、运行的回归测试、产品的部署，或者您的团队认为永远不应该失败的任何内容。
This could mean different things depending on company, project or team.
Usually "build" is some reference (usually automated) procedure which is either succeeds or not.
Thus "breaking the build" is doing something that leads failing of this reference procedure.
It could include or exclude unit-tests running, or regression test running, or deployment of your product, or whatever your team thinks should never fail.