持续集成服务器在哪一点有趣？

我一直在阅读有关Jenkins等CI服务器的信息，我想知道：在什么时候有用？

因为对于一个只有5个类和10个单元测试的小项目，肯定没有真正的需要。

在这里，我们进行了大约1500个单元测试，它们在90秒钟内（在旧的Core 2 Duo工作站上）通过了（因为它们实际上是在测试“单元”，因此非常快）。我们的规则是测试失败时我们不能提交代码。

因此，每个开发人员都会启动其所有测试以防止回归。

显然，因为所有开发人员总是启动所有测试，所以一旦一个开发人员撤消另一个更改（如有），我们就会捕获由于冲突更改而导致的错误。

对我来说还不是很清楚：我应该像Jenkins一样设置CI服务器吗？它会带来什么？

它对提高速度有用吗？（在我们的情况下不是问题）

因为可以重新创建旧版本，这是否有用？（但是我们可以通过检出旧版转速来使用Mercurial来做到这一点）

基本上，我知道它会很有用，但我无法确切知道原因。

任何考虑到我上面提出的观点的解释都将受到欢迎。

它对提高速度有用吗？（在我们的情况下不是问题）

花在循环流程上的任何时间都是您本可以花在开发流程上的时间。

您还可以节省里程碑时间，因为理想情况下，您正在构建完全包装且可以立即发货的位，这些位可以直接刻录到CD，上传到网络等。

因为可以重新创建旧版本，这是否有用？（但是我们可以通过检出旧版转速来使用Mercurial来做到这一点）

不，您不重新创建内部版本。您可以使用它创建的版本，并保留它，直到保留设置丢掉为止。

您在构建服务器上构建它，而不是在某些开发人员的盒子上构建它。

在这里，我们进行了大约1500个单元测试，它们在90秒钟内（在旧的Core 2 Duo工作站上）通过了（因为它们实际上是在测试“单元”，因此非常快）。我们的规则是测试失败时我们不能提交代码。

另外，您是否不希望能够对代码运行自动集成或端到端测试，并发现单元测试无法解决的问题？

您不希望在开发箱上运行它们，因为设置和维护该环境会很痛苦。集成测试的执行速度也往往很慢。

在什么时候有用？

这是一项与其他投资一样的投资。

使用它一次，您可能会落后或只能收支平衡。在多个项目上使用它，您可能会领先一步。

它还取决于您制作的应用程序的类型。

如果您制作需要部署到Java应用程序服务器或IIS的Web应用程序，则CI变得轻而易举。如果您将数据库作为项目的一部分，则相同。手动执行部署很麻烦，而且您的质量检查团队（如果有的话）有时会每天都需要它。

另外，您可能想看看您的需求和问题与Joel Spolsky的“改善代码的12个步骤”如何一致。特别是2、3和10（尽管它们都很有趣而且很重要）。

在什么时候有用？

• 您的构建+测试周期超过了几分钟。经过5分钟的测试运行，您将不再想要自己运行所有测试，尤其是对于小的更改。
• 您开始构建多个变体。如果您有几个具有不同自定义项的客户，则应针对每个变体运行测试，因此工作量将开始迅速增长。比起您要在开发人员机器上运行一个变体的测试套件，然后将其留给CI来在其余变体上运行它来说，要好得多。
• 您编写了需要一些非平凡的测试环境设置的自动集成测试。比起您要在一个规范的测试环境中进行测试，因为开发人员可能会由于开发更改而以各种方式修改其环境。CI是最适合规范环境的地方。
• 测试人员可以从CI中获取最新版本。因此，他们无需拥有，学习和使用开发工具，也无需任何开发人员手动将其构建发送给他们。
• 准备发布时：
  • 测试变得越来越重要，因此拥有一个准备好的版本进行测试的场所就更加有用。
  • 您可以确定所有构建都是使用相同的构建环境构建的，因此可以避免开发人员安装之间的细微差异可能引起的问题。
  • 您可以确定您正在完全构建版本控制系统中检查的内容。在开发过程中，如果有人忘记签入某些内容，您会很快找到，因为对于下一个开发人员而言，它会失败。但是，如果将此类构建提交质量检查或生产，并且他们报告了错误，则将很难跟踪。

您可能现在还不需要CI，但是我认为进入测试阶段将变得很有用。Jenkins可以在几个小时内完成设置，它将简化您的测试并避免出现愚蠢的错误（尤其是在您急于快速解决生产问题时会发生这种错误）。

对我来说，如果您的团队中有超过1名成员，则CI会变得很有趣。

您必须停止将CI视为“另一台为我运行测试的PC”。CI具有定义的自动化构建过程和发布管理。

CI是创建您的软件版本的唯一权威实体。如果它不在CI的基础上，那就没有发生。

使用CI时，您会受到限制，无法自动执行所有操作，这将向您显示所有已进行的手动调整，修改和快捷方式，而这些操作与CI无关，因此应首先避免。

它避免的问题：

• 谁负责构建发行版
• 这个人24/7有空吗
• 但是它建立在我的机器综合症上
• 消除了关于我们发布的版本的所有歧义

优点（太多不胜枚举）：

• 自动版本编号
• 问题跟踪集成
• 自动化指标生成
• 静态代码分析
• 自动化部署
• 多阶段设置

关于持续集成（CI）的一个基本问题可以完美地反映在您的问题中：CI实践很难实施和捍卫，因为CI服务器软件的安装不容易，而通过CI来启动和运行项目也不容易。服务器。这样一来，很难真正看出采用CI的好处。

首先，CI是关于洞察力和质量的。良好的CI使您更接近项目，为您提供有关质量指标，文档，编码标准合规性等方面的适当反馈。它应为您提供轻松可视化所有这些功能的工具，并使您一目了然并轻松识别将一组更改与所有这些项目指标的特定快照相关联。

这不只是运行单元测试。一点也不！这带给我品质。CI接受错误，它不会避免错误或将其丢弃。它的作用很简单，就是为您提供一种可以尽早出错而不是稍后出错的工具。因此，您实际上不会将以前测试过的代码提交到CI服务器。尽管您应该努力提交干净且不会破损的代码，但实际上您是使用CI服务器自动通过代码自动运行集成生成器，并让它评估一切是否正确。如果有的话，整齐！如果没有，那就没问题-良好的CI实践表明，您的下一个优先事项应该只是修复已损坏的所有内容。在一个好的CI服务器中，应该为您轻松指出。

随着团队规模的扩大，每个人的代码集成自然变得越来越困难。中央CI服务器的任务应该是测试所有集成的部件，并减轻团队成员的负担。因此，您必须让每个人尽早（并且尽可能干净）提交承诺，然后监视构建状态（通常涉及通知）。再说一次，如果由于某个开发人员的提交而使某些东西损坏了，它立即成为他的责任来修复它，并使那些自动构建立即恢复为OK状态。

因此，您认为，在我看来，每个项目都受益于持续集成。事实是，直到现在，由于我所知道的每台CI服务器都令人难以置信的复杂性，人们真的抵制了较小/较简单项目上的CI实践。因为，来吧，人们比花几天时间配置丑陋，过于复杂，交付不足的，过时的软件要更好。

我也遇到了同样的问题，这就是让我从一年前开始的空闲时间发展Cintient的原因。我的前提是使安装，配置和使用变得简单，并使其按照其他每个人几乎都失败或未能充分实现的质量指标来交付。因此，在这个漫长的答案之后，我毫不客气地指出了该项目的GitHub链接（这是免费且开源的，natch）。显然，它也有一些漂亮的屏幕截图。:-) https://github.com/matamouros/cintient

希望我能帮到你。

（注：在布莱恩·奥克利（Bryan Oakley）评论后编辑，基于这样的事实，我应该花更多时间来制定更好的答案。我也认为他是对的。