TFS CI构建链 [英] TFS CI Build Chain

问题描述

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

In an effort to introduce reusable code at my new employer I've elected to create a class library that will be referenced by 200+ existing small applications. This library contains logging, dbconnection logic, etc.

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

Is there a way to setup TFS online's build service to automatically determine which projects have referenced this common library as a nuget package? I'd like them to build after (or part of) the CI build for the common library runs.

依赖于nuget包的项目确实存在于

The projects that will depend on the nuget package do exist in the same TFS Team Project, but are not in the same branches, each application has its own set of branches.

推荐答案

不是真的，但是不是在同一个分支，每个应用程序都有自己的分支。

Not really, and I'd say that what you want to do kind of defeats the purpose of NuGet.

你有200个应用程序使用这个公共库。共同的图书馆可能工作。真棒。当您发布新的生产稳定版本的软件包时，您应该压制其版本号，并让使用旧版本的所有内容继续这样做。

You have 200 applications consuming this common library. The common library presumably works. Awesome. When you release a new production-stable version of the package, you should bump its version number and let everything that's using the old version continue to do so.

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

It should be the responsibility of the consumer of that library to choose whether to update it or not when a newer version is made available. The team responsible for each application should be able to make a conscious decision to upgrade the component.

此外，请记住单一责任原则。有一个包含日志记录，数据库逻辑和其他完全不相关的东西的上帝大会听起来像一个真正的坏主意，特别是如果这些事情将继续随着时间的推移。你会碰到一种情况，一个应用程序需要在数据库块中的新特性X，但不幸的是有人在几个星期前在记录器逻辑中发生了无关的中断更改Y.现在你必须将不相关的破裂更改Y集成到你的应用程序中，即使你不想要或不需要它。

Also, keep the single responsibility principle in mind. Having a "god assembly" that contains logging, database logic, and other totally unrelated stuff sounds like a really bad idea, especially if these things are going to continue to evolve over time. You'll bump into a situation where an application needs New Feature X in the database piece, but unfortunately someone made Unrelated Breaking Change Y in the logger logic a few weeks ago. Now you have to integrate Unrelated Breaking Change Y into your application even if you don't want or need it.

这篇关于TFS CI构建链的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！