Когда над проектом работает несколько разработчиков, то возникают определенные структурные и организационные вопросы. Каждый программист обычно работает с собственным сервером, закачивая обновления в рабочую ветку (branch по терминологии git) проекта (например, develop).
После обновления ветки в репозитории, изменения каким то образом должны попасть на сервер (тестовый сервер), где команда тестировщиков, сможет проверить работу.
Закачка и настройка изменений вручную
Можно сделать это вручную.
Залогиниться на тестовый сервер, скачать и произвести обновления измененных файлов. В случае git, это можно сделать командой:
|
1 2 |
#при условии, что выбрана уже нужная ветка git pull |
Изменения структуры данных, настройки типов публикаций, представлений и т.п. нужно подготовить специальным образом, чтобы эти изменения могли быть перенесены на тестовый сервер. Для Drupal обычно используют модуль features, и пишут код обновления в файлах *.install.
Если изменения базы данных надлежащим образом подготовлены, то их требуется как то выполнить после закачки файлов из репо.
Используя drush, можно выполнить следующий набор команд, находясь в папке с настройками drupal сайта (где то в /sites/<имя проекта>):
|
1 2 3 |
drush updb drush fra -y drush cc all |
Как автоматизировать, реализовать эту логику программно?
По крону можно можно выполнять git pull, если обновлений в репозитории нет, то никаких операций произведено не будет. Но если каждый раз запускать после git pull сброс кешей и реверт фич, то это будут сильно нагружать ваш сервер и мешать работе.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
#!/bin/sh # Для работы как git так и drush вам нужно находиться # в правильном месте. cd /var/www/ваш-сайт/www/sites/каталог-с-настройками-вашего-сайта # Результат git pull мы запишем в файл .build, # но сейчас надо проверить # не создан ли он уже (т.е. не запущено ли обновление). if [ ! -f .build ]; then git pull > .build # Если есть какие то новые файлы, то нужно запустить updb и прочее if [ "`cat .build`" != "Already up-to-date." ]; then drush -y updb drush -y fra drush cc all # Возможно, вы пользуетесь less, сбросим кеш для него отдельно drush cc less fi # файл .build больше не нужен rm .build fi |
Остаётся подключить это скрипт в crontab. Кроме того, чтобы не зависеть от переменных окружения, стоит использовать абсолютные пути для всех вызываемых утилит, т.е:
|
1 2 3 4 |
# вместо rm .build # использовать /usr/bin/rm .build |