Githubizer: автодеплой с Гитхаба на сервер

[hakimovis]

Или проще — ssh server.hostname /srv/deployscript.sh

[Chvanikoff]

А как же пункт «написать deployscript.sh, который умеет все вышеперечисленное»? =)

[hakimovis]

Так там простой git pull. По сути, должно быть два скрипта:
на локальной машине что-то вроде

#!/bin/sh
echo "--- Indexing changes"
git add -A
echo "--- Making commit"
git commit -m'deploy $1'
echo "--- Pushing to master"
git push origin master
echo "--- Executing remote pull"
ssh server.hostname /srv/deployscript.sh

И на сервере примерно так:

#!/bin/bash

cd /srv/project_path
git pull

Само собой, если надо раскатывать по серверу конфиги nginx или выполнять миграции, таким велосипедом не обойтись.

[Chvanikoff]

А также
— Создать ssh-ключ для сервера
— Добавить его на сервере
— Поправить ~/.ssh/config, если хочется использовать не стандартный id_rsa
— Вводить при каждом пуше команду запуска скрипта (ключевой, пожалуй, момент)

Понятно, что это все мелочи, но именно эта рутина и заставила меня написать Гитхабайзер (ну и желание попрактиковаться с Эрлангом, да). Так-то можно и вообще обойтись

$> git push
$> ssh -f server 'cd /path/to/app && git pull'

[hakimovis]

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

[maxp]

Скажите, уважаемые, а кто-нибудь пользуется таким способом?

git push prod-server -f
ssh prod-server 'git reset --hard'

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

[ainu]

Весьма интересно.
А если на push сервера поставить хук для git reset?

[maxp]

Я это выдумывал с точки зрения минимальных модификаций сервера, собственно, там только надо вписать ignore в [receive]. чтобы push -f не ругался на currentBranch. Подразумевается, что всякие ssh ключи туда уже настроены. Идея в том, чтобы не размазывать всякие неявные зависимости по хукам, а иметь всю последовательность в одном скрипте.

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

[ainu]

Зачем ssh ключи? Мы же прямо на prod пушим.

[maxp]

Чтобы аутентифицироваться.
Можно и логин-пароль вводить, конечно, но это лениво каждый раз.

[youlose]

а почему не hook'ом post-receive с

git checkout -f

внутри?

[Nailgun]

У меня небольшой скриптик на node.js следит за файлом в директории /tmp. Если кто-то сделает на файле touch, скрипт делает git pull и перезапускает приложение. Картину дополняет CI Jenkins, который после удачного прогона всех тестов делает touch. Таким образом на девелоперском серваке всегда крутится свежая и рабочая версия приложения, можно тестить ручками.

[grossws]

Использую для таких целей capistrano.
Возможности большие: разные стратегии деплоя (например скопировать директорию проекта с локальной машины, вытянуть сервером определенную ветку репозитория), хранит нужную глубину версий для отката изменений, умеет использовать gateway для подключения к серверу.
Деплою так java-приложения, статику и рельсы. В случае последних возможностей ещё больше (e. g. zero-downtime deploy при использовании unicorn или rainbow).

У пайтонистов, вроде было что-то аналогичное capistrano.

И можно, конечно, предложить SCM (chef, puppet, cfengine, bcfg2), которые ещё более гибкие, чем просто тулзы для деплоя.

[svoloshyn]

Есть еще хороший и бесплатный сервис
https://deploybutton.com/.