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

Эти посты кажутся связанными, но мой мозг начинает таять, пытаясь обдумать это: P

Мой работодатель только начал использовать систему контроля версий, прежде всего потому, что до того, как они наняли больше разработчиков, «хранилище» было жестким диском одинокого разработчика, который работает в основном из дома. Весь написанный им код .NET был проверен в массовом порядке , и в нем много дублированных функций (читай: скопированный). Прямо сейчас наша система SCM является прославленной резервной копией.

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

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

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

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

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

И как бы мне ни хотелось использовать Mercurial, мы уже потратили деньги на централизованный коммерческий SCM (Vault), и переключение не вариант. Кроме того, я думаю, что проблема здесь гораздо глубже, чем выбор инструмента контроля версий.

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

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

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

Библиотеки должны рассматриваться как отдельные проекты и стабилизироваться как можно скорее. Как только они стабилизируются (особенно интерфейсы), должно быть легче интегрировать изменения с другими проектами. Новые библиотеки должны работать со старым кодом. Помечайте стабильные выпуски библиотеки своим собственным идентификатором выпуска. Попробуйте относиться к библиотекам так же, как к сторонним библиотекам.

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

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

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

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

Некоторые преимущества:

1. Более простая отладка каждого модуля.
2. Более быстрые циклы сборки (без перестроения библиотек, которые не изменились)
3. Как только что-то сработает, вы с меньшей вероятностью сломаете его, изменив другую область за пределами этого модуля (не на 100%, но вы уменьшите шансы).
4. Проще разбить рабочие задания, если это не большой взаимозависимый беспорядок.
5. Более быстрое распространение небольших частей, когда вы исправляете одну библиотеку (большая причина, почему у вас есть файлы .dll / .so).

У меня есть один вопрос по этой части:

«Идеальное решение в моем навязчивом уме - это создавать библиотеки отдельно, при этом каждый зависимый проект строится на основе специально выбранных, совместимых их версий».

Вы статически связываете весь проект? Если это так, это приведет к: 6. Сокращению ненужного раздувания кода.

Некоторые негативы:

1. Если проект небольшой, то вы просто добавляете сложность туда, где она не нужна.
2. Разветвление большого количества модулей может превратиться в проблему обслуживания для действительно больших проектов. Я не знаю "Убежище", поэтому я не уверен, хорошие ли у них операции ветвления.

Прямо сейчас, похоже, у вас одна кодовая база встроена сразу в одну цель. У вас, вероятно, не более пяти разработчиков. На самом деле я не вижу смысла разделять библиотеки слишком сильно. Вы изменили бы свой рабочий процесс из кода -> компилировать -> запустить в код -> компилировать -> скопировать DLL -> компилировать -> запустить ... ick.

Некоторые компании (Google и Amazon) имеют достаточную инфраструктуру для разработки, поэтому довольно просто создать множество отдельных библиотек. Инфраструктура, позволяющая сделать его безболезненным, включает в себя способ указания версий библиотек, которые существуют в вашей SCM (которые у вас, вероятно, есть), способ указания версий зависимостей, которые существуют в вашей SCM, сервер сборки, который может это понять и правильно скомпилировать и способ получить соответствующие артефакты сборки с вашего сервера сборки и из вашей локальной рабочей области. Я сомневаюсь, что у вас есть это.

Без этой инфраструктуры я бы отделил проект, если применимо одно из следующих:

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

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

То, что вы можете и должны делать сейчас, - это настроить сервер сборки для надежных, повторяемых сборок и убедиться, что вы можете найти исходную версию из данного исполняемого файла. Вы, кажется, используете .NET; довольно просто настроить CruiseControl.NET для вставки строки версии, включая номер редакции.

Если у вас есть сервер сборки, разделение библиотеки будет в значительной степени делом перемещения его в Vault, добавления другой цели в CC.NET, копирования полученной библиотеки DLL в папку библиотеки вашего основного проекта и фиксации ее. Проще на стороне SCM, чем повседневная разработка.

У Mercurial есть функция, которая называется subrepositories. Я недавно прочитал этот блог от Kiln, объясняющий, как они работают.

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

Может быть, Vault имеет аналогичную функцию.

Мы добавили файл метаданных к каждому модулю в SC, который указывает имя всех других модулей, от которых он зависит. Продукт будет иметь второй файл метаданных, указывающий, какая версия каждого зависимого модуля требуется для продукта. Кроме того, это инструмент для анализа файлов метаданных, проверки всех необходимых модулей и создания проекта для нашей IDE.

Это гарантирует, что наши сборки всегда воспроизводимы, и что правильные заголовочные файлы всегда совместно используются компонентами. Другая сложность может быть распределена по мере необходимости. У нас есть инструменты, которые теперь могут генерировать отчеты о различиях между любыми двумя сборками продукта, указав измененные исходные файлы, комментарии о проверке, комментарии о версии, авторов по всем независимым модулям в SC. Мы получаем феноменальное повторное использование количества из нашей базы кода.