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