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

Question

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

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

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

Answer 1

ссылаться на код как на скомпилированные двоичные файлы (dlls)

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

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

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

Answer 2

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

Answer 3

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

Пара вещей:

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

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

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

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