Поддержание общей библиотеки среди сотен небольших приложений

58
7

У меня возник вопрос о создании общей библиотеки для очень большого количества небольших приложений. Недавно я присоединился к команде разработчиков. Мы собираемся расширить до 3. У нас есть более 200 приложений, которые мы поддерживаем. Все приложения поддерживают наши операции, и все они находятся в проектах развития дома.

Все эти приложения ссылаются на множество сторонних зависимостей, таких как dapper, nlog и т.д. Но ни одна ссылка не используется в домашней библиотеке.

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

Я думаю, что это помогает добавить последовательность в такие вещи, как электронная почта и ведение журнала, однако я не знаю, как управлять 200 приложениями, ссылающимися на одну версию библиотеки.

Моя первоначальная мысль заключалась в том, чтобы все 200 приложений ссылались на одну и ту же версию библиотек, которые автоматически перестраивались с помощью сборки CI, когда была изменена новая одна из ее зависимостей (библиотек), но из того, что мне сказали, это слишком рискованно и не поддерживается TFS.

Должен ли я позволить этим 200 приложениям ссылаться на различные версии общей библиотеки, которую я создаю, или это действительно не стоит проблем, и пусть все приложения расширяют свои собственные протоколирование, электронную почту и логику аудита?

Если общая библиотека является наилучшей практикой для этого, как вы отслеживаете, какое приложение использует какую версию библиотеки при обнаружении ошибок и т.д.

Изменить, чтобы уточнить из потенциального дублированного вопроса

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

спросил(а) 2015-10-12T21:42:00+03:00 4 года, 11 месяцев назад
1
Решение
69

Вы, вероятно, поддерживаете сторонние зависимости, такие как NLog, с использованием NuGet.

Почему бы не использовать NuGet для вашей внутренней библиотеки? Вы можете настроить фид NuGet с разумными усилиями.

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

В этих сценариях вы можете настроить настраиваемый фид NuGet, и вы можете настроить Visual Studio на предоставление этого фида вместо или в дополнение к официальному каналу. Канал может быть локальным (папка на локальном компьютере или сетевая папка) или удаленный (интрасеть или интернет-URL).

Источник: docs.nuget.org

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

ответил(а) 2015-10-12T21:49:00+03:00 4 года, 11 месяцев назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема