Frameworks TFS：如何缓存框架构建以减轻构建过程？

我最近被分配到一个发布工程团队，努力使我们的构建过程更易于管理。在我们的产品历史中，我们只是在版本控制存储库中用每个构建构建所有内容，因为这样做并不需要太多时间。这包括我们拥有源代码的第三方产品（例如，包括企业库）、我们自己的内部框架代码，最后是产品本身。然而，经过几年稳定的产品增长，这已经成为一个非常繁琐的过程

这就是说，我们希望建立一种分层构建系统，其中每天只构建产品（每天都在更改），而我们的框架代码（更改频率要低得多）和第三方代码（几乎从不）仅在更改时构建。我们设置了一个symbol&source服务器来帮助调试代码，比如我们的框架库，这些库不是新构建的，每个版本都有，但我们仍在研究如何帮助调试。作为记录，我们使用TFVC进行源代码控制

我的问题是：什么样的实践被用于这类事情？我们是否为此构建的每个“层”设置了单独的团队项目（即第三方团队项目、框架团队项目、产品团队项目），并将它们相互分支？我们是否曾经将一层的构建产品检入下一层以确保依赖关系得到解决？如果没有，二进制文件在哪里？这些要求是否要求我们使用GAC

最后，如果有任何关于这类事情的指导，我喜欢做一些阅读；但是，由于我是构建/发布工程的新手，我还不知道该去哪里寻找

---

谢谢

首先回答最后一个问题，这里有一个关于构建配置和管理的问题

关于您的第一个问题：我们单独处理依赖关系。我们有一个编译框架的构建。我们有另一个编译我们自己项目的构建

但是，作为第二次构建过程的一部分，我们在编译自己的项目之前，从构建机器上的框架构建安装了安装程序

这样，我们可以将框架与项目分开发布。我们的项目可以决定（通过修改构建配置）何时开始使用新版本

---

项目和框架都有自己的TFS项目

太棒了。粗略地说，这就是我一直在构思的方法。自动化框架安装的想法非常有趣！这一部分我没有想到，而是以某种方式使用源代码管理来管理二进制文件。然而，只有通过使用安装程序才能使不同的构建相关，这无疑是有吸引力的。这是否意味着当您发货时，必须运行几个安装程序才能安装产品，或者依赖项是否在最终产品安装程序中重新打包？此外，我猜您提供的链接将是，但我很高兴它是其他的东西！我有点不高兴它不在kindle上，但我还是订购了它——读起来很兴奋！我们做了一个单独的安装。因此，客户机必须先安装框架，然后安装应用程序。但是您可以创建一个单独的安装程序，将您的框架和应用程序结合起来。只需为每个模块创建一个mergemodule，并创建一个只安装mergemodules的安装程序。