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

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

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

Спасибо, Уолт

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 ответа

Решение

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

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

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

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

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

Источник

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

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

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

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

Источник

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

Источник
Другие вопросы по тегам