Нам нужно найти разумный способ управления нашими собственными библиотеками .NET, которые потенциально могут быть повторно использованы несколькими проектами. Погуглив и подумав о проблеме в течение нескольких часов, я пришел к следующему выводу, с которым я хотел бы пойти дальше:
На нашем сервере сборки (Jenkins) будет отдельная работа для каждой версии каждой имеющейся у нас библиотеки. После успешной сборки библиотеки выходные данные сборки (чаще всего файл .dll) будут скопированы в общий сетевой репозиторий. Структура этого хранилища может быть похожа на это:
-libraryA
-1.0
-libraryA_1.0.dll
-1.1
-libraryA_1.1.dll
-libraryB
-1.0
-libraryB_1.0.dll
Каждый проект, который хочет использовать библиотеку, будет поставляться с простым файлом .bat, который будет копировать необходимые библиотеки из этого репозитория в папку, специально предназначенную для хранения зависимостей проекта. Затем зависимости будут ссылаться из этой папки. Пример проекта может выглядеть так:
-project
-src
-dependencies
-libraryB
-1.0
-libraryB_1.0.dll
-getDependencies.bat
getDependencies.bat всегда удаляет содержимое папки dependencies и получает свежую копию библиотек из хранилища. Он будет выполняться перед каждой сборкой проекта на Jenkins. Папка dependencies никогда не будет передана в SVN.
Некоторые альтернативы, которые я также рассмотрел:
- Использование собственного канала NuGet вместо простого репозитория. Я отказался от этого, потому что, как я выяснил, довольно тяжело использовать NuGet из Visual Studio 2008, который все еще используется в нашей компании. В противном случае, это было бы моим предпочтительным решением.
- Использование svn: externals для разрешения зависимостей. Мне это не нравится по двум причинам:
- Вместо того, чтобы иметь дело только с двоичными файлами (как в решении, описанном выше), svn: externals заставляет меня иметь дело с исходным кодом. Я не хочу загромождать каждый проект, использующий библиотеку, с ее исходным кодом.
- Каким-то образом управление зависимостями с помощью SVN (которое, по моему мнению, по крайней мере, должно использоваться для управления версиями ) не кажется правильным. Я также думаю, что svn: externals затрудняет отслеживание зависимостей конкретного проекта и делает проект слишком зависимым от SVN.
Я бы очень признателен, если бы кто-то мог указать на возможные проблемы с моим предпочтительным решением или просто на то, что, по вашему мнению, не так с ним. Кроме того, если я пытаюсь заново изобрести колесо и уже есть какое-то стандартизированное решение, которое используют все (кроме упомянутых мною альтернатив), пожалуйста, не стесняйтесь меня просветить :)
Большое спасибо!