управление и управление версиями общих библиотек в разных проектах

Question

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

Вопрос, который у меня возникает, - как бы вы убедились, что они управляются должным образом?

Ссылка на проект трассировки непосредственно из windows app1

Плюсы: вам не нужно объединяться и разветвляться.

Минусы: Вы можете создавать проблемы в системах при перекомпиляции кода. с тех пор его компилируют с последней версией.

Отключите трассировку для каждого проекта и время от времени объединяйте их плюсы и минусы являются полной противоположностью первого варианта.

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

Answer 1

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

Мы обрабатываем старые приложения, просто обновляя их до последней версии, когда нам нужно внести изменения в это приложение.

Я создаю SDK и распространяемый установщик для общей библиотеки. SDK предоставляется всем разработчикам и включает в себя исходный код, шаблоны, документацию, помещает библиотеки DLL на свои диски, а также помещает библиотеки DLL в свои GAC. Вторично распространяемый просто помещает библиотеки DLL в GAC. Мы устанавливаем распространяемый на серверах.

Скоро мы перейдем к методу, в котором мы не создаем распространяемый продукт. Мы только создадим SDK, и в этом SDK будет модулем слияния для общей библиотеки. Когда разработчик использует библиотеку и готов перевести свое приложение в производство, он создаст для нее установщик и включит модуль слияния в этот установщик, чтобы при развертывании приложения всегда была правильная версия общей библиотеки, и мы не нужно беспокоиться об установке его на серверах в первую очередь.

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

Answer 2

Одно из важных отличий заключается в том, имеет ли значение, если на двух дочерних проектах на сервере выполняются разные версии «общего» кода. Библиотеки, ты, наверное, в порядке. Общие услуги? Возможно нет. Если последнее, то ветвление становится гораздо более серьезной проблемой, потому что легко всем выйти из синхронизации. Если вы можете позволить себе запускать разные версии одновременно, то я бы выбрал метод ветвления, поскольку он дает каждому проекту / области больше контроля над тем, когда принимать изменения.

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

Это также поможет избежать беспорядка в ваших более крупных решениях.

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