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

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

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

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

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

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

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

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

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

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

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

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

• Вопрос задан более трёх лет назад
• 39795 просмотров

• Facebook
• Вконтакте
• Twitter

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

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

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 для деплоя и запускайте тесты на Вашей локальной рабочей машине. Как только Вы почувствуете, что этого не достаточно — Вы наверняка уже будете знать, куда шагать дальше.

• Facebook
• Вконтакте
• Twitter

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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