[БЕЗ_ЗВУКА] Всем привет!
В этом видео мы поговорим о том,
чем отличается разработка проекта на локальном компьютере от работы проекта
в production-окружении, то есть на боевых серверах и на широкую публику.
Отмечу очевидные различия.
Во время разработки на локальном компьютере проект доступен только вам,
разработчику, и нагрузки на него нет вообще никакой.
Запросы не выполняются параллельно, никто вас не пытается сломать или заддосить,
скорость вам абсолютно не важна, зато важно удобство отладки.
Удобно, например, когда все ошибки выводятся прямо на веб-страничку,
на которой они произошли, или в консоль, где запущен сервер,
чтобы сразу их увидеть и исправить.
Удобно, когда письма не отсылаются вашим проектом на реальные email-адреса,
а складываются куда-то, либо в папку, либо есть специальные сервисы,
локальные сервера mailhog или mailcatcher,
которые умеют отлавливать письма и показывать их в веб-интерфейсе.
Удобно, когда у всех пользователей в базе одинаковые пароли,
или можно зайти под разными пользователями вообще без пароля, так,
чтобы легко переключаться между пользователями для отладки опять-таки.
Удобно, когда при любом изменении кода или шаблонов изменения сразу видны на
вашем сайте локальном.
То есть когда включен авторелоад и отключены, например, все кеши.
Удобно, когда все js-, css-файлы не сжаты и не обфусцированы,
их легко посмотреть и изменить.
А вот на production ситуация совсем иная.
Может прийти сразу много людей и возникнуть большая нагрузка.
Могут появится параллельные запросы, и они могут привести к состоянию гонки.
Нельзя выводить подробные сообщения об ошибках на экран: их увидит пользователь,
и либо не поймет, либо, что может быть еще хуже, поймет и как-то использует.
При этом об ошибках тем не менее надо оперативно уведомлять разработчика,
то есть ошибки обрабатываются совершенно по-другому.
Важна безопасность и производительность.
Все должно быть заранее скомпилировано, оптимизировано.
Статика, такая, как js- и css-файлы, картинки, файлы пользователей,
раздаются не вашим приложением, как обычно это бывает в разработке,
а специальным оптимизированным под это веб-сервером, например,
nginx, или даже сторонним сервисом для доставки контента, CDN.
Например, самый известные — это Cloudflare, NetDNA или Amazon CloudFront.
Пароль от базы данных, ключи шифрования, данные для авторизации во
всевозможных сторонних API должны быть разными в разработке и в production.
Во многих компаниях у разработчиков нет доступа к боевым серверам и боевым базам
данных, и они не знают пароли и другие боевые реквизиты.
Таким образом, настройки проекта для разработки очень сильно
отличаются от настроек этого же проекта при запуске его в production.
Это касается, например, флагов отладки,
которые есть у многих фреймворков, и влияют на вывод
стек-трейса на страницу при ошибке и много на что еще на самом деле.
Это касается секретных реквизитов: паролей, настроек кешей,
путей для различных файлов, используемых веб-серверов для запуска приложения
и методов раздачи статических файлов, хотя не только этого.
Важной частью является и то,
как код разработчиков попадает и запускается на боевых серверах.
Нет каких-то общих подходов и шаблонов,
и в каждой компании это реализовано по-своему.
Код может запускаться на железном сервере, своем или арендованном, на
виртуальной машине, так называемой VPS, в докер-контейнере или на облачном хостинге.
Одних только крупных облачных хостингов наберутся десятки.
Из известных: Amazon EC2, Microsoft Azure, Google App Engine, Heroku и другие.
При этом выбранная вами инфраструктура: VPS, облачный хостинг и так далее,
может сильно влиять и на стек используемых вами технологий,
и на способы доставки кода из среды разработки на production.
Например, в Heroku достаточно закомить изменения в
специальный репозиторий git, для того чтобы запустить код на production.
А, например, Google App Engine накладывает ограничения на доступные языки
программирования и привязывает проект к своему стеку технологий.
В нашей компании разработчики собирают код в rpm-пакеты,
а их раскладкой на боевые сервера и мониторингом заведует отдел эксплуатации,
то есть совершенно другие люди.
Я для одних своих домашних проектов использую VPS-сервера,
и ansible для доставки на них кода, а для других я использую облачный сервис Heroku,
а кто-то до сих пор копирует файлы по FTP.
В большинстве компаний также используются системы непрерывной интеграции,
обычно на базе чего-то вроде Jenkins или Gitlab CI.
Они, при обнаружении изменений в коде в системе контроля версий,
автоматически выкачивают эти изменения и запускают сборку проекта и
автоматические тесты, проверяют качество кода и его покрытие тестами,
а могут заодно и выкатывать код на боевые или тестовые сервера.
Это позволяет автоматически тестировать любые изменения,
внесенные в код разными членами команды, и обнаруживать проблемы,
особенно проблемы интеграции и ошибки на очень ранних этапах.
Они также позволяет автоматизировать многие рутинные операции по
сборке проекта и подготовке его к production.
Также между разработкой и production существуют еще и stage,
или отладочные сервера.
Железо и ПО, а также процессы на них, процессы в том числе доставки кода,
максимально приближены к production-серверам, но при этом
используются они для внутреннего тестирования, то есть недоступны снаружи,
но при этом для тестирования в условиях, максимально приближенных к боевым.
Конкретные механизмы: continuous integration,
тестирования, релизов на боевые сервера, способы запуска кода в production,
мониторинга и уведомления об ошибках,
очень сильно отличаются от компании к компании, и даже от проекта к проекту.
И разные задачи в этих процессах могут выполняться совершенно
различными командами, не только программистами, но и девопсами,
тестировщиками, администраторами.
Я поэтому расскажу в курсе только какие-то отдельные моменты запуска проекта на
боевых серверах.
Давайте подведем итоги.
Работа вашего приложения во время разработки может сильно отличаться от
работы этого же приложения в production.
И файлы конфигураций и настройки приложения будут отличаться.
Существуют системы непрерывной интеграции и непрерывного развертывания для
автоматизации действий по сборке и тестированию проекта.
Для запуска вашего кода на широкую аудиторию нужны сервера.
Это могут арендованные физические или виртуальные сервера или облачный хостинг.
Процесс выкладки кода в production тоже может быть различным.
Это может быть и установка rpm-файлов, и докер-контейнеры,
и даже просто копирование файлов вручную и перезапуск нужных сервисов.
[ЗВУК] [БЕЗ_ЗВУКА]
