Управление внутренними сторонними Зависимостями
У нас есть много различных решений/проектов, которыми управляют различные команды. Наше решение должно сослаться на несколько проектов, которыми владеет другая команда. Мы не хотим добавлять эти зависимости как ссылки проекта, потому что мы не предназначаем при изменении того кода, мы просто хотим использовать его. Также мы уже имеем довольно мало проектов в нашем решении и не хотим добавлять набор больше, так как оно замедлит Visual Studio. Таким образом, мы разрабатываем эти проекты в разном решении и добавляем их как ссылки на файл на наше решение.
Мой вопрос, как люди управляют этими типами зависимостей? У меня должен просто быть некоторый автоматизированный процесс, что ищет изменения в тех проектах, создает их и проверяет dlls в нашем управлении исходным кодом, после которого мы рассматриваем их как другие сторонние зависимости? Существует ли рекомендуемый способ сделать это?
2 ответа
Одно из решений, хотя оно не обязательно является тем, что вы ищете, состоит в том, чтобы каждая зависимая подсистема выполнила выпуск. Этот выпуск может иметь форму установки MSI или просто сетевой ресурс сборок. Когда будет внесено значительное изменение, эта команда может сообщить вам об этом, и вы можете запустить установку или сценарий для копирования файлов.
Как только вы получите выпуск, вы можете поместить их в GAC, таким образом, вам не придется беспокоиться о копировании их в папки корзины вашего проекта.
Другое решение, предполагающее, что вы используете сервер сборки или какую-то непрерывную интеграцию, состоит в том, чтобы выполнить этап после сборки или обработать файлы. Чем в любой момент времени разработчики других команд могли захватить новые файлы или иметь файл сценария или bat-файла для их локального скачивания.
РЕДАКТИРОВАТЬ - ДРУГОЕ РЕШЕНИЕ Было бы лучше спросить, почему у вас эти зависимости? Вы действительно нуждаетесь в них локально при создании своей части приложения? Не могли бы вы смоделировать зависимости в своем решении, что позволит вам кодировать, создавать и запускать модульные тесты? Фактическое приложение подключит их к вашим средам DEV / Test / Prod. Развязка и независимость вашего решения может быть лучшим решением для отдельной команды. Оставьте интеграцию и связывание, когда приложение работает в реальных условиях.
( Не полный ответ, но все же: )
Любую доставку лучше хранить в файловом / двоичном репозитории, в отличие от VCS, используемой для управления историей источников .
Мы предпочитаем управлять этими доставками в репо, например Nexus , и мы используем maven , чтобы вернуть правильные зависимости.
Даже если эти инструменты могут быть более ориентированы на Java, Nexus может хранить что угодно, а maven существует только для чтения pom.xml каждого артефакта и вычисления правильных зависимостей.