Разрабатывать локально это прикольно, но интерфейсом должны пользоваться другие люди, верно?
Раньше всё было легко — воткнул джс в тег <script>, залил через ФТП и получил новый сайт. Сейчас всё стало сложнее:
- во-первых, мы используем Бейбель, чтобы компилировать код из нового стандарта в тот, что поддерживается браузерами сейчас;
- во-вторых, нужно минифицировать код;
- в-третьих, Вебпак должен разбираться со всеми импортами: мы же не положим картинку в джс-файл, хоть мы её и импортим там?
Для этого существует шаг билда.
Билд (build) это этап сборки проекта: когда весь проект собирается в продакшен версию.
Продакшен это один из видов окружения: места, где работает ваш код. Во фронтэнде продакшен-версия обычно означает, что файлы будут минифицированы, сжаты через какой-нибудь gzip, вырезаны лишние проверки, благодаря этому уменьшен код и так далее. Почитайте в доке КРА — там об этом хорошо рассказано.
Билдится проект через react-scripts build (эта команда уже записана в package.json под build благодаря CRA и поэтому можно вызвать как yarn build), после билда у вас будет директория build с файлами: index.html в корне, в static — main.[hash].js, main.[hash].css и так далее.
Если вы откроете файл build/index.html в браузере, то вы получите белый экран и ошибку в консоли, что файлы .css и .js не найдены. Почему так?
Если вы почитаете документацию КРА, то заметите некий параметр PUBLIC_URL — при билде КРА заменяет его на указанное значение.
Например, если ваш PUBLIC_URL равен https://erodionov.ru, то после билда ссылки на джс- и цсс-файлы будут выглядеть как
<link href="https://erodionov.ru/static/css/main.e34a431d.css" rel="stylesheet">
...
<script src="https://erodionov.ru/static/js/main.6e03bcce.js"></script>Как указать паблик урл? Это делается энв-параметром: специальным параметром, который задаётся в системе.
Если вы хотите вшить его до перезагрузки, то в Терминале вбейте export PUBLIC_URL=... — КРА подхватит при билде.
Если вы не хотите вшивать в систему навсегда, а хотите лишь при вызове одной команды — укажите её перед вызовом, например, PUBLIC_URL=... yarn build. Это удобно, если вы работаете с несколькими проектами.
Если вы работаете с несколькими проектами, то можете задуматься о файле .env — КРА поддерживает библиотеку dotenv, которая устанавливает энв-параметры через файл .env, находящийся в корне проекта.
И вы, конечно же, можете установить свои энв-параметры: в Джсе благодаря Вебпаку они доступны в объекте process.env (например, console.log(process.env.PUBLIC_URL)), но хочу уточнить, что КРА заставляет все кастомные энв-параметры префиксовать как REACTAPP*. Ради безопасности!
Окей, с паблик урл и энв-параметрами разобрались, с билдом тоже — в build мы получаем готовую статику, а что делать с этим дальше? Люди же не будут заходить к вам на ноутбук и искать директорию билд.
Деплой (deploy) это процесс выкатки обновлений.
Что делать с билдом? Его нужно куда-нибудь залить, чтобы он был доступен по адресу (ХТТП).
Интернет делится на несколько вещей, давайте поработаем через аналогии с городом:
- хостинг — это библиотека,
- домен — адрес библиотеки,
- ДНС — карта города
Хостинг — это сервер, где находится ваш сайт (или база данных, или контр-страйк сервер или ещё что-то).
Домен — адрес к этому серверу.
Конечно же, на одном сервере может быть несколько доменов привязанных — для этого используют веб-сервер (типа nginx), который указывает, что по адресу
x.comнужно показать контент из директории/www/x.com, а по адресуy.comнужно отправлять запросы на локальное приложение, которое находится на порте 1234. Об этом будем разбирать в следующем уроке.
По ДНСу браузер (или любой другой клиент) определяет, на какой сервер нужно сходить по домену. ДНС это каталог, так сказать.
Что нам дали эти знания? Нам нужно залить сайт на хостинг, к которому будет привязан домен через ДНС.
Но нас пока эта сложность не очень интересует, нам нужно получить минимальный рабочий результат. Для этого мы возьмём now.sh — это не совсем хостинг, это некая инфраструктура для разработки: от деплоев до управления ДНС.
Наусш работает очень легко: вы ставите now из нпма и затем командой now deploy [path] деплоите проект, где path — путь к билду.
Пример? mlshv-burberry-fake-shop-for-study.now.sh.
Если вы попробуете задеплоить свой проект, вам выдаст поддомен erodionovru-dyltftawkr.now.sh, а то и вовсе build-dyltftawkr.now.sh.
Чтобы исправить build в названии, можно указать опцию --name, а для исправления "уродского" поддомена можно использовать альясы.
Наусш работает по принципу иммутабельных деплоев: если вы что-то задеплоили, то именно за этим деплоем закрепляется уникальный айдишник (именно он и есть уродливый поддомен) — это удобно.
Для постоянного адреса есть альясы, в том числе своего отдельного домена (но понадобится платный аккаунт от $15 в месяц).
Насколько Наусш надёжный и подходит для разработки? Ну, этот сайт находится на Наусш :) В серьёзной разработке я бы на него не завязывался, купил бы свой сервер и настроил бы через Докер всё, но в целом приятный сервис.
Но, согласитесь, деплоить руками даже через команду now build (можно опустить deploy, потому что это дефолтная команда и она вызывается при простом now) как-то не очень удобно: сначала коммит, потом пуш, потом ещё и задеплоить.
Было бы удобно, если бы проект сам собирался и деплоился бы при пуше в репозиторий! Такой подход называется Continuous Deployment (на самом деле их аж три: Continuous integration vs. continuous delivery vs. continuous deployment).
Один из самых популярных публичных и бесплатных для опенсорса сервисов — Travis CI.
Трэвис работает по принципу сценариев: в YAML-файле (в корне проекта .travis.yml) описывается сценарий, который выполняется при каждом коммите.
В этом уроке вы познакомились с билдами, деплоями, окружениями и их параметрами (я про энвы), немного копнули даже в хостинги-днсы и узнали про сервисы деплоя. Хотите задание?