HighQuality
@HighQuality
☁ Ниндзя девелопер

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

Привет!


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


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


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


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

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



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


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


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


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

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


Прошу обратить внимание, что мои вопросы могут быть заданы совсем неверно или не очень верно. Не сердитесь. :-(
  • Вопрос задан
  • 40312 просмотров
Решения вопроса 1
shebanoff
@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 для деплоя и запускайте тесты на Вашей локальной рабочей машине. Как только Вы почувствуете, что этого не достаточно — Вы наверняка уже будете знать, куда шагать дальше.
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
Мой стек php:
— для тестов: локально Behat;
— для деплоя capifony;
— для модульности composer.
Ответ написан
Комментировать
Singaporian
@Singaporian
Нельзя дать хороший совет, не зная языка, на котором пишется приложение. От языка зависит выбор инструментов. Нельзя посоветовать uDeploy для PHP, но он прекрасно сойдет для Java. Нельзя советовать Grunt для C++, но в JS без него никуда. И так далее.
Ответ написан
Комментировать
Ваш ответ на вопрос

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

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