检查持续集成

从代码控制软件中检查代码以执行持续集成或每晚构建时，您通常都会做什么？你是否1）拉取最新的代码，或者2）通过代表开发者最新测试代码的标签（即FUNCTIONAL）拉动？检查持续集成

我想这个答案取决于人们通常如何使用他们的配置管理存储库。你是否打算只存储“完整”的代码。如果是这样的话，如果一个开发人员正在从事一项任务一周左右，他/她将无法检查任何内容，直到完成任务。然而，如果持续集成服务器只是通过一个知名标签拉取而不是拉取最新代码，那么这将允许开发人员在频繁检查代码时检查代码，因为他们正在努力存储他们正在进行的工作的历史记录。然后，一旦他们对这些更改感到满意，他们可以使用FUNCTIONAL标记标记新代码。

只是想知道最佳实践。

感谢

来源

2009-10-21 dewald

你假设开发人员可以在一个任务，而不造成破损无法正常工作，但不一定是真实的，特别是如果他们运行一套单元测试每次提交之前，并避免测试失败时提交。 – bdsl 2017-07-13 23:13:00

所以我们通常做的是有一个“建”分支，它的CI服务器生成了。我们将我们想要包含在夜间构建中的所有东西都合并到构建分支中，并且它将在那里建立。

我们实际上并没有针对构建分支进行开发，我们有开发分支用于保持尚未准备好发布到测试环境的更改。

来源

2009-10-21 02:08:04 lomaxx

你使用什么工具？它是否使连续分支和合并非常简单？ – dewald 2009-10-21 02:24:48

我们使用TeamCity。 CI服务器实际上没有进行任何分支和合并，这仍然由开发人员来完成。 CI服务器所做的是检测对特定SVN分支的提交，并触发构建。构建包括编译应用程序，运行单元测试以及将应用程序部署到服务器上 – lomaxx 2009-10-21 05:40:17

我放出来了CI（更像是经验法则）的主要建议：

有它从 HEAD/MASTER拉代码。尽可能保持稳定，尽可能保持稳定。
没有人可以向 HEAD/MASTER提交破损的代码。如果发生这种情况，那么意味着有人破坏了构建。
无论谁打破构建必须是致力于尽快修复它成为可能。
让您的CI以每个承诺为基础运行构建。所以，只要某人提交破碎的代码到 HEAD，配置项将获得它并打破构建。大部分CI的服务器，我见过支持这种做法操作。
您还可以让您的CI在生成程序包时每晚生成并标记代码。这也是一个很好的练习，你可以看到在世界各地的开源项目上的许多CI上都有。

我的一些经验：我们的CI可以从HEAD/MASTER中获取代码。我们在这里使用git，所以我们的开发人员总是很容易地在分支上工作并保持同步 - 但他们只能将稳定的代码提交给HEAD/MASTER。

来源

2009-10-21 02:44:06 Macaubas

我同意上面的大多数观点 - 一个谨慎的想法 - 我发现如果以每次执行的方式运行，很难获得流畅的CI在一个同时在一个大型项目的几个模块上工作的多开发团队。提交频率往往会压倒CI服务器，特别是如果你有很多测试。在这种情况下，尝试批量生成一定数量的提交或按计划运行。 – Nikhil 2009-10-21 03:45:00

正确的答案是基于你如何组织你的代码。

如果主线总是被认为是稳定/工作的，那么你只需从中建立。

如果你有一个分支是“金”分支，然后...

在我们的商店，我们有三种分支：

主线//总可建，总是“准备好发布一次QA完成”
发布分支//金黄，释放和释放，能够在任何时间
开发分支//其中凌乱手术一事无成

（当然要做到这一点需要很好的vcs。我们使用perforce，它有很棒的分支。）

我们从mainline和release分支做我们的连续建筑。

HTH

来源

2009-10-21 03:33:50 Jonesome

检查持续集成

回答

相关问题