我一直在尝试在公司内部实施Nuget策略,我想知道在内部托管的TFS上处理内部项目时自动包恢复的真正价值是什么。
据我所知,在OpenSource项目中或使用外部托管源代码控制时,不检查外部软件包可以节省大量磁盘空间,但除了这一优势(节省服务器上的磁盘空间),我看不到任何其他优势自动恢复:实际上它给我们带来了一些问题,因为构建机器没有连接到互联网,并且为了使用该功能,我们要么改变防火墙规则,要么保留nuget存储库的本地缓存。
谢谢
答案 0 :(得分:2)
正如Steven在他的answer中指出的那样,保持包源不受源控制的主要原因是减少需要由源控制服务器存储和传输到源控制服务器的数据量。显然,在您控制所有硬件的公司中,磁盘空间和网络传输都不是问题,但如果您不需要,为什么要浪费处理软件包的磁盘空间/时间。请注意,包目录的大小可以占工作空间总大小的相当大的百分比。在我的情况下,当使用TFS(对于我的工作空间)时,packages目录占用总工作空间的80%-95%,而对于我的私有工作空间(基于git,因此具有.git)占50%-75%。占用一些空间的目录)。总而言之,如果您使用包恢复,则可以在源控制服务器上保存大量空间。
使用Nuget.org解决访问问题的一种方法是拥有自己的local package repository。此本地软件包存储库可以是本地nuget web service,也可以只是服务器上的共享目录。由于存储库位于公司LAN内部,因此构建服务器访问本地nuget存储库不应该是一个大问题。 这种方法的一个附带好处是你的构建过程独立于Nuget.org(在非常罕见的情况下它会发生故障),更重要的是,你确切知道哪些软件包被拉入构建中(因为它们将被批准)本地存储库中的包。)
对于我们来说,决定是否使用本地nuget存储库和包恢复选项取决于我们决定将所有内部库打包为nuget包(我已将answer中的开发过程描述为另一个nuget问题)。因此,我们需要一个本地软件包存储库来分发这些内部软件包。这意味着将第三方软件包添加到此存储库很容易,因此使用软件包还原非常有意义。 如果您不将内部库打包为nuget包,那么您将把它们放在源代码管理中与解决方案和代码文件一起。在这种情况下,您也可以为第三方库做同样的事情。
最后,这完全是一种权衡。磁盘空间与基础架构设置的简易性等。选择最适合您环境的解决方案。
答案 1 :(得分:1)
最初的NuGet工作流程一直是将Packages文件夹提交到源代码管理中。原因是它匹配开发人员在没有NuGet时通常会做的事情:他们创建一个
Lib
或ExternalDependencies
文件夹,将二进制文件转储到那里并将它们提交给源控件以允许其他人构建。
因此,我们的想法是在将构建项目的每台机器上恢复软件包,以便二进制数据不受源代码控制。使用像Mercurial或Git这样的分布式源代码控制系统,即在客户端机器和服务器上使用的磁盘空间和带宽。
但是当你的构建机器无法连接到互联网nuget.org(我假设)时,这确实会造成问题。我认为你已经达到了主要的解决方案。将包提交给源代码控制并避免包恢复,允许构建计算机连接到Internet或设置本地镜像。
我不会说你的环境中没有包恢复的优点。我认为提交包裹没有太大的危害。但这实际上取决于您的团队如何运作,您的团队期望什么以及您正在从事的企业环境类型。