Совместное использование общих библиотек в большой команде и отслеживание того, какая версия библиотек используется

Question

Я принадлежу к магазину .NET с использованием TFS. В прошлом году или около того мы пытались поделиться и между нашими командами (некоторые местные, некоторые в совершенно другом регионе).

До сих пор мы использовали общий код в качестве ссылок на проекты. По мере роста зависимости от общего кода у нас возникают все больше проблем (люди изменяют код, который нарушает другие приложения, обновляет проект до новой версии Visual Studio и т. Д.). В результате я склоняюсь к тому, чтобы люди ссылались на код как скомпилированные двоичные файлы (dll). Сам код будет поддерживаться и регулярно обновляться назначенной командой. Исходный код будет доступен только для чтения, чтобы люди могли вносить изменения/исправления и отправлять его в команду для проверки и перераспределения. Что вы думаете об этом плане? Есть ли способ лучше?

Я чувствую, что недостатком этого плана является то, что я торгую одним набором головных болей для другого. Если у меня много разных версий библиотеки, как я могу точно знать, какие версии используются, а какие нет? Есть ли способ сделать это через TFS? Я считаю, что если мы точно знаем, какие версии используются, мы можем знать, в какой степени нам приходится беспокоиться о обратной совместимости, с кем мы можем связаться, если у нас есть проблемы и т. Д.

Как некоторые из вас, люди на больших командах справиться с этим?

Answer 1

ссылка код, как откомпилированном (DLL)

Это хорошая идея. В краткосрочной перспективе общие ссылки на проекты могут чувствовать себя легче, но это усложняет работу, если у вас нет хороших регрессионных тестов. Даже тогда лучше рассматривать общие библиотеки проекта/продукта сами по себе. Имейте отставание и Командный проект, посвященный этому достижению.

я могу знать наверняка, какие версии используются и которые не являются

Мой первый вопрос, почему вы заботитесь? Разрешить те, которые зависят от разделяемых библиотек, обновлять и принимать новые версии, поскольку их конкретная временная шкала и пропускная способность позволяют. Основная причина, по которой вам, вероятно, понадобится , требует потребляющих проектов/продуктов для обновления, чтобы иметь дело с обесцененными функциями или правилами. Например, вы можете развертывать общую библиотеку отчетов об ошибках, которая обесценивает механизм отправки отчета о сбое, поскольку теперь вы требуете HTTPS. Старые версии больше не будут работать. В этом случае общение будет вашим лучшим выбором, но вы можете запустить скрипт по всем сборкам, найденным в TFS, для просмотра версии сборки.

Answer 2

Как я могу знать наверняка, какие версии используются и которые не являются

Пара вещей:

• Поддерживайте столько изоляции, как вы можете между кодом приложения и ваш библиотеки. Используйте приятные и стабильные интерфейсы.

• Сделайте свои разработчики ответственными за получение последних версий библиотек, прежде чем они будут выполнять свою локальную работу/компиляцию. Личная личная ответственность - это хорошо.

• Беспокойство об интерфейсах во время сборки. Убедитесь, что ваша сборка получает самую последнюю версию библиотек до ее сборки.Если ваши разработчики допустили ошибку, это станет очевидным.

• Используйте только свои официальные сборки для тестирования и выпуска. Локальные сборки могут использоваться для некоторого модульного тестирования, но как только вы присоединитесь к интеграции, только официальные сборки должны быть приемлемыми.

Answer 3

Мы занимаемся распространением сборок в разных командах. Если метод или перегрузка должны быть изменены в определенной версии, мы сохраняем старый метод как [Obsolete("message")], добавляем новый метод, а затем в следующих версиях мы удаляем устаревший метод. Таким образом, разработчикам достаточно времени для использования более новых версий.