Это хороший подход для управления общими библиотеками?

Question

Нам нужно найти разумный способ управления нашими внутренними библиотеками.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.

Я был бы очень признателен, если бы кто-то мог указать на возможные проблемы с моим предпочтительным решением или просто на то, что, по вашему мнению, не так. Кроме того, если я пытаюсь изобрести велосипед, и уже есть какое-то стандартизированное решение, которое используют все (кроме упомянутых мною альтернатив), пожалуйста, не стесняйтесь меня просветить:)

Большое спасибо!

Answer 1

Вам нужны только отдельные версии ваших библиотек для внесения изменений. Добавление новых функций и исправление ошибок не гарантирует новую версию. Кроме того, проекты, использующие библиотеки, должны хранить копию бинарного файла, который они используют, в своем исходном репозитории.

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