Git для веб-сайтов/пост-прием/разделение тестовых и производственных сайтов

Question

Я использую Git для управления исходным кодом и развертыванием моего сайта, и в настоящее время у меня есть тестовые и живые сайты, работающие в одном и том же поле. После этого ресурса http://toroid.org/ams/git-website-howto первоначально, я придумал следующий сценарий после приема крючка дифференцироваться между выталкивает на мой живой сайт и нажимает на мой тестовый сайт:

while read ref 
do 
    #echo "Ref updated:" 
    #echo $ref -- would print something like example at top of file 
    result=`echo $ref | gawk -F' ' '{ print $3 }'` 
    if [ $result != "" ]; then 
    echo "Branch found: " 
    echo $result 
    case $result in 
     refs/heads/master) 
     git --work-tree=c:/temp/BLAH checkout -f master 
     echo "Updated master" 
     ;; 
     refs/heads/testbranch) 
     git --work-tree=c:/temp/BLAH2 checkout -f testbranch 
     echo "Updated testbranch" 
     ;; 
     *) 
     echo "No update known for $result" 
     ;; 
    esac 
    fi 
done 
echo "Post-receive updates complete" 

Однако, у меня есть сомнения, что это на самом деле безопасно:) Я ни в коем случае не специалист Git, но я предполагаю, что Git, вероятно, отслеживает текущий проверенный филиал, и этот подход, вероятно, может смутить его до конца.

Так несколько вопросов:

1. Это безопасно?

2. Будет ли лучший подход состоять в том, чтобы мой базовый репозиторий был хранилищем тестового сайта (с соответствующим рабочим каталогом), а затем изменил этот репозиторий на новый репозиторий реального сайта, который имеет соответствующий рабочий каталог для живого база сайта? Это также позволит мне перенести производство на другой сервер и сохранить целостность цепочки развертывания.

3. Есть ли что-то, что мне не хватает? Есть ли другой, чистый способ разграничения между тестовыми и производственными развертываниями при использовании Git для управления веб-сайтами?

В качестве дополнительной записки в свете ответа Vi, является ли хороший способом сделать это, что будет обрабатывать делеции без отвода с файловой системой много?

Спасибо, -Walt

PS - Сценарий я придумал для нескольких сделок РЕПО (и я использую, если я не лучше слышать) выглядит следующим образом:

sitename=`basename \`pwd\`` 

while read ref 
do 
    #echo "Ref updated:" 
    #echo $ref -- would print something like example at top of file 
    result=`echo $ref | gawk -F' ' '{ print $3 }'` 
    if [ $result != "" ]; then 
    echo "Branch found: " 
    echo $result 
    case $result in 
     refs/heads/master) 
     git checkout -q -f master 
     if [ $? -eq 0 ]; then 
      echo "Test Site checked out properly" 
     else 
      echo "Failed to checkout test site!" 
     fi 
     ;; 
     refs/heads/live-site) 
     git push -q ../Live/$sitename live-site:master 
     if [ $? -eq 0 ]; then 
      echo "Live Site received updates properly" 
     else 
      echo "Failed to push updates to Live Site" 
     fi 
     ;; 
     *) 
     echo "No update known for $result" 
     ;; 
    esac 
    fi 
done 
echo "Post-receive updates complete" 

А потом репо в ../Live/$sitename (это «голые» сделки РЕПО с рабочими деревьями добавлены после инициализации) имеет базовый после приема:

git checkout -f 
if [ $? -eq 0 ]; then 
    echo "Live site `basename \`pwd\`` checked out successfully" 
else 
    echo "Live site failed to checkout" 
fi 

Answer 1

бы лучший подход будет иметь мой база хранилище будет хранилищем полигона (с соответствующим работают каталога), а затем, что хранилища нажимных изменений в новое живое хранилище сайта, который имеет Соответствующий рабочий каталог сайт сайта в реальном времени?Это также позволило бы мне перевести производство на другой сервер и сохранить целую цепочку развертывания .

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

Обычно у меня есть установка виртуальной машины для тестирования. Работает очень хорошо, и я могу иметь его со мной на своем ноутбуке во время путешествия.

Использование git для развертывания вашего веб-сайта - это очень хорошая идея, есть много других людей, которые делают это (например, Rob Conery). Если в любом случае у вас есть живые и тестовые сайты, у вас должны быть отдельные ветви для них в вашем репозитории, настроены как ветви удаленного отслеживания в соответствующих репозиториях сервера. Ваш рабочий процесс становится таким же легким, как и работа в тестовой ветви, толкать его на тестирование, тестировать, сжигать и жить вживую.

Честно говоря, не делайте это слишком тяжело для себя.

Answer 2

Подумайте, что оба способа будут работать.

Вы также можете использовать «git archive master» tar -C c:/temp/BLAH -x »и« live-site git archive »ssh live-site« tar -C/var/www -x ».

Сохранение отдельных репозиториев может быть полезно, но «нажимать другой крючок, связанный с подключением» выглядит сложно, и я ожидаю, что он будет медленным. Сорт длинной цепи, которая будет медленной и хрупкой.

Может быть, обновления в реальном времени должны запускаться вручную после тестирования «тестовой» версии?

Answer 3

Я также следовал тому же руководству на toroid.org, но хотел бы отметить, что, хотя вы начали с открытого репозитория, добавив рабочий каталог, скорее всего, потребуется дополнительная обработка. Я обнаружил, что следующий крючок полезно, если у вас есть содержание, которое может изменять динамически или иным образом и не хотите терять данные при использовании git checkout -f

предварительно получить

#!/bin/sh 
git add -A 
git diff --quiet --cached 
if [ $? -gt 0 ]; then 
    git commit --quiet -m "autocommit" 
    echo "Working Directory was out of sync. Pull to receive updated index." 
    exit 1 
fi 

Это остановит толчок, если являются изменения в удаленном рабочем каталоге. Подумайте об этом, так как кто-то (веб-сервер) вносит изменения, но забывает их совершить. Использование checkout с -f отменяет эти изменения. Этот крюк - хорошее место, чтобы этого не происходило, но было бы неплохо, если бы к выходу был еще крюк, вызываемый на удаленном сервере, чтобы получить эти изменения без проблем.

после приема

#!/bin/sh 
git checkout -f 
echo "Working directory synced." 

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