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

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

当一个良好的CI构建流程自动化到QA并从那里手动进行时，该流程是否足够好？

解决方案

CI并非旨在用作部署机制。最好让CI执行到QA / Test服务器的任何自动部署，以确保构建工作的那些方面，但是我不会使用Cruise Control或者Bamboo等CI系统作为部署方式。

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

我正在开始一个我非常期待的新项目。我们仍处于初始设计阶段，并且最近才完成了逻辑系统架构。我们已经为测试和登台环境订购了新服务器，并正在基于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调用它的问题。甜的。

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

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

我正在观看ThoughtWorks的演示文稿(巡航控制系统的创建者)，他们实际上解决了这个问题。他们的回答是，没有部署太复杂以至于无法测试。为什么？因为否则，客户将成为测试人员，而这正是我们不希望成为的测试人员。

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

为了回答第一个问题，一个好的过程是使存储库和开发人员之间能够进行通信的过程。如果存储库处于不良状态(非编译代码，失败的测试等)，则开发人员应尽快了解它，以便他们可以对其进行更正。

确保我们了解CI构建背后的想法。 CI代表持续集成，并且CI构建实际上旨在作为即弃即用的构建，当开发人员将代码检入源控制系统(或者以指定的间隔)以确保最新更改不会破坏代码库时执行(因此，不断将更改集成到代码库中的想法)。

为此，与构建过程中实际发生的情况相比，用于实际构建服务器过程的技术在很大程度上无关紧要。如@pdavis所述，CI构建应编译代码库，执行一些代码分析(FxCop，StyleCop，Lint等)，执行单元测试和代码覆盖率，并执行我们想要执行的任何可能影响概念的自定义分析"成功"或者"失败"的构建。

将CI构建自动部署到环境中实际上并不受构建服务器的控制。话虽如此，我们始终可以创建一个在构建服务器上运行的单独项目，该项目在检测到某些情况(例如构建成功完成)时就处理部署，但是始终应将其作为完全独立的事情来完成。

发现错误的时间越晚，修复它的成本就越高。因此，应该尽早发现错误。这就是CI背后的动机。

一个好的配置项应确保捕获尽可能多的错误。整个应用程序包括代码(通常使用多种语言)，数据库架构，部署文件等。任何这些错误都可能导致错误，因此CI应尝试尽可能多地使用它们。

CI不会取代适当的质量检查规范。此外，CI在项目的第一天不必非常全面。可以从一个简单的CI流程开始，该流程最初会进行基本的编译和单元测试。当我们在质量检查中发现更多类别的错误时，应调整CI流程以尝试捕获将来出现的这些错误。它还可能涉及静态代码分析检查，因此我们可以在整个代码库中实现一致的编码和设计理想。

这得看情况" ：)

我们使用CI系统来：

• 构建和单元测试
• 部署到单个设备中，运行集成测试并编写analisys代码
• 部署到实验室环境
• 在类似产品的系统中运行验收测试
• 删除传递给代码的内部版本以进行产品部署

这是针对一个部署在20台以上服务器上的十几种服务和数据库的新建项目，该项目还依赖于六种其他"外部"服务。

使用CI工具将产品部署到生产环境是一个现实的目标？再次..."取决于"

你为什么想做这个？

• 如果我们有此过程，则可以更快，更频繁地回滚更改(并回滚)
• 减少人为错误的机会
• 我们可以在投入生产之前在测试环境中测试相同的部署策略，并尽早发现问题

在回答此问题之前，我们必须解决一些技术问题：

• 系统的正常运行时间要求是什么？-是否允许我们停机或者需要24/7全天候运行？
• 我们是否有需要人工干预/批准的变更控制流程？
• 如果部署失败，部署是否足够健壮，以至于任何组件都可以回滚到正常状态？
• 系统是否设计为在一个或者多个组件部署失败的情况下处理不同版本的服务或者客户端(并且我们具有上述回退到最后一次的认可)？
• 该过程是否具有处理部分组件无法处理其依赖项/客户端的混合版本的部分部署的能力？
• 我们如何处理数据库部署/升级？
• 我们是否有适当的监控，以便知道什么时候出了问题？

这是最近有关自动化和构建所需工具的几个相关链接。

归结为它，系统越复杂，使所有内容自动化的难度就越大，但这并不意味着它不是一个值得的目标，它需要花费更多的精力和意志力才能完成它-了解知识我们将要面对的困难，必须解决的问题(将发生故障)，基础架构的政治挑战(与更多产品功能相对)。

现在这是一个大秘密……技术挑战具有挑战性，但并非不可能……政治挑战可能是无法克服的。无论是开发时间还是购买第三方解决方案，有关这一切的成本都是金钱。那么，真的，我们可以构建1000美元，10000美元，10万美元或者100万美元的解决方案吗？

无论我们要使用哪种解决方案，请确保自动化首先是健壮的，其次才是完整的……也就是说，请确保我们拥有尽可能强大的解决方案，以将其部署到测试环境，而不是将脆弱的解决方案部署到生产环境。

Is a good good CI build process good enough when its automated to QA and manual from there?

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

此功能可以在类似prod的环境中通过自动部署过程测试来消除，并且还必须在部署后测试回滚机制。

对这些功能进行足够的测试后，我们将对使用的过程和工具充满信心。