Я понимаю, что это очень специфический вопрос, и некоторые вещи могут даже вздрогнуть закаленного пользователя git, но потерпите меня…
Мы реализуем виртуальное хранилище данных, которое генерирует метаданные (SQL-как код).Продукт ( Denodo ) может быть подключен к VCS (например, git) для сохранения изменений под контролем версий.
Внутренне существует виртуальных баз данных , и Denodo также организуетего код в папки, соответствующие этим базам данных.Таким образом, в git вы получите что-то вроде:
Root
\- Orders
\- Customers
\- Invoices
Под каждой из этих папок базы данных будет несколько файлов кода, составляющих метаданные.
Передача и отправкакод в Denodo всегда выполняется на уровне базы данных , хотя в git-репо такого различия нет и фиксация является глобальной для репо.
Разработчики работают локально над своими отдельными базами данных и будутпериодически совершать изменения кода.Все эти изменения перенесены на сервер разработки.Пока все хорошо.
Рано или поздно, изменения, внесенные в разработку, должны найти свой путь в QA и производство.Однако, если бы мы слили текущий статус из нашей ветви разработки (develop) в нашу ветвь QA (release), мы могли бы получить некоторые нежелательные (ломающиеся) изменения, которые еще не были готовы к прайм-тайм.
Таким образом, нам нужно вишня .И используя git log, мы можем видеть, какие коммиты еще предстоит повысить до QA.Но если мы выберем отдельные коммиты из ветви develop в ветку release, они получат новый SHA, и в следующий раз, когда мы сделаем сравнение git log, ранее выбранные коммиты все равно будутПоявляются
Также помните, что хранилище организовано по базе данных.Это также означает, что:
- Я получаю отчет о коммитах, сделанных в каждой папке, связанной с базой данных
- Решите, какой последний коммит для каждой базы данных будет повышен
- Для каждогобаза данных: вишня выбрать самый старый коммит с момента последнего слияния до выбранного на предыдущем шаге.
Этот диапазон не обязательно является последовательным.У вас может быть что-то вроде этого (упорядочено по дате).
| To be promoted | Commit | Database | Change |
|----------------|--------|-----------|---------------------|
| | da39a3 | Orders | Created views |
| X | ee5e6b | Customers | Bug fix |
| X | 4b0d32 | Invoices | Removed data source |
| | 053e2d | Invoices | Updated credentials |
| X | 956018 | Orders | Created data source |
В этом примере мы бы выбрали коммиты ee5e6b (клиенты), 4b0d32 & 053e2d (счета) и956018 (заказы).Причина, по которой я должен выбрать 053e2d также для заказов, заключается в том, что последние метаданные могут основываться на ранее внесенных изменениях (из-за зависимостей внутри базы данных).Между базами данных практически отсутствуют зависимости.
Требования:
Каждый раз, когда запланировано повышение, я должен иметь возможность представитьобзор коммитов, которые находятся в разработке, но не в QA.
Я должен иметь возможность выбирать определенные (вплоть до) изменения на уровне базы данных, которые можно объединить с release ветка для продвижения в QA.
Ограничения:
Коммиты происходят изнутри Denodo и поддержка VCS не поддерживается.не все так здорово (например, смена веток на самом деле не поддерживается).Это также означает, что мы не можем реализовать ветки feature , чтобы изолировать критические изменения или долгосрочное развитие.
Пока мы оцениваем, что продвигать на уровне базы данныхэти коммиты не последовательные.
Приношу свои извинения за затянувшийся вопрос, но это не совсем типичный сценарий и ему нужно немного больше контекста.Я также не специалист по мерзавцам (не слишком далеко), поэтому, пожалуйста, никаких вил или факелов.Спасибо!