只要您通过CI构建服务器开发,一切都很好：
>获取A和B的最新来源,其中B取决于A
>修复A中的错误
>建立一个
>检查源代码管理
> CI Build Server已启动
>创建新的nuget包并将其放置在公司存储库中
>构建B(将获得更新的A包)
>运行B以验证A中的错误是否已修复
ñ.重复n次
但是,我想知道是否可以在本地作为单个开发人员工作,而不必等待CI Build Server生成新的包？
Nuget有一个功能Package Restore,它将在构建时自动下载所有依赖项.您还可以列出程序包还原应查找程序包的存储库顺序.
如果工作流程可能变为：
>获取A和B的最新来源,其中B取决于A
>修复A中的错误
>建立一个
>(构建创建本地nuget包)
>运行B来测试A中的(已解决的)错误(现在应该使用我们的本地nuget包,而不是本地存储库)
> …重复n次
>检查源代码管理
> CI Build Server已启动
>在企业存储库中创建的新nuget包
这可能使用Visual Studio,MSBuild,CI构建服务器和nuget吗？我特别感兴趣的是在本地开发时制作本地包.
请注意,我有本机项目,但除了生成nuget包后构建时,这将是一个工作流程,我希望它应该适用于C#和C项目.
我现在所拥有的解决方案,虽然远非理想,但我能找到最好的解决方案.哦!这是一项正在进行中的工作,因此我会在未来几周/几个月内改变,因为我想知道如何解决问题.我现在大部分都要处理托管DLL,但我确实有一些本机代码和最差的多平台本机代码来处理.
创建一个本地存储库,基本上只是一个文件夹,并在您的nuget供稿列表中进行配置.
然后我创建了一个任务(MSBuild),它将打包项目并将其输出到本地存储库的根文件夹中.确保包的版本始终在增加.目前我通过编辑程序集版本手动执行此操作.
构建完成后,更新引用它的其他项目,我通常通过包管理器控制台(update-package)执行此操作.
每个项目都经过更新,提升了他们的版本冲洗车床并重复,直到你到达最顶层的项目(实际程序).
一旦一切都很好并且您已经准备好提交,那么构建系统应该自己打包并将其发送到您的官方存储库.
好的
>没有堵塞存储库和构建具有中间开发版本的系统,垃圾仍然(应该)本地.
>本地回购非常容易设置,甚至可以在不改变VS的情况下通过全局nuget配置完成.
>这对包恢复或包含项目的签入包的范例都很友好.这就是说我建议不要检查你在本地构建的软件包,而是选择一个通过构建系统提交到本地存储库的软件包.本地建造的应该保留在当地.
坏
>比仅仅将项目添加到解决方案还要复杂得多.
>你的依赖树越深(或越宽),痛苦就越大.
丑陋的
>使一些原生的nuget行为相当古怪和烦人：
>如果您的VS连接到版本系统(对我来说是perforce),则更新操作将永久进行.我听说他们“解决”了这个问题,如果它现在是最糟糕的话,那就不愿意看看它是怎么回事！
>让nuget将非代码引用更改为永不复制是一个主要的痛苦.
要是
>直接从nuspec配置内容依赖项的所需状态(永远复制,永不复制或更新)并完成它！ (与ClickOnce内容状态相同的故事包括,排除等)
>快速更新操作,对于十几个项目来说,2分钟就是疯了,特别是如果最终目标是管理500个.
>也许是一种混合模式,在本地我们使用项目包含,但构建系统将使用nuget依赖(并在必要时构建它们)
>如果要解析项目,请遵循MSBuild解析规则并遵守条件语句.
我还有一些问题尚未弄清楚如何管理存储库中代码的多个分支.如何在食物链中进一步处理版本冲突.在一个大型项目中(最终我们必须在一个应用程序可执行文件中将500个单独的项目放在一起,预计会发生冲突).
我很想带来Maven理智的依赖管理,但到目前为止,我还没有发现nuget足够成熟甚至想到向开发团队提出建议.