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

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

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

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

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

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

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

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

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

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

есть идеи?

P.S. ранее все работало через СВН и по этому на продакшене есть папочки .svn (закрытые через шттп), хочется найти способ что б перейдя на него, не вспоминать о старых временах :)
  • Вопрос задан
  • 5033 просмотра
Пригласить эксперта
Ответы на вопрос 3
klen
@klen
Ну так, что вам мешает развернуть на продакшен тот же Git репозиторий и получать в него только изменения?
Ответ написан
Рекомендую 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 серверов разом и выполнение всяких разных команд локально\удалённо — само собой разумеющееся
Ответ написан
opium
@opium
Просто люблю качественно работать
Jenkins ака hudson?
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы