---
title: Локальная разработка веб-проектов
description: Как устроена локальная среда разработки, какие задачи она решает и как выбрать подход между специализированным окружением и контейнеризацией.
---

## Что такое локальная разработка

Локальная среда — набор инструментов и сервисов на компьютере разработчика, в котором приложение можно запускать, менять и проверять до публикации. Обычно в неё входят язык и runtime, веб-сервер, база данных, кэш, очереди, инструменты сборки и тестирования, а также конфигурация домена и HTTPS.

Цель среды — сократить время между изменением кода и проверкой результата, сохранив достаточно сходства с тестовым и production-окружением. Она не обязана копировать production полностью: важно явно понимать различия, например в масштабе, сетевой топологии, почте и внешних интеграциях.

## Из каких частей состоит среда

- **Runtime и зависимости.** Зафиксированные версии PHP, Node.js или другого языка и воспроизводимая установка библиотек по lock-файлу.
- **Приложение и веб-сервер.** Запуск проекта, маршрутизация запросов, локальный домен и при необходимости доверенный HTTPS.
- **Инфраструктурные сервисы.** Базы данных, кэш, очереди и хранилища, которые приложение использует во время работы.
- **Конфигурация и данные.** Локальные переменные окружения, тестовые данные, миграции и правила, исключающие секреты из Git.
- **Инструменты обратной связи.** Логи, отладчик, профилировщик, тесты и автоматическая перезагрузка после правок.

## Как выбрать способ запуска

Есть три распространённых модели. Можно установить runtime и сервисы непосредственно на компьютер; это просто для одного стека, но версии и системные настройки могут конфликтовать. Можно использовать специализированную среду, которая автоматизирует типовые проекты и управление сервисами. Или описать приложение и зависимости контейнерами — это даёт явную конфигурацию и помогает команде запускать одинаковый стек на разных компьютерах.

Выбор зависит от проекта и команды: числа стеков, нужды изолировать версии, особенностей файловой системы, требований к совместной работе и опыта поддержки Docker. Не переносите контейнеризацию в проект как самоцель: сравните стоимость поддержки конфигурации с выгодой воспроизводимости.

## Практический минимум

1. Уточните поддерживаемые проектом версии языка и сервисов; используйте lock-файлы.
2. Опишите один повторяемый путь запуска и проверки, пригодный для нового участника команды.
3. Храните локальные настройки отдельно от кода, а реальные секреты не коммитьте.
4. Используйте тестовые данные и отдельные локальные базы; не подключайте среду разработки к production.
5. Проверьте миграции, фоновые процессы, загрузки файлов, почту и внешние API — часто именно они расходятся между машинами.
6. Добавьте проверки готовности сервисов и сохранение нужных данных между перезапусками.
7. Документируйте отличия локальной среды от CI и production и регулярно проверяйте инструкции на чистом checkout.

## Подходы и инструменты

- [Lerd](https://wpcraft.ru/kb/stacks/local-development/lerd.md) автоматизирует локальную среду для PHP и других веб-проектов через rootless Podman, домены, сервисы и рабочие процессы.
- [Docker Compose](https://wpcraft.ru/kb/stacks/local-development/docker.md) описывает приложение и зависимости в контейнерах и подходит, когда команде нужна явная конфигурация стека.

Для окружений после локальной разработки см. [CI/CD и GitHub Actions](https://wpcraft.ru/kb/infrastructure/devops/cicd-github-actions.md) и материалы по [типам хостинга](https://wpcraft.ru/kb/infrastructure/hosting/hosting-types.md).

## Материалы и источники

- [Lerd](https://lerd.sh/)
- [Docker Compose: Watch](https://docs.docker.com/compose/how-tos/file-watch/)
- [Docker Compose: secrets](https://docs.docker.com/compose/how-tos/use-secrets/)