大型项目的连续集成最佳实践

Question

我的团队有一个持续集成服务器(目前是TeamCity，但这并不重要)和大型Visual 项目，它在签入(构建、运行单元测试、在测试服务器上部署)之后，需要大约1小时才能完成完整的CI过程。

解决方案分为两个部分:后端部分，即完全.NET堆栈项目(、等)。和前端单页应用程序包含大量的JavaScript和前端的东西。

持续集成构建过程1小时大约是90%的后端代码，构建，单元测试.

这是大型项目的常见场景，我希望您分享您的最佳实践和建议，即如何以某种方式使“智能”签入触发逻辑，即解决方案的每个部分(前端、后端)不会为另一部分启动构建过程。

Answer 1

在你的例子中

大型项目的常见场景

可以更好地处理下一个步骤- 连续交付。因为你所描述的所有行为都是自然的。关于那个角色

持续集成构建过程耗时1小时，约占后端代码、构建、单元测试的90%。

这个文章提供了非常好的解决方案-并行测试。当然，这取决于您的环境。其基本思想是，如果执行得当，处理器并行性-like执行/度将是非常有效的。在分析你所有的目标和资源之后。如果这种自动化操作得当，那么测试工作量就会大大减少。

带着.

以某种方式使“智能”签入触发器逻辑，使解决方案的每个部分(前端、后端)不会为另一部分启动构建过程

考虑到这样的假设

持续集成服务器(但这并不重要)

在这里的细节中描述了一个非常好的解决方案(用Jenkins编排交付管道)。也许对你来说最有价值的是：

• #1 确保可复制的构建

和

• #3 为每个任务选择正确的粒度

Answer 2

尽管后端部分和前端部分来自不同的世界(Javascript上的.NET和SPA )，但它们仍然可以相互依赖。例如，前端部分(Javascript)可能在后端控制器上有链接，如果更改路由规则，则可能会破坏链接。这只是一个肤浅的例子，但在子系统之间存在大量依赖关系的复杂系统中，更可靠的方法是只进行一次构建。在这种情况下，您不需要考虑可能存在的潜在问题。

但是，您肯定需要以某种方式优化您的单个构建过程，因为1小时确实是很长的时间。

首先，单元测试(如果它们确实是单元测试)不应该有很大的依赖关系，并且应该运行得非常快，即使您有成千上万的依赖项。如果测试有像数据库这样的外部依赖项，那么它就是集成测试。您可以在不同的测试项目之间分离轻量级单元测试和重集成测试，或者以某种方式标记您的测试以允许TeamCity区分它们。例如，您可以在NUnit中使用“类别”属性将测试标记为"Unit“或"Integration”，并将TeamCity配置为只对每个构建运行单元测试。和运行集成测试手动+定期定期(例如，每晚和午餐时间)。

然后，您可以配置TeamCity --不要在每次提交的开发/测试环境中进行部署，而是在真正需要时手动部署它。这是正常的做法。

Answer 3

• 创建多个测试项目示例: Test.Unit.dll、Test.Integration.dll、Test.Acceptance.dll。
• 创建msbuild目标示例: RunOnlyUnitTest、RunOnlyIntegrationTest、RunOnlyAcceptanceTest，这样您就可以控制哪些目标在teamcity上运行
• 在team上，创建一个构建步骤，它只运行那些更快的测试:调用前面创建的RunOnlyUnitTest目标。创建另一个构建步骤，它运行更长的示例验收UI测试调用RunOnlyIntegrationTest目标，但是这个步骤可以根据需求每晚或每一小时运行一次。
• 另一种选择是在提交之前在本地运行基本的验收测试，这将在开发周期中节省大量时间。