Capistrano: Как развернуть базу данных MySQL для приложения PHP? - PullRequest
2 голосов
/ 09 марта 2011

Я занимаюсь разработкой приложения на основе PHP и использую Capistrano для его развертывания на моем веб-сервере.

До сих пор я не использовал базы данных и, следовательно, развертывание выполнялось нормально.

Однако сейчас я пытаюсь использовать базу данных MySQL и с этим приложением, и мне было интересно, есть ли возможность развертывания базы данных, а также на удаленном сервере с Capistrano - как это делается для баз данных Rails.

С уважением
Нихил Гупта

Ответы [ 3 ]

7 голосов
/ 19 апреля 2011

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

Я несколько раз выступал по этой теме и публиковал свои слайды (в формате HTML) на GitHub: https://github.com/wjgilmore/Automating-Deployments-with-Phing--Capistrano-and-Liquibase

Включает бонусные материалы для развертывания сайтов PHP с использованием Capistrano. : -)

6 голосов
/ 16 марта 2011

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

Вам нужно будет подготовить сценарии для переноса базы данных, поэтому не используйте ихсценарий, каждое изменение базы данных требует нового сценария.Вам также нужно где-то хранить список уже выполненных миграций, для этого rails использует таблицу базы данных, но файл тоже может пригодиться для этого.

Возможно, вы захотите попробовать этот код:

set :mysql_params, "-u user -ppassword"
set :mysql_db_name, "database_name"

after :deploy, :migrate
desc "migrate database on server"
task :migrate do
  run "touch #{shared_path}/migration.list ;
ls -1v #{current_path}/sql/*.sql 2>/dev/null > #{shared_path}/migration.available;
diff #{shared_path}/migration.available #{shared_path}/migration.list | awk \"/^</ {print \\$2}\" | while read f ;
do echo \"migrating $(basename $f)\"; mysql #{mysql_params} #{mysql_db_name} < $f && echo $f >> #{shared_path}/migration.list ; done;
rm -f #{shared_path}/migration.available"
end

after "deploy:setup", :create_db
desc "create database on server"
task :create_db do
  run "mysql #{mysql_params} -e \"CREATE DATABASE #{mysql_db_name}\""
end

и, что наиболее важно для сохранения порядка миграций, вы должны называть ваши миграции последовательными числами или date_time, поэтому пример вывода ls -1v #{current_path}/migrations/*.sql будет выглядеть следующим образом:

0001_create_database.sql
0002_create_user_table.sql
0003_add_password_to_users.sql
20101205_141534_add_admin_user.sql
20110108_090712_create_post_table.sql
20110210_165609_create_comment_table.sql

записи date_time используют формат YYYYmmdd_hhMMss_title.SQL

0 голосов
/ 15 мая 2014

Насколько мне известно, существует 3 полностью автоматических подхода к развертыванию базы данных на рабочем сервере.

  • Используйте liquibase , записывайте (или генерируйте ) наборы изменений, которые содержат ваш код миграции.
  • Использовать источник событий с реляционным кэшем чтения, имеющим ту же структуру, что и обычно. Отправьте дамп схемы со своими выпусками. Очистить весь кэш чтения, включая таблицы. Создайте заново таблицы, используя дамп. Повторно вставьте данные в одну транзакцию, используя хранилище событий и прогнозы. Откат не так сложен, вы можете сбросить старый кеш чтения или выполнить те же действия со старым выпуском.
  • Напишите свой собственный скрипт миграции и sql для каждого выпуска. Не рекомендуется, так как подвержен ошибкам.
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...