大型项目的持续集成最佳实践答案

【问题标题】：Continious Integration best practice for large project大型项目的持续集成最佳实践
【发布时间】：2014-12-19 08:15:04
【问题描述】：

我的团队有一个 Continuous Integration 服务器（目前是 TeamCity，但没关系）和大型 Visual Studio 项目，完成后大约需要 1 小时才能完成完整的 CI 流程签入（构建、运行单元测试、在测试服务器上部署...）。

解决方案分为两部分，后端是完全 .NET 堆栈项目（Windows 服务、Web 项目等）和包含大量 JavaScript 和前端事物的前端单页应用程序。

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

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

【问题讨论】：

我不太清楚你到底想知道什么？例如，我们只有一个构建配置，它为存储库中的每个更改构建所有内容（前/后），并将 10 分钟左右的更改组合在一起。我们不使用多个构建/依赖项，因为 a）我们还希望每个成功的构建都是完整的产品并且可以这样使用 b）这意味着我们可以使主构建脚本在任何地方保持简单和可用，在命令行或其他 CI服务器以及，如果需要的话。这些是你想知道的吗？
@stijn，感谢您的回复。我想要关于如何分离前端和后端应用程序的最佳实践，以便前端签入会导致仅前端部分的构建过程开始，而后端仅签入后端构建过程。
原因很简单，前端应用程序是用纯前端堆栈、AngularJS 等编写的。并且不依赖于 .NET 框架或任何其他服务器端代码。但是，如果我的前端开发人员签入他的 JavaScript，它将触发整个解决方案（前后）的构建过程，这需要大约 1 小时，而仅前端代码的“构建/单元测试/部署”过程不超过10 分钟。

标签： testing msbuild continuous-integration teamcity development-environment

【解决方案1】：

在你的情况下

大型项目的常见场景

可以在下一步处理得更好 - Continuous delivery。因为你描述的所有动作对它来说都是自然的。关于与

的部分

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

article 提供了非常好的解决方案 - 并行测试。当然，同意它取决于您的环境。基本思想是processor parallelism-like 执行/度如果处理得当将非常有效。在分析了你所有的目标和资源之后。如果正确地完成了这种自动化 - 测试工作将大大减少。

与部分

以某种方式“智能”检查触发逻辑，即解决方案的每个部分（前端、后端）不会为另一个部分启动构建过程

并假设

持续集成服务器（但没关系）

details here 中描述了一个非常好的解决方案（使用 Jenkins 编排交付管道）。也许对您最有价值的是：

#1 Ensuring reproducible builds

和

#3 Choosing the right granularity for each job

【讨论】：

【解决方案2】：

尽管后端部分和前端部分来自不同的世界（.NET 和 Javascript 上的 SPA），但它们仍然可以相互依赖。例如，您的前端部分（Javascript）可能在后端控制器上有链接，如果您更改路由规则，该链接可能会被破坏。这只是一个肤浅的例子，但在子系统之间有很多依赖关系的复杂系统中，更可靠的方法是 single build。在这种情况下，您无需考虑可能遇到的潜在问题。

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

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

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

【讨论】：

【解决方案3】：

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

【讨论】：