От идеи на ноутбуке до приложения, которым реально пользуются
Любое приложение начинается одинаково: с идеи в чьей-то голове. Возможно, вы хотите решить проблему, которую заметили, или ваша команда попросила вас создать что-то новое. Какова бы ни была причина, в какой-то момент вы открываете ноутбук и начинаете писать код.
На ноутбуке всё кажется простым. Вы запускаете приложение, видите интерфейс, пробуете несколько функций — и всё работает. Если что-то ломается, вы чините и запускаете снова. Приложение видите только вы. Никто другой не пострадает, если оно упадёт или выдаст ошибку.
Но идея создания приложения редко ограничивается вашим ноутбуком. Вы создали его, чтобы им могли пользоваться другие — друзья, клиенты, коллеги в офисе или широкая публика. Как только кому-то ещё понадобится доступ к нему, возникает самый базовый вопрос: где будет работать это приложение, чтобы другие могли до него добраться?
Ваш ноутбук для этого не подходит. Ноутбуки выключаются, у них садится батарея, их уносят домой, или они подключаются к сетям, блокирующим внешний доступ. Если приложение работает только на вашей машине, другие люди могут им пользоваться, только пока вы сидите перед ней и ваша сеть разрешает внешние подключения. Это непрактично и ненадёжно.
Первая реальная потребность: место для запуска
Приложению нужно место, которое постоянно включено, постоянно подключено к сети и доступно тем, кому вы разрешили. Такое место называется сервером. Сервером может быть физический компьютер, которым вы управляете сами, или виртуальная машина, арендованная у облачного провайдера. Важно то, что сервер — это компьютер, основная задача которого — запускать приложения и обрабатывать запросы пользователей.
Процесс размещения вашего приложения на сервере, чтобы другие могли к нему обратиться, — это первая реальная потребность, возникающая при доставке программного обеспечения. Эта потребность часто называется хостингом. Вам нужно решить, где будет размещено приложение, как отправить туда ваш код и как убедиться, что приложение действительно запустится после этого.
Сервер, на котором работает приложение, используемое реальными пользователями, называется продакшен-средой (production environment). Слово «продакшен» сигнализирует, что это больше не тестовая зона. Это место, где приложение должно работать корректно, потому что на него полагаются реальные пользователи. Если в продакшене возникнет ошибка, пользователи не смогут использовать его функции. Если оно полностью упадёт, пользователи вообще не получат доступа к сервису.
Разница между вашим ноутбуком и продакшеном
Разрыв между вашим ноутбуком и продакшен-средой фундаментален. На ноутбуке у вас полный контроль, и серьёзных последствий, если приложение сломается, нет. В продакшене приложение должно продолжать работать, быть доступным и оставаться стабильным. Последствия сбоя напрямую ощущают пользователи.
Именно здесь многие разработчики впервые осознают нечто важное: заставить приложение работать на собственном ноутбуке — это личное дело. Сделать приложение доступным для других людей — совершенно другая задача. Вам нужно место для его запуска, способ доставки кода туда и уверенность, что после доставки оно будет работать корректно.
Как на самом деле доставить приложение на сервер?
Как только у вас есть сервер, следующий логичный вопрос: как доставить туда приложение? Достаточно ли просто скопировать файлы? Или здесь есть что-то ещё?
Ответ зависит от того, какое приложение вы создали. Если это простой статический сайт, копирования HTML-файлов может быть достаточно. Но большинство приложений сложнее. Им нужны установленные зависимости, настроенные конфигурационные файлы, подключённые базы данных и определённые переменные окружения. Простого копирования кода почти всегда недостаточно.
Здесь и появляется понятие деплоя (deployment). Деплой — это процесс переноса вашего приложения из его источника (обычно репозитория кода) и запуска в целевой среде. Он включает копирование нужных файлов, установку зависимостей, выполнение шагов настройки и запуск процесса приложения, чтобы оно начало принимать запросы.
Простой деплой может выглядеть так:
- Забрать последний код из репозитория на сервер.
- Установить новые зависимости.
- Выполнить миграции базы данных, если изменилась схема.
- Перезапустить процесс приложения.
Даже эта простая последовательность может пойти не так. Что, если на сервере другая операционная система, чем на вашем ноутбуке? Что, если версия зависимости конфликтует с уже установленной? Что, если миграция базы данных займёт больше времени, чем ожидалось, и пользователи увидят ошибки?
Сделать доступным vs. Сделать работающим
Есть ещё одно различие, которое стоит заметить на раннем этапе: разместить приложение на сервере — это не то же самое, что сделать его доступным для пользователей.
Вы можете скопировать все файлы на сервер, запустить процесс и всё равно получить приложение, до которого никто не сможет добраться. Возможно, файрвол сервера блокирует порт. Возможно, доменное имя не указывает на правильный IP-адрес. Возможно, приложение привязывается к localhost вместо сетевого интерфейса. Возможно, SSL-сертификат истёк, и браузеры отказываются подключаться.
Сделать приложение по-настоящему используемым — это нечто большее, чем деплой. Это означает убедиться, что сеть настроена правильно, DNS-записи указывают на нужное место, приложение слушает правильный адрес и порт, а сервис продолжает работать даже после перезагрузки сервера.
Вот почему продакшен-среды никогда не сводятся только к коду. Они включают работу с сетями, системное администрирование, мониторинг и часто требуют отдельной команды или человека, отвечающего за поддержание инфраструктуры в рабочем состоянии.
Что дальше
Как только ваше приложение запущено в продакшене и пользователи могут к нему обращаться, путешествие не заканчивается. Пользователи найдут баги. Они попросят новые функции. Кто-то обнаружит уязвимость в безопасности. Бизнес захочет добавить платёжный модуль или изменить пользовательский интерфейс.
Каждое из этих изменений означает, что вам нужно обновить приложение в продакшене. И каждое обновление несёт риск. Новая функция может сломать что-то ещё. Миграция базы данных может повредить данные. Изменение конфигурации может замедлить приложение.
Именно здесь становится очевидной потребность в надёжном, воспроизводимом процессе. Вы не можете позволить себе каждый раз вручную копировать файлы и надеяться, что всё сработает. Вам нужна система, которая последовательно собирает, тестирует и развёртывает ваше приложение.
Эта система — то, что будет рассмотрено в остальной части этой серии статей. Но прежде чем мы перейдём к этому, стоит проверить, покрыты ли в вашей текущей настройке основы.
Быстрая практическая проверка
Если вы сейчас запускаете приложение, которым пользуются другие люди, задайте себе эти вопросы:
- Знаете ли вы точно, на каком сервере работает приложение?
- Можете ли вы развернуть новую версию менее чем за 30 минут с уверенностью в успехе?
- Если сервер упадёт, сможете ли вы восстановить приложение и его данные?
- Знаете ли вы, что произойдёт при перезагрузке сервера?
- Можете ли вы откатиться на предыдущую версию, если что-то пойдёт не так?
Если вы ответили «нет» на любой из этих вопросов, вы не одиноки. Большинство команд начинают с ручных процессов и улучшают их со временем. Важно осознать эти пробелы и начать закрывать их один за другим.
Вывод
Создание приложения, которым люди могут реально пользоваться, начинается с простой истины: ваш ноутбук — это не продакшен. Разрыв между запуском кода локально и его работой для реальных пользователей — это то место, где скрывается большая часть сложности доставки программного обеспечения. Прежде чем беспокоиться о пайплайнах, автоматизации или продвинутых стратегиях деплоя, убедитесь, что вы понимаете, где работает ваше приложение, как оно туда попадает и что ему нужно для бесперебойной работы. Всё остальное строится на этом фундаменте.