在大型团队中共享公共库跟踪正在使用的库版本
我属于一家使用 TFS 的 .NET 商店。在过去一年左右的时间里，我们一直在尝试在我们的团队（一些是本地的，一些在完全不同的地区）之间共享。
到目前为止，我们已将共享代码作为项目参考包含在内。随着对共享代码的依赖不断增加，我们遇到了越来越多的问题（人们修改破坏其他应用程序的代码、将项目更新到新版本的 Visual Studio 等）。因此，我倾向于让人们将代码引用为已编译的二进制文件 (dll)。代码本身将由指定的团队维护和定期更新。源代码将以只读方式提供，以便人们可以进行更改/修补并将其提交给拥有团队进行审查和重新分发。你觉得这个计划怎么样？有更好的办法吗？
我觉得这个计划的缺点是我用一组头痛换了另一组头痛。如果我有一个库的许多不同版本，我如何确定哪些版本正在使用，哪些版本没有？有没有办法通过 TFS 来做到这一点？我相信，如果我们确切地知道正在使用的版本，我们就可以知道我们在多大程度上需要担心向后兼容性，如果我们有顾虑应该联系谁，等等。
大型团队中的一些人如何处理这个问题？
I belong to a .NET shop using TFS. In the last year or so we've been trying to share and between our teams (some local, some in a completely different region).
Up until now, we've included shared code as project references. As the dependency on the shared code grows, we're getting into more and more problems (people modifying code that breaks other apps, updating project to new version of Visual Studio, etc.). As a result, I'm leaning toward having people reference the code as compiled binaries (dlls). The code itself will be maintained and regularly updated by an assigned team. Source code will be available as read only so that people can make changes/patches and submit it to the owning team for review and redistribution. What do you think of this plan? Is there a better way?
I feel that the downside to this plan is that I'm trading in one set of headaches for another. If I have many different versions of a library, how can I know for sure which versions are being used and which aren't? Is there a way to do this through TFS? I believe that if we know exactly what versions are being used, we can know to what extent we have to worry about backward compatibility, who to contact if we have concerns, etc.
How are some of you folks on large teams handling this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我们确实将程序集分发到不同的团队中。如果必须在特定版本中更改方法或重载，我们会将旧方法保留为
[Obsolete("message")]，添加新方法，然后在下一个版本中删除已弃用的方法。这样，开发人员就有足够的时间使用更新的版本。We do distribute assemblies across different teams. If a method or an overload must be changed in a specific version, we preserve old method as
[Obsolete("message")], add new method and then in next versions we remove deprecated method. This way, developers have enough time to use newer versions.以下几点：
在应用程序代码和库之间保持尽可能多的隔离。使用良好且稳定的界面。
让您的开发人员负责在进行本地工作/编译之前获取最新版本的库。个人责任是一件好事。
在构建过程中担心接口。确保您的构建在构建之前获取最新版本的库。如果您的开发人员犯了一个错误，它会在这里变得很明显。
仅使用您的官方版本进行测试和发布。本地构建可用于某些单元测试，但一旦进行集成，就只能接受官方构建。
A couple things:
Maintain as much isolation as you can between your app code and your libraries. Use interfaces that are nice and stable.
Make your developers responsible for getting the most recent versions of the libraries before they do their local work / compiling. Personal individual responsibility is a good thing.
Worry about the interfaces during your builds. Make sure your build gets the latest version of the libraries before it builds. If your developers have made a mistake, it will become apparent here.
Only use your official builds for testing and release. Local builds can be used for some unit testing, but once you get to integration, only official builds should be acceptable.
这是一个好主意。从短期来看，共享项目参考可能会感觉更容易，但除非您有良好的回归测试，否则它会让事情变得更加困难。即使如此，最好将共享库本身视为一个项目/产品。拥有专门用于该可交付成果的积压工作和团队项目。
我的第一个问题是，你为什么关心？允许那些依赖共享库的人在其特定的时间线和带宽允许的情况下升级并采用新版本。您可能需要消耗项目/产品来升级的主要原因是处理折旧的功能或规则。例如，您可能正在部署一个通用的崩溃报告库，该库会贬低发送崩溃报告的机制，因为您现在需要 HTTPS。旧版本不再有效。在这种情况下，通信将是您的最佳选择，但您可以对 TFS 中找到的所有程序集运行脚本来查看程序集版本。
This is a good idea. In the short term, shared project references can feel easier, but it makes things more difficult unless you have good regression tests. Even then it is better to consider shared libraries a project/product in-and-of themselves. Have a backlog and Team Project dedicated to that deliverable.
My first question is, why do you care? Allow those that depend on the shared libraries to upgrade and adopt new versions as their particular timeline and bandwidth allows. The primary reason you'll likely require consuming projects/products to upgrade is to deal with depreciated features or rules. For instance, you may be deploying a common crash reporting library that depreciates a mechanism for sending a crash report because you are now requiring HTTPS. Older versions no longer will work. In this case, communication is going to be your best bet, but you could run a script over all the assemblies found in TFS to look at the assembly version.