Как правильно организовать деплой приложения?

Question

[Артур Борденюк]

Привет!


Вчера я понял, что веду свои _дела_ каким-то абсолютно варварским способом. Использование git и bitbucket уже никого не удивляет.


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


Прямо сейчас имеется мой пк на котором разрабатывается _очередной_ сайт и два компьютера, которые можно назвать серверами. Да черт с ним, два невероятно полноценных сервера — development и production сервера. ( а какой размах? )


Я честно воспользовался гуглом, в стране в которой отсутствует реестр незаконных сайтов, и понял, что мою маленькую проблему решает:

• Service POST на стороне bitbucket;
  
• Какой-то скрипт для git pull на стороне development сервера.
  

Но вот моя компетентность оставляет желать лучшего — я решил освоить тестирование. Каюсь, до селе пусть и знал, но не воспринимал тестирование любого вида, как должное. Пора становиться намного лучше!


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


И предположим, что велосипед моего производства вышел на свет в виде готового сайта на дев-сервере. По-старинке, по фтп на продакшн?


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

Т.е. есть желание сделать такие операции в результате которых с дев-сервера можно сливать на все файлики сайта, а только их часть.


Прошу обратить внимание, что мои вопросы могут быть заданы совсем неверно или не очень верно. Не сердитесь. :-(

Answer 1

[shebanoff]

Я увидел в Вашем вопросе две части.

Как правильно организовать деплой (выкладку работоспособного кода на сервер)?

В самом простом случае Вам подойдет связка ssh + git pull на сервере. В этом случае на сервер будут доставлены патчи коммитов, которые есть в репозитории, но еще не появились на сервере, т.е. «только обновления файлов, которые сейчас существуют». Этот метод довольно подробно обсудили в ответах на другой вопрос.

Если хочется автоматизировать процесс, что похвально, то я вижу три доступных инструмента для этого: Capistrano, Mina (мой персональный фаворит) и Vlad the Deployer. Все три проекта схожи по сути. Принцип их работы таков:

1. Подключиться к целевому серверу.
2. Залить обновление кода из репозитория.
3. Выполнить предписанные Вами инструкции (перезапуск демонов, сброс индексов, обновление структуры БД и прочее).
4. ...
5. PROFIT!

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

Как организовать процесс тестирования?

Если Вы еще не определились с методикой тестирования (Test Driven Development, Behavior Driven Development, Лень-Driven Development), то Вам следует для начала заняться именно этим.

Скорее всего, тесты будут выполняться на Вашей локальной машине, пока Вы пишете код. Используя RSpec, я держу открытым Guard. Guard отслеживает изменения в коде и запускает набор юнит-тестов, которые покрывают измененный код. Весь процесс занимает не больше минуты-двух, и особо не напрягает. Как только я вижу провалившийся тест, я меняю код до тех пор, пока он не станет зеленым. Пока тестов мало (это не самый лучший знак, к слову), Вы работаете один, локального запуска перед деплоем может оказаться достаточно — например, чтобы проверить релиз на доступность критического функционала: регистрации, покупки, создание постов и т.п.

В какой-то момент речь может зайти о Continious Integration. Это возможность иметь стабильный билд в любой отрезок времени, а так же принимать решение о годности каждого отдельного коммита. Сопряжено с деплоем кода на integration-сервер и запуском на нем тестов. Скорее всего, это Вас не интересует, если Вы не работаете в команде. Но, для полноты картины, Вы можете понаблюдать за билдами на Travis CI известных Open Source проектов: Symfony 2 и Ruby on Rails.

Таким образом

Вы не указали, какие конкретно инструменты для разработки Вы используете. Если же с деплоем все гораздо проще, то при выборе инструментов для тестирования я рекомендую Вам ориентироваться на те, которые нативны для Вашего основного фреймворка и языка (PHP, если правильно понимаю) и привычны их пользователям. Это позволит быстро применить устоявшиеся практики к Вашему проекту и понять всё на деле.

Приведите в порядок Ваш репозиторий с кодом, используйте mina для деплоя и запускайте тесты на Вашей локальной рабочей машине. Как только Вы почувствуете, что этого не достаточно — Вы наверняка уже будете знать, куда шагать дальше.

Comments

[egorinsk]

Не лучше ли использовать технологии вроде bash scripting для деплоя вместо всех этих капистранов? Преимущества:

1) bash-скрипт простой и короткий. Его легко и быстро написать. Во всяких капистранах надо сначала полдня изучать инструмент, потом думать, каким костылем можно заставить его делать то, что нужно.
2) bash-скрипт легко проверить на отсутсвие ошибок и не надо полдня отлаживать
3) bash-скрипт делает ровно то, что в нем написано. Что сделает сложная система, написанная другим человеком неизвестной квалификации — никому неизвестно
4) Простое решение лучше сложного

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

Плюс, как видно из описания Mina, это чрезвычайно тяжелый и сложный инструмент: вы добавили пару строчек в файл, логично закачать измененный сервер на файл за полсекунды и успокоиться, но она будет делать репозитории, выкачивать что-то, собирать, загружать… боюсь, это не способствует быстрой разработке.

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

В общем, советую автору вопроса сделать самую-самую простую систему деплоя на основе bash скрипта/нескольких скриптов и FTP/SFTP и не мучаться.

[Артур Борденюк]

Инструменты для разработки? PHP, MySQL, свои велосипеды (никакого yii).
Методика тестирование? TDD. :)

Очень здорово! С этими вопросами покончено! Спасибо.
Значит на продакшн проще по-старинке, да?
И всё-таки может ли гит выкачать определенные папки из конкретной ветки с указанного удаленного репозитория?

[shebanoff]

Egorinsk — Mina, если Вы этого не заметили, сама по себе генерирует баш скрипт и транслируется из Ruby напрямую в bash. Это очень легкий инструмент и отдельного внимания заслуживает DSL с помощью которого и генерируется конечный баш-скрипт. По поводу «сложной системы», «другого человека» и «неизвестной квалификации» — предлагаю периодически думать.
По поводу тестов — я привел пример того, как запускать тесты. Автор просил именно этого совета. И конечно юнит-тесты не панацея.

Автор, уточните пожалуйста, с какой целью Вы хотите выдергивать отдельные папки из гита? Сразу скажу, что это невозможно :)

[Артур Борденюк]

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

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

Без абстракции всё выглядит примерно так: есть мой микро-фреймворк который реализует базовый функционал простого сайта — я его назвал ядром. И всякие модули к нему, например галерея с множественной загрузкой картинок. На одном сайте такой модуль нужен — на другом нет. Но ядро везде одно и тоже.

Вопрос стоит таким образом: как производить обновления основных компонентов сайта (ядра) и при этом не лазить на каждый сайт по фтп?

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

Есть решение? Можно вызвать более опытных товарищей на скайпообщение?

[Артур Борденюк]

Блин, ребята, пожалуйста. _Автор, скажи, пожалуйста_ — немного обижает. Будьте любезны, HighQuality либо Артур. :(

[shebanoff]

Прошу прощения, Артур)

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

[Toast]

Вопрос по поводу Capistrano, Mina и тд. Не знаком с ними, но бегло почитав страницы продуктов не увидел большой разницы между ними и использованием git с хуками. Возможно я что-то упускаю, но основные операции, что вы описали (перезапуск демонов, сброс индексов, обновление структуры БД и прочее) выполняет git, в моем случае я вешаю хук на сервер и после получения мастер бренча в репозиторий git производит деплой в необходимую папку со всеми необходимыми операциями. Оправдано ли использование Capistrano etc, если использовали git для этого, то чем удобнее оказались эти инструменты?

[shebanoff]

@Toast Capistrano, Mina и т.д. - это все инструменты для автоматизации деплоя, а git - это система контроля версий. Так что лучше отделить котлет от мух, области применения все же разные.

Capistrano-подобные инструменты дают DSL (язык) для описания конфига, а также предлагают некоторый workflow деплоя по умолчанию. Исторически наибольшее распространение эти инструменты получили в сообществе Ruby on Rails разработчиков (хотя могу врать, конечно), где их использование дает деплой "из коробки", буквально. С плавным перезапуском сервера, контролем и версионированием ассетов, миграцией данных.

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

И, конечно, от гита вам отказываться не придется. И мина, и капистрано в первую очередь идут от идеи о том, что ваш код лежит в репозитории под контролем git.

Попробуйте, это просто.

Answer 2

[Вячеслав Слинько]

Мой стек php:
— для тестов: локально Behat;
— для деплоя capifony;
— для модульности composer.

Answer 3

[Михаил]

Нельзя дать хороший совет, не зная языка, на котором пишется приложение. От языка зависит выбор инструментов. Нельзя посоветовать uDeploy для PHP, но он прекрасно сойдет для Java. Нельзя советовать Grunt для C++, но в JS без него никуда. И так далее.