project deploy (разворачивание проекта)

Question

[g00d]

Ищется оптимальное и наиболеe безгеморройное решение для след. задачи:

— хочется иметь «легкий» (особенно по трафику) способ деплоя приложения на продакшен, с такой же легкой возможности «переключения» (откатки) на рабочие версии.

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

в качестве СКВ используется ГИТ.

На дев сервере две ветки мастер и дев.
От последней делаются клоны(пулы) в нее же попадают все пушы.
По хуку все ее содержимое копируется в ввв_рут виртуальноого хоста.

после тестов и фиксов, все мерджится в мастер и опять таки деплоиться на локальный вирт. хост для финального тестирования.

Как только все готово хочется все закинуть на продакшен.

— хочется НЕ заливать все дерево целиком каждый раз (проект большой)
— и хочется иметь возможность в случае внезапно найденно баги быстро и легко откатиться на шаг или более назад.

Делать так как делалось с СВНом (через svn up) видится не совсем идеологически верно.

есть идеи?

P.S. ранее все работало через СВН и по этому на продакшене есть папочки .svn (закрытые через шттп), хочется найти способ что б перейдя на него, не вспоминать о старых временах :)

Comments

[plr]

Перед нами стоят те же задачи. Уточни пожалуйста, как вы поступаете с БД, т е с изменением ее структуры и данных между версиями. В частности, протоколирование измений в структуре, статических данных и их версионность? Автоматизация процесса отката версии кода и версий структуры БД? Как все делать вручную — понятно, интересует разумная автоматизация процессов, может быть где-то даже на уровне человека.

Answer 1

[klen]

Ну так, что вам мешает развернуть на продакшен тот же Git репозиторий и получать в него только изменения?

Comments

[g00d]

на сколько это разумно поступать так же как и было с СВНом?
вопрос только в этом.

возможно есть другие более идеологически правильные пути?

[klen]

Git в отличии от SVN не создает свои служебные директории в каждой папке репозитория. Обычно .git находится вне веб-пространства. Это гораздо безопаснее.

[g00d]

проблема не в защите папки .git от доступа (которая ОБЫЧНО находится там где ее сделает git ini | clone etc).

Вопрос совершенно в другом.

[klen]

Значит вопрос сформулирован очень не четко. Вы пишете:

— хочется НЕ заливать все дерево целиком каждый раз (проект большой)
— и хочется иметь возможность в случае внезапно найденно баги быстро и легко откатиться на шаг или более назад.

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

[g00d]

я же и спрашиваю есть ли у этого способа недостатки? кроме идеологических? в случае когда гит на продакшене.

[gro]

А какие идеологические недостатки вы видите?

Answer 2

[Андрей Янцен]

Рекомендую Capistrano (http://habrahabr.ru/tag/capistrano/):
— мы используем вместе с модулем multistage, он позволяет разворачивать код на несколько stage-серверов (по команде «cap demo deploy» выкладывается ветка testing на демо-сервер, «cap production deploy» — ветка master на боевой)
— позволяет делать cached-copy: при первом развёртывании создаётся папка с клоном репозитория, при последующих — в ней делается git pull. Далее эта папка тупо копируется в целевую вместе с .git (у нас www-root находится не в корне проекта, а в одной из вложенных папок — так что паранойя нас сильно не мучает)
— deploy:rollback — откат к предыдущему деплою
— возможно задавать всякие разные задачи: before update, after update, restart, web:disable (блокировка сервера на период обновления)
— так же нашли и допилили модуль для создания тегов при каждом деплое — теперь прямо в дереве коммитов можно легко определить кто, что, куда и когда деплоил. Различия между версиями? Пожалуйста. Дату релиза? Пожалуйста. Конфетка получилась :)
— деплой на 10 серверов разом и выполнение всяких разных команд локально\удалённо — само собой разумеющееся

Comments

[Андрей Янцен]

Странный он, этот хабрапарсер… http://habrahabr.ru/tag/capistrano/

[himik]

так же рекомендую. использую и для Ruby и для РНР проектов. отлично работает и с svn, и с git

[g00d]

Спасибо, буду пробывать.

Answer 3

[Пума Тайланд]

Jenkins ака hudson?

Comments

[Андрей Янцен]

Эмм… а каким образом CI связан с деплоем? Или я чего-то не знаю о Jenkins`е? :)