Git для веб-сайтов / пост-получение / разделение тестовых и производственных сайтов - PullRequest
5 голосов
/ 02 февраля 2010

Я использую 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 для управления веб-сайтами?

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

Спасибо, -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 (это «голые» репозитории с рабочими деревьями, добавленными после init) имеет базовый пост-приём:

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

Ответы [ 3 ]

2 голосов
/ 05 февраля 2010

Думаю, что оба способа будут работать.

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

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

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

1 голос
/ 10 апреля 2010

Я также следовал тому же руководству на 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

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

после приема

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

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

1 голос
/ 14 февраля 2010

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

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

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

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

Честно, не усложняй себе жизнь.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...