Capistrano deploy

Как ранее уже писалось ^[1]
Данную статью можно рассматривать как опыт внедрения capistrano, после прочтения статьи. Статья-дополнения, скажем так.
Статью разделю на 3 части, это первая.
В первой части опишу теоретические сложности, с которыми я столкнулся по мере работы с капистрано.
Во второй- установка и настройка базового функционала.
Третья- финальная, допиливание=)

Capistrano — это не для php, по своей природе. Он для ruby on rails. Но его с легкостью можно использовать так и для деплоя php проектов.

Теория

Continious integration, непрерывная интеграция(CI)
Схему CI используют, как правило, в больших проектах, где время простоя очень критично для компании. Поэтому необходимо делать внедряй плавно и незаметно для конечных пользователей.

Компания, в которой я тружусь, отчасти относится к интернет магазину, оттого время простоя складывается в капеечку. Поэтому передомной появилась задача внедрения CI. Все усложнялось и тем, что у нас не поставлена на поток работа с git. Все всё фиксили на бою. Иногда пушались в мастер.

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

Далее начинается самое интересное — мучительный выбор между Hudson,Capistrano и… не могу вспомнить названия, phpDeploy

Последний вариант оказался слишком древним и неповоротливым, да и не дружелюбным в плане освоения.
Hudson — Легкий в установке, с веб мордой, много всяких кнопочек… но душа не лежит. Возможно как раз из-за большого числа настроек, сразу теряешься.
Capistrano — Консольный диплой, легкий, могучий и гибкий.
Надо заметить, что про в нете материала про capistrano/hudson достаточно, но все на англ.

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

Что умеет делать Capistrano

Вобще схема его работы такая
Он скачивает на удаленный сервер ветку, которую вы указываете в конфиге (делает git clone).
Создает, в указанном вами месте, папку с релизом, сгенерированным по текущей дате.
Переключает симлинк до нового актуального релиза (при этом ваш паблиш сервер должен читать сайт с симлинка)

Чтобы git clone не занимал много время, он у себя хранит кеш проекта. Смотрит, что поменялось, копирует в новый релиз неизменный кусок из локального кеша — что делается быстрее, чем если ваш гит сервер и паблиш сервер находятся на разных машинах.
При откате он лишь изменяет цель симлинка. Ну а вобще при откате он может удалить старый релиз, с которого откатились или не трогатьт его… ну и окатиться на любой релиз. Или вобще отпулить в текущей релиз старый коммит. Как вы ему скажите!

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

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

В случае не успешного релиза (недоступен гит, кончилось место… и т.д.) он все откатывает, как было до запуска деплоя.
В случае успешного релиза, в папке релиза создается локальная ветка «deploy»

Пожалуй, первую часть я закончил. Если коллегам интересно, то с удовольствием поделюсь опытом доведения до ума CI во второй части.

Автор: mflash123

Источник ^[2]