Как организовать синхронизацию сайта с bare-репозиторием на сервере?

Question

[246]

Здравствуйте.

Установил gitolite на сервер (под пользователем git). В "/home/git/repositories/site.com.git" лежит bare-репозиторий сайта с ветками "master" и "test". Также есть папка "site.com", где лежит сайт, и папка "test.site.com", где лежит тестовая версия сайта, владелец - user.
Теперь проблема: как правильно сихронизировать файлы сайта и его тестовой версии с репозиторием?
Создать в папках с сайтом и тестовой версией по репозиторию, и написать хук, который при пуше в в ветку master bare-репозитория пушит в папку с сайтом, а при пуше в ветку test пушит в папку с тестовой версией?
Или есть более умные и проверенные временем способы?

Answer 1

[Андрей]

Только не пушит, а переходит в нужный каталог и делает оттуда pull.

Например так:

branch=$(git rev-parse --symbolic --abbrev-ref $1)
if [ $(git rev-parse --is-bare-repository) = true ]
then
    rep=$(basename "$PWD"|sed 's/.git//')
else
    rep=$(basename $(readlink -nf "$PWD"/..|sed 's/.git//'))
fi

/home/scripts/git/post-update.sh $rep $branch

И в post-update.sh например так:

#!/bin/sh
DATADIR=/var/www/$1/$2
REPO=$1
BRANCH=$2

if [ ! -d $DATADIR ]
then
    mkdir -p $DATADIR
    git clone [e-mail]:$REPO $DATADIR
    cd $DATADIR
    git checkout $BRANCH
else
    cd $DATADIR
    /usr/bin/git config user.email "deploy@local"
    /usr/bin/git config user.name "Deploy Robot"
    /usr/bin/git fetch origin
    /usr/bin/git reset --hard origin/$BRANCH
    /usr/bin/git stash
    /usr/bin/git checkout
    /usr/bin/git pull    
fi

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

Comments

[246]

Спасибо, попробую разобраться с Вашим вариантом. Вопрос только с правами возник: нормально ли, что пользователь git будет иметь доступ на директорию с самим сайтом и, соответственно, создавать там свои файлы? С одной стороны, вроде и ничего страшного, но с другой как-то это не совсем правильно кажется. Или как в таком случае поступают?

[Андрей]

Ну, пользователю git в любом случае надо куда-то выгрузить файлы. В bare репозитории их, как известно, нету. Приведенные скрипты мы используем на тестовом сервере, и сайты, куда всё это выгружается, не рабочие. А на рабочие сайты (на другие сервера вообще говоря) мы деплоим при помощи rsync (например, если пуш прошел в ветку release, то вызывается после обновления рабочего репозитория еще и rsync, который сгружает нужные файлы уже в рабочий каталог). Чтобы кто попало не мог пушить в release, имеет смысл поставить gitolite например. Секьюрность на уровне ssh, не вижу проблемы в том, что таким образом меняются файлы в рабочем каталоге сайта.

[Ubran_Hera]

246, делают no-login user'а с оболочкой gitlab-shell

Answer 2

[_ _]

Проще всего это сделать через веб-запрос.
Напишите хуки, которые будут дергать url по заданному адресу, в самом сайте сделайте обработку этого запроса, чтобы делал git pull.
У вас ситуация, конечно, попроще - репозиторий и деплой на одной машине, но этот способ наиболее универсальный.
Да и на будущее пригодится, если будете делать автодеплой с битбакета, например. Там вам вручную хуки писать не дадут, зато у них есть готовый хук c http-запросом.

Answer 3

[Алексей Киселев]

Универсальным решением будет использование сервера непрерывной интегации (Continuous Integration), например Jenkins.
Сделайте на нем 2 задания, одно для ветки master, второе для вертки test. В этих заданиях в ответ на появление коммитов в ветке сделайте публикацию на сайт по SSH, FTP или простым копированием.
Преимуществом подхода является то, что вся информация о deployment сосредоточена в одном месте - заданиях Jenkins, для разных проектов можно по разному организовать выкладку файлов на сервер, но принципиально задания будут одинаковыми.
Если пойти дальше, то в этих же заданиям можно запускать автоматическое тестирование.

Comments

[Андрей]

Бывает так, что это слишком тяжеловесное решение. Вполне можно обойтись баш-скриптами, особенно если тестов никто не пишет.

[Алексей Киселев]

Зависит от кол-ва проектов, если их не один-два, то выделенный сервер уже оправдан. Если одни-два и не предвидится расширения, согласен с тем, что скрипты лучше и быстрее.

[Ubran_Hera]

если capistrano тяжеловат, то ansible