Управление различными версиями программного обеспечения с помощью тегов git в нескольких проектах

Question

Недавно я столкнулся с проблемой, которую не могу решить. Наша компания среди многих других проектов развивает группу, в центре которой находится один - назовем это двигателем. Движок содержит большую часть базы кода с использованием инфраструктуры MVC yii. Есть несколько других проектов, которые используют движок в качестве своей базы. Хотя они могут также содержать уникальный код, они в основном используют или расширяют методы и классы из движка, специально разработанные для спецификаций клиента (в разумной степени). Эти проекты, хотя и похожи, могут содержать уникальные части, которые отличают их друг от друга. Я бы сказал, что каждый проект имеет 30-40% уникальной кодовой базы.

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

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

Мы используем git в качестве нашей системы отслеживания версий, которая должна уметь обрабатывать что-то подобное, по крайней мере, я надеюсь. Наш ведущий программист управляет несколькими проектами с похожей структурой: несколько сайтов работают на одном центральном движке (два движка созданы для двух совершенно разных целей). Он столкнулся с этой же проблемой несколько лет назад и начал использовать теги git для управления более важными выпусками. Сайт некоторых клиентов использует версию движка 1.3, другие - 1.4 и так далее. Несмотря на то, что эта система упрощает и ускоряет отправку обновлений и исправлений ошибок, в долгосрочной перспективе я не думаю, что это удобно. Или это лучшая практика.

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

Мой главный вопрос: как долго мы можем идти в ногу с этим методом? Хотя я понимаю преимущество только добавления нового кода в проект, который нуждается в этом, создание нового выпуска для каждой основной функции кажется чем-то, что может быстро выйти из-под контроля.

Кроме того, как мы должны обрабатывать исправления и обновления существующего кода? Насколько я понимаю, что исправление чего-то на 1.2 не исправляет ошибку на 1.3 и 1.4 - или я ошибаюсь? Или я должен это исправить на 1.4? Могу ли я выбрать способ, позволяющий легко применять определенные изменения к более старым / новым версиям, чтобы мне не приходилось вносить одни и те же изменения несколько раз? Как насчет включения функции, написанной для 1.5 в старых версиях?

Я начал изучать использование исправлений для доставки исправлений в каждую нужную версию, но я не уверен, что это отличная идея.

Или я должен просто сказать "f * ck it" и исправлять ошибки только в последней версии, обновляя проекты один за другим, чтобы они получали исправления, когда мы можем быть уверены, что они ничего не сломают в этой конкретной системе?

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

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

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

Answer 1

Кроме того, как мы должны обрабатывать исправления и обновления существующего кода? Насколько я понимаю, что исправление чего-то на 1.2 не исправляет ошибку на 1.3 и 1.4 - или я ошибаюсь? Или я должен это исправить на 1.4? Могу ли я выбрать способ, позволяющий легко применять определенные изменения к более старым / новым версиям, чтобы мне не приходилось вносить одни и те же изменения несколько раз?

Нет, исправления для одной версии не применяются автоматически ко всем остальным версиям. Я предполагаю, что вы создаете bug-fix Ветка основана на коммите, помеченном как версия 1.2. После нахождения и исправления ошибки вы должны объединить это исправление с версией 1.2 и, в конце концов, отметить версию 1.2.1. В какой-то момент процесса эти коммиты должны быть объединены в другие версии (например, 1.3, 1.4 и т. Д.), Разрешая конфликты по мере необходимости. Затем сделайте релизы для 1.3.1, 1.4.1 и т. Д. С любыми дополнительными исправлениями ошибок, специфичными для этих версий.

Чтобы решить более общую проблему, я считаю, что рассматривать ваш "движок" как отдельный проект с собственным циклом выпуска - разумная стратегия. Каждый из проектов, использующих этот механизм, может указывать версию, которую он использует в системе управления зависимостями проектов (requirements.txt для python, Maven или Ant для Java, пряжа или npm для JavaScript).