Comments 16
git rebase — это плохо. Теряется контекст разработки, затрудняется работа git bisect и т. п.
Поэтому в этой схеме есть некоторые ограничения: 1) при ребейзе нельзя входить в интерактивный режим и вручную править коммиты (ребейз используется только для изменения основы ветки); 2) обновлением основных веток занимается один человек — мейнтейнер проекта (члены команды работают только с dev веткой).
Таким образом использование rebase в этой схеме безопасно.
2. Поскольку отличий с точки зрения процесса принятия изменений, в одну из основных веток, между bugfix и hotfix ветками нет (тесты запускаются одни и те же, правила мержа те же), то также нет смысла именовать ветки по разному (в зависимости от того куда они будут сливаться).
3. Непонятно как называть фикс-ветки (bugfix или hotfix), если они создаются для beta ветки (она же также релизится).
2. Смысл имеется. Как раз для того, чтобы было ясно куда фикс будет вливаться, хотя бы чтобы реджектить мерж/пулл-реквесты, отправленные не по адресу.
3. hot подразумевает правку по живому, без прохождения полного цикла тестирования и приёмки, так что годится только для прода.
Я спрашиваю, потому что у себя вижу необходимость в запуске тестового (бета) окружения. Как его лучше организовать, чтобы с одной стороны протестировать приложение в более или менее реальном окружении, с другой чтобы не отправить реальным пользователям оповещалку с бета стенда, для меня пока загадка…
Если beta БД использовалась бы только для чтения или не синхронизировалась бы с продовской, ваше предложение подошло бы.
Основная проблема заключается в том, что бета БД и прод БД должны содержать одни и те же данные, в любой момент времени. Но поскольку у них разные схемы возникает проблема синхронизации.
Предположительно оба стенда должны писать одновременно в обе базы данных, но здесь есть ряд проблем:
Если бета стенд знает об отличиях своей БД от продоской и может их учитывать, то продовский стенд об этих отличиях ничего не знает и не может писать в бета БД.
Делать транзации становится сложно, поскольку помимо того, что под каждую БД будут создаваться транзакция, также будет создаваться и одна общая транзакция, на случай проблем при внесении данных в одну из БД.
- Поскольку обе БД являются master (обеспечивают read-write доступ) в случае выхода из строя какой-то из них возможны потери данных.
Возможно есть и другие проблемы.
— деплоим промежуточную схему БД для новой фичи
— деплоим промежуточный код на бету
— деплоим промежуточный код на прод
— деплоим конечный код на бету
— деплоим конечный код на прод
— деплоим конечную схему БД
Естественно, после каждого деплоя всё тестим и откатываемся если что не так.
Не уверен, что правильно понял проблему. Бета стенд — это полноценный прод только следующей версии для предоставления раннего доступа к новому функционалу "контрольной" группе пользователей. С него должны уходить сообщения пользователям как с прода. Если нужно протестировать приложение в более-менее реальном окружении нужно использовать dev стенд, предварительно среплецировав данные с прода, как VolCh предлагает делать.
Я правильно понимаю, что при изменениях в ветках справа, у вас ребейзится ветка dev, с которой активно работают разработчики?
Как вы решаете вопрос конфликтов с локальными копиями на машинах разрабов?
Да, при изменении веток справа, мейнтейнер проекта последовательно ребейзит ветки слева до dev. Далее каждый разработчик обновляет (ребейзит) свои feature ветки от dev.
Графически можно представить это следующим образом.
Что делает разраб при изменении dev:
- Стягивает изменения:
git fetch origin - Переходит в feature-ветку:
git checkout feature - Ребейзит
featureветку отdev:git rebase origin/feature
Если возникают конфликты он правит только свои коммиты. Т.е. конфликтов не связанных с его фичей здесь быть не может — их все разрешил мейнтейнер, когда ребейзил основные ветки.
Как подружить этапы разработки с gitflow