[Git] Как организовывать обновления кода и структуры SQL

Запускать можно через хуки, только вот как-то надо проверять, чтоб скрипт конвертации не запустился два раза. Неужели формат базы данных будет менятся так часто, что руками лень?

С пунктом 2 что делать - не знаю

google://миграции.

Казалось бы, причем тут гит...

>С пунктом 1 планирую поступить так. На этом же сервере поднять Git-сервер. Коммитить в него все изменения. Когда нужно будет обновить ПО на сервере, зайти на сервер через SSH и обновиться с этого localhost-репозитария. Как вам такое решение?

Нормально, хотя, в принципе, по фигу - где разворачивать сервер гита.

С пунктом 2 что делать - не знаю. Нужно наверно писать какой-то конвертор структуры, который будет отслеживать какая версия структуры в данный момент, и какую надо получить, запуская соответсвующую функцию преобразования. Запускать данный конвертор перед обновлением ПО. Так это делается?

Пишешь апгрейд-скрипт, включешь его в скрипт деплоя, в чём сложность то?

в схеме базы данных где-то желательно иметь текующую версию и историю изменений

2. LiquiBase

Как вам такое решение?

Глупое решение. Деплой можно сильно проще сделать, нежели через поднятие VCS.

Давно пробовал, тогда это было УГ с SQL внутри XML.

> Деплой можно сильно проще сделать, нежели через поднятие VCS.

Как?

rsync, например.

Насколько давно? Никакого sql незаметно. Я пытался у нас ввести, но шефиня твердолобая отказала по какой-то смехотворной причине.

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

Есть еще dbmigrate и autobase, но я их не трогал.

пункт 2 - я веду файл alter.sql.lisp примерно вот с такими командами:
(def-firebird-patch myfirm.2011-10-10
(alter-table 'foo :columns '(bar)))

(def-firebird-patch myfirm.2011-10-11
(fcm create user luser;
))

и т.п.

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

Def-firebird-patch заносит в спец.таблицу, находящуюся в базе, сведения об успешном применении патча. Можно было написать что-нибудь более «точное», например, проверять, что все предыдущие файлы уже выполнены, а следующие - ещё нет.
Всё это делается без большого труда на любом ЯП, например так это могло бы выглядеть на Pascal (я не знаю PHP, но наверняка можно и на php)

unit database_patches;

...

procedure patch_2011_10_11;
begin
check_last_patch('patch_2011_10_10');
begin_patch('patch_2011_10_11');
runSQL('alter table foo add bar int');
end_patch('patch_2011_10_11');
end;

procedure check_db_version;
begin
check_last_patch('patch_2011_10_11'); // меняется при эволюции БД
end;

виедл его пару месяцев назадю имо ничего не изменилось

в одном из предыдущих проектов юзали похожую «схему». достаточно просто и надежно

Есть сервер с установленным приложением на PHP/Ruby/Java/C
На этом же сервере поднять Git-сервер

говорят мухи должны быть отдельно от котлет. есть же github/bitbucket для сырцов

> Когда нужно будет обновить ПО на сервере, зайти на сервер через SSH и обновиться с этого localhost-репозитария. Как вам такое решение?

зачем? сразу пушишь в продакшн, там стоит хук, который все разворачивает сам.

baverman

rsync, например.

Как решать вопрос с ревизиями? Как откатить код в случае необходимости? Бэкапы?

ТC хочет деплой. Каким боком здесь VCS?