什么是良好的CI构建过程

Question

什么构成良好的CI构建过程？

我们使用CI，但是如果您依赖于应该部署的多个服务而其他应用程序也可能依赖于这些目标，那么即使是实际的CI目标也会部署到生产中。

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

Answer 1

嗯“这取决于”：）

我们使用CI系统：

1. build＆amp;单元测试
2. 部署到单个框，运行集成测试和代码分析
3. 部署到实验室环境
4. 在类似prod的系统中运行验收测试
5. drop build传递给代码drop以进行prod部署

这是一个绿地项目，包括部署到20多台服务器的大约十二个服务和数据库，这些服务和数据库也依赖于其他六个“外部”服务。

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

你为什么要这样做？

• 如果您拥有该流程，则可以更快，更频繁地滚动更改（并回滚）
• 人为错误的机会较少
• 您可以在进入生产阶段之前在测试环境中测试相同的部署策略并及早发现问题

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

• 您的系统的正常运行时间要求是什么？您是否允许停机或是否需要全天候运行？
• 您是否有适当的变更控制流程需要人工干预/批准？
• 您的部署是否足够强大，以便任何组件在部署失败时回滚到已知良好状态？
• 是您的系统，旨在处理不同版本的服务或客户端，以防一个或多个组件部署失败（并且您已经回滚到上次已知的商品）？
• 该流程是否具有智能来处理部分无法处理其依赖关系/客户端的混合版本的部分部署？
• 您如何处理数据库部署/升级？
• 您是否有适当的监控，以便在出现问题时知道？

以下是有关automation和building the tools you need的最新相关链接。

当涉及到它时，你的系统越复杂，自动化一切就越困难，但这并不意味着它不是一个有价值的目标，它只需要更多的努力和意志力来完成它 - 从了解您将面临的困难，您必须解决的问题（失败将发生），建设基础设施的政治挑战（与更多产品功能相比）。

现在这是一个大秘密......技术挑战具有挑战性但并非不可能...... 政治挑战可能是不可逾越的。无论是开发时间还是购买第三方解决方案，关于此的一切都需要花钱。那么，你真的可以建立1K，1万美元，10万美元或100万美元的解决方案吗？

无论您采用何种解决方案，都要确保自动化首先是健壮的，完全是第二个...即确保您拥有尽可能强大的解决方案，以便部署到测试环境而不是部署到生产的脆弱解决方案。

Answer 2

CI不是一种部署机制。让你的CI执行任何自动部署到QA /测试服务器 是好的，以确保你的构建的那些方面工作，但我不会使用像Cruise Control或Bamboo这样的CI系统部署。

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

Answer 3

确保您了解CI构建背后的理念。 CI代表持续集成，CI构建真正意图是当开发人员将代码检入源控制系统（或以某个指定的间隔）执行时执行的丢弃构建，以确保最新的更改不会破坏代码库（因此，不断将更改集成到代码库中的想法）。

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

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

Answer 4

我正在开始一个我真正期待的新项目。我们仍处于初始设计阶段，最近刚刚完成了逻辑系统架构。我们已经为测试和登台环境订购了新服务器，并且正在建立基于Cruise Control（http://cruisecontrol.sourceforge.net/）和MSBuild（http://msdn2.microsoft.com/en-us/library/wea2sca5.aspx）的持续集成（CI）构建系统，该系统基本上是一个改进的端口蚂蚁。看来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调用它。甜。

Answer 5

良好的CI流程将具有完整或接近完整的单元测试覆盖率。单元测试测试类和方法，以及集成测试，测试系统的多个部分。设置CI构建时，让它们自动化单元测试。这样，CI构建可以每天运行多次。我们的设置每2小时运行一次。

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

Answer 6

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

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

要回答您的初始问题，一个好的流程可以实现存储库和开发人员之间的通信。如果存储库处于错误状态（非编译代码，测试失败等），开发人员会尽快知道它，以便他们能够纠正它。

Answer 7

后来发现了一个错误，它的修复成本更高。所以应该尽早发现错误。这是CI背后的动机。

良好的CI应该确保捕获尽可能多的错误。整个应用程序包含代码（通常是多种语言），数据库模式，部署文件等。其中任何一个错误都可能导致错误 - 因此CI应尽可能多地运用它们。

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

Answer 8

  

    

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

  

我认为，当具有部署工程师角色的人担心部署后的某些内容可能出错时，会使用“手动”部署。他对部署工具的可靠性和稳定性没有信心。

这个专长可以在类似prod的环境中进行自动部署过程测试。它还必须在部署后测试回滚机制。

当对此功能进行足够的测试时，您将对使用此过程和工具充满信心。