Обрисую ситуацию:
Есть программный продукт, этот продукт поставляется различным субъектам РФ.
Бывает такое, что один из субъектов, просит внести (убрать) какие-либо фичи которые ему нужны (не нужны), но в то же время, другим субъектам, эти фичи могут быть не нужны или нужны.
В данный момент используем Subversion. Структура такая:
/trunk/ — основной функционал, общий для всех субъектов
/branches/REGION_1/ — версия с фичами для субъекта REGION_1
/branches/REGION_2/ — версия с фичами для субъекта REGION_2
/branches/REGION_N/ — версия с фичами для субъекта REGION_N
и т.д.
Основная сложность в том, что при большом кол-ве субъектов со своими требованиями, возникает необходимость делать мержи туда-сюда, и иногда попросту можно что-то забыть, например не смержить какой-нибудь bugfix. Сложно всё удержать в голове, а revision log разрастаестя до такой величины, что на то, чтобы проверить, а замержил ли я bugfix, уходит время. Также, для каждого субъекта, приходится обновлять отдельную документацию, тоже уходит время.
Посоветуйте, как лучше всё это дело организовать? Нормальная ли структура папок? Есть ли какие-либо утилиты упрощающие ведение проекта?
Контора не очень большая, пока что не готовы тратить денюжку на JIRA и ей подобные системы.
Если есть какие-либо статьи, по Redmine и другим бесплатным системам, буду рад ссылочкам.
p.s. А как организован процесс разработки у Вас? Какие дополнительные утилиты, упрощающие жизнь, используете? Очень интересно услышать ответ.
Мне кажется, что тут более правильный подход — branch by architecture.
Т. е. вы реализуете в проекте IoC и включаете/отключаете нужную функциональность через конкретные конфиги для каждого клиента.
Кодовая база при этом для всех одна.
Рефакторинг может оказаться достаточно дорогим, но, ИМХО, branch hell — это еще дороже, если клиентов много.
Если брать во внимание, что вам нужно именно в виде отдельных веток управлять отдельными фичами (хотя на мой взгляд, лучше что-то с самим продуктом сделать, быть может разделить его на модули), то в голову пришло вот такое простое решение:
* мигрируете с svn на git (я не знаю, есть ли в svn функция, аналогичная rebase в git)
* в нем делаете отдельные ветки, которые все исходят от master-ветки
* затем при доработке или исправлении бага, после его проверки, вы заносите его в master
* во всех ветках для регионов, использующих эту функциональность, делаете rebase относительно ветки master (в этом случае, она возьмет свежую версию кода из master, и уже поверх них наложит ваши новые. В этом случае, багфикс применится ко всем веткам автоматически благодаря rebas. Если нет накладок в коде, конечно же, а иначе — придется помержить ручками).
Решение абсолютно не идеальное, просто ход мыслей, оформленный в виде ответа (:
1) Насчет модульности продукта, спасибо за совет, мне стоит подумать над этим. Просто не подозревал что будет такой наплыв хотелок от заказчиков, архитектуру придется переделывать :)
2) На Git начальство не очень хочет переходить, хотя сам постоянно смотрю в его сторону
Мое мнение, что всю разработку (мастер) нужно вести в одно ветке.
Различие в функциональности поддерживать на уровне конфига ПО или при сборке.
В разных проектах у нас были реализованы оба подхода — какой из них предпочтительней — решайте сами, в качестве критерия мы выбрали следующее:
Если код распространяется с исходным кодом, который жалко отдавать, то используем на уровне сборки ПО «уровне сборки».
Как это работало:
* запускали конфигуратор с подключаемыми модулями, который вычищал из софта «все лишнее»
* потом запускали сборщик
* клиенту передавали, то что осталось
Если исходный код не жалко (или нет боязни, что через конфиг включат что-то лишнее), то проще встроить все в полное ПО. Т.е. распространять максимально полную версию.
Отдельный случай — когда требуется в одних и тех же ситуациях схожее поведение, но со своими особенностями. Для иллюстрации приведу бестолковый пример, но, надеюсь наглядный:
Нам нужно внести информацию об ответственном лице в компании. В варианте А) от нас требуют все размещать в одном поле в произвольном формате, потому что им так удобней, а в вариаанте Б) от нас требуют все разносить по разным полям: ФИО — отдельно, телефон — отдельно, email — отдельно и т.п.
В этом случае было бы неплохо и то и другое реализовать и сделать в кофигураторе переключатель, как описано в ответе выше: Branch By Abstraction — т.е. попытаться абстрагировать некоторое поведение и пользоваться и облегчить себе подключение требуемого модуля.
Простой
Простой
