Я использую Мерзавца, чтобы управлять исходным кодом и развертыванием моего веб-сайта, и в настоящее время иметь тест и живые сайты, работающие на том же поле. После этого ресурса 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"
Однако у меня есть сомнения, что это на самом деле безопасно :) Я ни в коем случае не эксперт Мерзавца, но я предполагаю, что Мерзавец, вероятно, отслеживает ток, проверенный глава филиала, и этот подход, вероятно, имеет потенциал, чтобы перепутать его ни к какому концу.
Так несколько вопросов:
Действительно ли это безопасно?
Лучшее приблизилось бы, чтобы должным быть иметь мой основной репозиторий быть репозиторием испытательной площадки (с соответствующим рабочим каталогом) и затем иметь то нажатие репозитория изменения в новом живом репозитории сайта, который имеет соответствующий рабочий каталог на живую базу в сайте? Это также позволило бы мне перемещать производство в другой сервер и сохранять цепочку развертывания в целости.
Есть ли что-то, что я пропускаю? Существует ли другой, очевидный способ для дифференциации между тестом и производственными развертываниями при использовании Мерзавца для руководящих веб-сайтов?
Как дополнительное примечание в свете ответа Vi, существует ли хороший способ сделать это, которое обработало бы удаления, не унавоживая с файловой системой очень?
Спасибо, - Walt
PS - Сценарий я придумал для нескольких repos (и использую, если я не слышу лучше), следующие:
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"
И затем repo в../Live/$sitename (это "пустой" repos с рабочими деревьями, добавленными после init) имеет основное, постполучите:
git checkout -f
if [ $? -eq 0 ]; then
echo "Live site `basename \`pwd\`` checked out successfully"
else
echo "Live site failed to checkout"
fi
Будет ли лучшим подходом, если мой базовым репозиторием будет репозиторий тестового сайта репозиторий (с соответствующей рабочей директорией), а затем этот хранилище переносит изменения в новое хранилище живого сайта репозиторий сайта, который имеет соответствующий рабочий каталог базе живого сайта? Это также позволит мне перенести производство на другой сервер и сохранить цепочку развертывания нетронутой.
Да, безусловно. Это очень редкий случай, когда вы хотите разместить свой тестовый сайт рядом с рабочим. Это опасно и непрофессионально почти во всех отношениях, не говоря уже о повреждении базы данных, блокировке веб-сервера и т.д.
Для тестирования я обычно использую виртуальную машину. Работает очень хорошо, и я могу брать ее с собой на ноутбуке во время путешествий.
Использование git для развертывания вашего сайта - очень хорошая идея, многие люди так и делают (например, Роб Конери). Если у вас все равно есть живой и тестовый сайт, вы должны иметь отдельные ветки для них в вашем репозитории, установленные как ветки удаленного отслеживания на соответствующих серверных репозиториях. Ваш рабочий процесс становится таким же простым, как выполнение работы в тестовой ветке, перенос ее в тестовую, тестирование, слияние в живую и перенос в живую.
Честно говоря, не усложняйте себе задачу.
Думаю, что оба способа будут работать .
Вы также можете использовать «git archive master | tar -C c: / temp / BLAH -x» и «git archive live-site | ssh live-site 'tar -C / var / www -x'».
Хранение отдельных репозиториев может быть полезно, но «протолкнуть внутрь другого крючка, связанного с push», кажется сложным, и я ожидаю, что это будет медленным. Такая длинная цепочка, которая будет медленной и хрупкой.
Может быть, обновления на сайте должны запускаться вручную после тестирования «тестовой» версии?
Я тоже следовал тому же руководству на toroid.org, но хотел бы отметить, что, хотя вы начали с чистого репозитория, добавив рабочий каталог , скорее всего, потребуется дополнительная обработка. Я обнаружил, что следующая ловушка полезна, если у вас есть контент, который может изменяться динамически или иным образом, и вы не хотите терять данные при использовании git checkout -f
pre-receive
#!/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
отменит эти изменения. Этот хук - хорошее место, чтобы этого не произошло, но было бы неплохо, если бы на удаленном сервере был также хук, вызываемый до извлечения, чтобы вы могли беспрепятственно получать эти изменения.
post-receive
#!/bin/sh
git checkout -f
echo "Working directory synced."
Что касается двух веток, я подумал, что ваше первое решение было более элегантным, чем необходимость иметь дело с несколькими репозиториями. Если вы действительно хотите изолировать свой производственный сайт, вы можете использовать локально rsync, который имеет аналогичное дельта-исправление. У меня была бы тестовая и стабильная ветка в репозитории с только тестовым сайтом в качестве рабочего каталога. Когда все будет готово к выпуску, объедините тестирование в стабильную ветку, нажмите и получите ловушку, ищущую коммиты в стабильную ветку, и вызовите rsync.