Управление общими библиотеками .net в небольшой компании (более 50 разработчиков)

Question

В моей компании более 50 разработчиков.Существует около 9 проектов, которые используют много общих библиотек (более 20). Этот процесс с каждым днем ​​становится все сложнее.Основные проблемы:

1. , как отслеживать, что было изменено в каждой версии библиотеки
2. , где хранить эти сборки.Теперь мы используем общий диск и у нас есть соглашение: /lib/version/*.dll
3. о том, как автоматически вставлять правильные библиотеки во время сборки.В настоящее время мы используем файл .targets в Visual Studio, который мы обновляем вручную.

Как вы управляете этим аспектом в вашей компании?

Answer 1

Пока я этого не сделал, вы можете попробовать собрать ваши библиотеки в виде пакетов Nuget и запустить внутренний сервер Nuget для их обслуживания.

http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds

Мы начинаем делать то же самое с нашими библиотеками Ruby, которые нам нужно разделить между командами - упаковать их как гемы и обслуживать их с внутреннего сервера гемов.

Answer 2

Я запускаю бесплатную версию TeamCity, которая может автоматически создавать проект (требуется некоторая настройка MSBuild), а затем выводить файл, опубликованный в TeamCity с ссылкой для загрузки, например: http://10.0.0.194:8111/guestAuth/repository/download/bt3/.lastSuccessful/Project.dll. В моем проекте я перезаписываю «BeforeBuild»раздел MSBuild и загрузите файл Project.dll по этой ссылке - я уверен, что:

• Я использую последнюю версию Project.dll (она всегда сохраняется в той же http-ссылке)
• Скачанная мной dll (или любая другая) прошла некоторые тесты (зависит от конфигурации TeamCity)
• Я работаю независимо от другого программиста, потому что у меня нет ручного копирования / вставки или использования общего диска
• Доступен из любой IDE / программы / любой другой, которая может получить доступ к сайту и загрузить файл (Java, C ++, Python и т. Д.)
• и т. Д., Т. Д. И т. П. *