12

什么构成了一个好的 CI 构建过程？

我们使用 CI，但是当您依赖于应该部署的多个服务并且其他应用程序也可能依赖于这些服务时，部署到生产甚至是一个现实的 CI 目标。

当一个好的 CI 构建过程自动化到 QA 并从那里手动时，它是否足够好？

4

7 回答 7

14

这要看情况” ：）

我们使用 CI 系统来：

  1. 构建和单元测试
  2. 部署到单机，运行集成测试和代码分析
  3. 部署到实验室环境
  4. 在类似产品的系统中运行验收测试
  5. 删除传递给代码删除以进行产品部署的构建

这是一个新项目，大约十几个服务和数据库部署到 20 多台服务器上，还依赖于六个其他“外部”服务。

使用 CI 工具将您的产品部署到生产环境作为一个现实的目标？再次......“这取决于”

你为什么想做这个？

  • 如果你有这个过程，你可以更快、更频繁地滚动更改（和回滚）
  • 减少人为错误的机会
  • 您可以在投入生产之前在测试环境中测试相同的部署策略并尽早发现问题

在回答这个问题之前，您必须解决一些技术问题：

  • 您的系统的正常运行时间要求是什么——您是否允许停机或是否需要 24/7 不间断运行？
  • 您是否有需要人工干预/批准的变更控制流程？
  • 如果部署失败，您的部署是否足够健壮，任何组件都可以回滚到已知良好状态？
  • 您的系统是否设计为在一个或多个组件部署失败时处理不同版本的服务或客户端（并且您有上述回滚到最后一次已知的良好状态）？
  • 该过程是否具有处理组件无法处理其依赖项/客户端的混合版本的部分部署的智能？
  • 您如何处理数据库部署/升级？
  • 您是否进行了监控，以便知道何时出现问题？

以下是一些关于自动化和构建您需要的工具的最新相关链接。

When it comes down to it the more complex your system the more difficult it is do automate everything, but that does not mean it is not a worthy goal, it just takes a lot more effort and willpower to get it done -- everything from knowing the difficulties you're going to face, the problems you have to account for (failure will happen), the political challenges of building infrastructure (vs. more product features).

Now heres the big secret... the technical challenges are challenging but not impossible... the political challenges may be insurmountable. Everything about this costs money whether its dev time or buying 3rd party solutions. So really, can you build the $1K, $10K, $100K, or $1M solution?

Whatever solution you go for make sure the automation is robust first, complete second... i.e. make sure you have as robust a solution as you can for getting deployment to a test environment rather than a fragile solution that deploys to production.

于 2008-09-19T17:09:44.160 回答
4

CI 并非旨在作为一种部署机制。最好让您的CI 对 QA/Test 服务器执行任何自动部署，以确保您的构建工作的这些方面，但我不会使用像 Cruise Control 或 Bamboo 这样的 CI 系统作为部署手段。

CI 用于定期构建代码库以自动执行自动化测试、通过静态分析和其他类似检查来验证代码库。

于 2008-09-19T15:36:37.457 回答
3

确保您了解 CI 构建背后的想法。CI 代表持续集成，CI 构建实际上是一次性构建，当开发人员将代码签入源代码控制系统（或在某个指定的时间间隔）时执行，以确保最新的更改不会破坏代码库（因此不断将更改集成到代码库的想法）。

为此，与构建过程中实际发生的情况相比，用于实际构建服务器过程的技术在很大程度上无关紧要。正如@pdavis 提到的，CI 构建应该编译代码库，执行一些代码分析（FxCop、StyleCop、Lint 等）、执行单元测试和代码覆盖率，并执行您想要执行的任何其他应该影响概念的自定义分析“成功”或“失败”的构建。

让 CI 构建自动部署到环境实际上并不在构建服务器的控制之下。话虽如此，您始终可以创建一个单独的项目，该项目在构建服务器上运行，当它检测到某些条件（例如构建成功完成）时处理部署，但这应该始终作为一个完全独立的事情来完成。

于 2008-09-19T15:50:08.860 回答
2

我正在开始一个我非常期待的新项目。我们仍处于初始设计阶段，最近刚刚完成了逻辑系统架构。我们为测试和登台环境订购了新服务器，并正在建立一个基于 Cruise Control ( http://cruisecontrol.sourceforge.net/ ) 和 MSBuild ( http://msdn2.microsoft) 的持续集成 (CI) 构建系统。 com/en-us/library/wea2sca5.aspx），它基本上是 ANT 的改进端口。似乎 Visual Studio 2005 项目和解决方案文件现在都是 MSBuild 格式。Cruise Control 会自动从 Visual Source Safe 中提取源代码（好吧，它不是 Subversion，但我们可以处理），编译它，然后通过 fxCop 运行它（http://www.gotdotnet.com/Team/FxCop/ )、nUnit ( http://www.nunit.org/ )、nCover ( http://ncover.org/site/ )，最后但不租用 Simian （http://www.redhillconsulting.com.au/products/simian/）。Cruise Control 有一个非常好的网站界面，用于显示来自各种工具的所有编译结果，甚至可以显示从一个构建到下一个构建的代码更改。它还跟踪构建历史中的所有构建。我很期待测试驱动的开发，并认为这种与 nUnit/nCover 相结合的方法应该会给我们一个很好的主意，然后再推出我们没有破坏任何东西的更改。一旦我们在项目中走得足够远，还计划加入某种类型的自动化用户界面测试。根据工具的不同，这应该只是在构建服务器上安装工具并从 Cruise Control 调用它的问题。甜的。

于 2008-09-19T15:37:55.067 回答
2

一个好的 CI 过程将具有完整或几乎完整的单元测试覆盖率。单元测试测试类和方法，而集成测试则测试系统的多个部分。当您设置 CI 构建时，让它们自动执行单元测试。这样，CI 构建每天可以运行多次。我们设置为每 2 小时运行一次。

您可以拥有每天运行一次的运行时间更长的构建。这些可以使用其他服务并运行集成测试。

于 2008-09-19T15:38:55.300 回答
1

我正在观看一个 ThoughtWorks 演示文稿（Cruise Control 的创建者），他们实际上解决了这个问题。他们的回答是，没有部署太复杂而无法测试。为什么？因为否则，您的客户将成为您的测试人员，而这正是您不想成为的地方。

如果您有复杂的部署结构，请设置可视化服务器。让它假装是您需要与之交谈的所有系统。它们始终可以以已知的良好状态启动，因为您可以重置为干净的图像。

为了回答您最初的问题，一个好的流程是能够在存储库和开发人员之间进行通信的流程。如果存储库处于不良状态（未编译代码、测试失败等），开发人员会尽快了解它，以便他们进行更正。

于 2008-09-19T15:39:44.017 回答
1

越晚发现错误，修复的成本就越高。所以应该尽早发现错误。这就是 CI 背后的动机。

一个好的 CI 应该确保捕获尽可能多的错误。整个应用程序由代码（通常采用多种语言）、数据库模式、部署文件等组成。其中任何一个错误都可能导致错误——因此 CI 应该尝试尽可能多地使用它们。

CI 不会取代适当的 QA 纪律。此外，CI 在项目的第一天不需要非常全面。可以从一个简单的 CI 流程开始，该流程最初会进行基本的编译和单元测试。当您在 QA 中发现更多类别的错误时，您应该调整 CI 流程以尝试捕捉这些错误的未来发生。它还可以涉及静态代码分析检查，以便您可以在整个代码库中实现一致的编码和设计理念。

于 2008-09-19T16:17:46.143 回答