我的团队有一个持续集成服务器（目前是TeamCity但没关系）和大型 Visual Studio 项目，大约需要1小时才能完成完整的CI流程签入（构建，运行单元测试，在测试服务器上部署......）。
解决方案分为两部分，Backend是完全.NET堆栈项目（Windows服务，Web项目等）和包含大量JavaScript和前端事物的前端单页应用程序。
持续1小时的持续集成构建过程约占后端代码，构建，单元测试的90％......
这是大型项目的常见方案，我希望您分享您的最佳实践和建议 如何以某种方式对触发逻辑进行“智能”检查，解决方案的每个部分（前端，后端）都不会为另一部分启动构建过程。
答案 0 :(得分：1)
在你的情况下这个
大型项目的常见场景
可以在下一步更好地处理 - Continuous delivery。由于您描述的所有操作都是自然的。关于
的部分持续集成构建过程需要1小时，大约是后端代码，构建，单元测试的90％。
这个article提供了非常好的解决方案 - 并行测试。当然，它的协议取决于您的环境。基本的想法是processor parallelism - 如果做得好，执行/学位将非常有效。在分析了您的所有目标和资源之后。如果这种自动化正确完成 - 测试工作量将大大减少。
部分
make＆＃34; smart＆＃34;以某种方式检入触发器逻辑，解决方案的每个部分（前端，后端）都不会为另一个部分启动构建过程
并且记住了
持续集成服务器（但并不重要）
在details here中描述了一个非常好的解决方案（使用Jenkins编排交付管道）。也许对你最有价值的是：
和
答案 1 :(得分：1)
尽管Backend part和Frontend部分来自不同的世界（Javascript上的.NET和SPA），但它们仍然可以相互依赖。例如，您的前端部分（Javascript）可能在Backend控制器上有链接，如果您更改路由规则，该链接可能会被破坏。它只是一个浅薄的例子，但在子系统之间有很多依赖关系的复杂系统中，更可靠的方法是单一构建。在这种情况下，您无需考虑可能存在的潜在问题。
但是，你肯定需要以某种方式优化你的单个构建过程，因为1小时是一段很长的时间。
首先，单元测试（如果它们实际上是单元 - 测试）不应该具有很大的依赖性，并且应该运行得非常快，即使你有数千个。如果test具有像数据库这样的外部依赖项，则它是 Integration -test。您可以在不同的测试项目之间分离轻量级单元测试和繁重的集成测试，或以某种方式标记您的测试以允许TeamCity区分它们。例如，您可以使用＆＃34;类别＆＃34; NUnit中的属性将测试标记为＆＃34; Unit＆＃34;或者＆＃34;整合＆＃34;并将TeamCity配置为仅对每个构建运行单元测试。并定期手动+定期运行集成测试（例如，每晚和午餐时间）。
然后，您可以配置TeamCity在EACH提交时不在dev / test环境上部署，而是在真正需要时手动部署它。这是正常的做法。
答案 2 :(得分：0)