Mat*_*lis 2 tfs visual-studio azure-devops
我们目前正在将源代码管理迁移到Visual Studio Online.我们旧系统(SourceGear Vault)中的一个功能是在解决方案之间共享项目.虽然这为我们的Framework项目在每个解决方案中创建了一个文件夹,但它在检查更改时保持了最新状态.
这对我们很有用,因为它允许我们在使用它的所有解决方案中处理框架代码.我知道编译dll并引用它们的更好的做法 - 在开发的这一点上,我们希望继续使用这个核心框架在所有解决方案中进行完整的代码访问和调试.
任何帮助非常感谢.
您有一些同样有效的选项来处理共享项目:
这使您可以在使用消费解决方案时完全控制共享项目的源代码,并且可以允许更容易的调试.
这里的缺点是,如果解决方案A在周四发布,维护和发布可能会变得更加棘手,但解决方案B将在3个月内发布,并处于一个巨大的重构周期中,该周期已经显着修改了共享组件X和共享组件X不够稳定,无法释放.
您设置发布管道以将共享组件推送到NuGet作为发布过程的一部分(理想情况下,使用专门构建的发布管理工具...... Microsoft Release Management就是我在这里想到的) - 您检查代码在,项目建成.发布过程将其打包并将其作为"预发布"版本推送到NuGet.您可以在需要最新版本的任何内容中引用最新版本.如果您需要引用已知良好的稳定版本,只需确保您的项目配置为从NuGet中提取特定版本.
当你完成后,你已经测试了共享的东西,你知道一切都很好,你批准了预发布版本,并且相同的二进制文件被重新打包成"稳定"版本.
这里的缺点是您的团队还有一些额外的软件要求,配置和培训.这将是我推荐的方法.
我不推荐这个 - 你最终膨胀你的源代码控制仓库(如果你使用Git,它是一个明确声明的反模式 - 永远不会将二进制文件放入Git,它会导致长期严重的性能问题) ,并且从来都不清楚哪些项目正在使用哪个版本的程序集.这是一场维护噩梦.
(1)如果您以锁步方式发布所有内容并且不必担心维护单独的版本,则是最佳方法.
(2)如果#1为假,则是最好的方法.
(3)如果#1是假的,那么这是最好的方法,你是2006年发布的时间旅行者.
| 归档时间： |
|
| 查看次数： |
1208 次 |
| 最近记录： |