Есть ли лучшие практики использования миграции Doctrine 2 в разных ветвях GIT?

Question

Есть ли лучшие практики использования миграции Doctrine 2 в разных ветвях GIT?

Я работаю над проектом Zend Framework 2 с зависимостью Doctrine 2. Управление версиями исходного кода осуществляется GIT. Мы используем GitFlow в качестве модели ветвления.

Проблемная ситуация:

Migrations on Develop branch:
001.php
002.php
003.php
004.php

Migrations on Production branch:
001.php
002.php

Допустим, мне нужно пропатчить, и я создаю миграцию 003.php в ветке Production. Я также должен выбрать вариант 003.php для ветки Develop, чтобы конечный результат выглядел так:

Migrations on Develop branch:
001.php
002.php
*003.php*
003.php
004.php

Migrations on Production branch:
001.php
002.php
*003.php*

Но здесь есть проблема. Если текущая миграция в базе данных Develop была 004 и добавлена 003, она не будет выполнена.

Каков наилучший способ справиться с миграцией Doctrine 2?

3

database-versioning doctrine-orm php zend-framework2

Решение

Другие решения

Я также работаю над проектом, использующим ZF2, Doctrine 2 и Migrations, а также Gitflow в качестве модели ветвления. Итак, у нас одна и та же проблема с миграциями, расположенными в разных филиалах. Когда возникает эта проблема, я обрабатываю ее вручную, используя инструмент миграции доктрины для синхронизации версий миграции:

$php public/index.php migrations:version 20150417121714 --add
$php public/index.php migrations:version 20150417202439 --remove

А потом:

$php public/index.php migrations:execute 20150417121714

Это решение требует некоторой ручной работы, но, к сожалению, у меня пока нет лучшего.

1

Источник

Accepted Answer

Я написал скрипт автоматизировать процесс переноса всех расходящихся миграций в текущую ветвь и обратно в новую ветвь, которую вы проверяете.

Приведенная выше ссылка предназначена для Symfony, но здесь она модифицирована для ZF2 (не проверено, поскольку я не использую ZF2):

doctrine-checkout.sh

#!/bin/bash

# Commit ref of current HEAD
start_commit="$(git rev-parse HEAD)"
# Commit ref of what is to be checked out
dest_commit="$1"
# First common ancestor commit between the two branches
ancestor="$(git merge-base HEAD "$dest_commit")"
# Shorthand for `sudo -u nginx /home/user/project/public/index.php`
# Modify this if you don't run `php public/index.php` as `nginx`
appconsole="sudo -u nginx php $(git rev-parse --show-toplevel)/public/index.php"
# Checkout the ancestor commit to find the first common migration between the
# two branches.  Migrate backwards to this version.
git checkout "$ancestor"ancestor_migration="$($appconsole migrations:latest)"git checkout "$start_commit"$appconsole migrations:migrate "$ancestor_migration"
# Checkout the destination branch and migrate back up

git checkout "$dest_commit"$appconsole migrations:migrate

Чтобы использовать это, когда вам нужно переключаться между ветвями функций, а не запускать git checkout another-branch, делать doctrine-checkout.sh another-branch,

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

0