TFS CI 构建链答案

【问题标题】：TFS CI Build ChainTFS CI 构建链
【发布时间】：2015-10-10 04:13:15
【问题描述】：

为了在我的新雇主那里引入可重用代码，我选择创建一个类库，该类库将被 200 多个现有的小型应用程序引用。该库包含日志记录、dbconnection 逻辑等。

有没有办法设置 TFS online 的构建服务来自动确定哪些项目将这个公共库引用为 nuget 包？我希望他们在公共库运行的 CI 构建之后（或部分）构建。

将依赖 nuget 包的项目确实存在于同一个 TFS 团队项目中，但不在同一个分支中，每个应用程序都有自己的一组分支。

【问题讨论】：

标签： c# .net tfs continuous-integration

【解决方案1】：

不是真的，我想说你想做的事有点违背 NuGet 的目的。

您有 200 个应用程序在使用这个公共库。公共图书馆大概可以工作。惊人的。当你发布一个新的生产稳定版本的包时，你应该增加它的版本号，让所有使用旧版本的东西继续这样做。

当有更新的版本可用时，该库的消费者应该有责任选择是否更新它。负责每个应用程序的团队应该能够有意识地决定升级组件。

此外，请牢记单一责任原则。拥有一个包含日志记录、数据库逻辑和其他完全不相关的东西的“上帝集合”听起来是个非常糟糕的主意，尤其是如果这些东西会随着时间的推移继续发展的话。您会遇到这样一种情况，即应用程序需要数据库中的新功能 X，但不幸的是，几周前有人在记录器逻辑中进行了无关的重大更改 Y。现在，即使您不想要或不需要它，您也必须将 Unrelated Breaking Change Y 集成到您的应用程序中。

【讨论】：

我们所有的应用程序都在内部运行以支持操作。现在，200 个应用程序中的每一个都包含它自己的日志记录、第 3 方微 ORM 和电子邮件逻辑。我将核心库作为单独的程序集启动，但我觉得我可以通过创建“上帝程序集”来减少依赖关系树的层数。我试图避免的一件事是必须手动更新 nuget 包并手动重建所有正在使用的应用程序。在为 200 个应用程序提供可重用代码库时，我应该采取另一种架构方法吗？
@TonyStewart871，正如上面 Daniel 所说，您可以使用 NuGet 管理器检查是否有可用的新版本，并确定是否将包更新到最新版本。应用新版本后，您可以手动为应用程序的构建排队。