Прямой ответ
Локальная Django-разработка становится беспроблемной при четырёх решениях: settings разделены на базу и окружения (dev/prod), секреты и флаги — в переменных окружения (не в коде), база — PostgreSQL (локально тем же docker-сервисом, что и в проде — SQLite прячет расхождения), статика собирается collectstatic-подобным образом и в dev (чтобы «пропавший CSS на проде» не был сюрпризом). Плюс дисциплина миграций (одна фича — свои миграции, makemigrations локально, а не «на проде») и DEBUG=True только локально — с ним Django отдаёт отладочные страницы с конфигами, и его утечка на прод — инцидент безопасности.
Структура settings: база + окружения
Рабочая схема: пакет settings/ с base.py (общее: INSTALLED_APPS, MIDDLEWARE, TEMPLATES), dev.py (DEBUG=True, локальные тулзы — debug_toolbar, relaxed-безопасность) и prod.py (DEBUG=False, строгие заголовки, логирование), выбор через DJANGO_SETTINGS_MODULE. Все окруженческие значения — из env: SECRET_KEY, DATABASE_URL, ALLOWED_HOSTS, флаги; парсинг — django-environ/pydantic-settings (подходы к секретам — в статье про env-переменные). Локальный .env — в gitignore, в репозитории — .env.example с пустыми значениями: новый разработчик поднимает проект за минуты, а секрет ключей не живёт в истории git.
База данных: PostgreSQL с первого дня
SQLite хорош для туториалов и прототипов, но расхождения с продезом стоят дороже экономии: типы полей (ArrayField/JSONB в SQLite работают иначе или никак), блокировки при конкурентной записи, поведение транзакций. Локальный PostgreSQL поднимается одной службой (настройка — в статье про локальный PostgreSQL), а весь dev-стек (БД, redis для кеша/очередей) — docker-compose-файлом (шаблон — в статье про локальный стек). Практика тестов: отдельная тестовая БД (Django создаёт её сам), а --keepdb между прогонами ускоряет итерацию в разы.
Миграции: рутина без драм
Порядок операций: makemigrations <app> (генерация) → migrate (применение) → миграция в коммит вместе с изменением моделей. Правила, спасающие от боли: не править применённые миграции руками (создавать новую); при слиянии веток с конфликтующими миграциями — makemigrations --merge; data-миграции (заполнение таблиц) — отдельными файлами от схемных; squashmigrations при разрастании истории. Диагностика — showmigrations (что применено) и sqlmigrate (какой SQL выполнится — спасает на больших ALTER). На проде миграции применяются деплой-скриптом до старта новых инстансов, а не «как-нибудь».
Static и media: два разных механизма
Частая путаница: static — файлы кода (CSS/JS/картинки интерфейса), собираются collectstatic в один каталог и на проде отдаются веб-сервером/CDN, а Django-рантайм их не обслуживает; media — пользовательские загрузки (MEDIA_ROOT), живут вне кода и на проде — в объектном хранилище. Локальная ловушка: при DEBUG=True Django сам отдаёт статику, и «всё работает» ломается при первом же прогоне с DEBUG=False — проверяйте collectstatic-пайплайн локально (runserver --insecure или whitenoise в dev). whitenoise, кстати, разумно держать и локально: поведение dev совпадает с продом (статика через WSGI-стек).
Отладка и дев-инструменты
Минимальный набор: django-debug-toolbar (SQL-запросы страницы, шаблоны, сигналы — незаменим против N+1 прямо в браузере; только в dev и только для внутренних IP), runserver_plus/werkzeug-дебагер или pdb-точки (import pdb; pdb.set_trace() — для сложных состояний; отладочные приёмы — в статье про отладку приложений), логирование запросов в консоль через LOGGING dev-конфига. Полезная привычка — manage.py check --deploy периодически локально: прогоняет деплой-чеклист Django (SECRET_KEY, SSL-заголовки, DEBUG) и показывает, что «прод-готовность» — не разовое действие перед релизом.
Практический сценарий: первый запуск проекта на новой машине
Полезный тест качества локальной настройки — «новый коллега поднимает проект за пятнадцать минут». Вот как выглядит этот путь в здоровом проекте и где он обычно ломается. Клонирование репозитория; cp .env.example .env — и здесь первый затык, если в примере не перечислены все обязательные переменные (SECRET_KEY, DATABASE_URL, флаги) с комментариями; создание окружения и установка зависимостей из lock-файла (uv sync — детерминированно); docker compose up -d db redis — поднимается PostgreSQL и Redis из dev-стека; python manage.py migrate — накатываются миграции (падают, если DATABASE_URL в .env не совпал с портами compose — ошибка должна читаться, а не тонуть в трейсбеке подключения); python manage.py createsuperuser и, при желании, загрузка фикстур демо-данных; python manage.py runserver — и страница открывается со стилями. Каждый шаг, который потребовал «спросить у старожила», — кандидат на исправление README или скрипта make setup. Тот же чек-лист — основа healtcheck'а CI: если сборка в Actions проходит те же шаги (поднятие сервисов, migrate, тесты), локальная среда и CI не разъезжаются, а «на моей машине работает» исчезает как класс проблем.
Практический сценарий: чек-лист «прод-готовности» локального конфига
Раз в квартал (и обязательно перед релизом) стоит прогонять локально простой сценарий: поднять проект с DEBUG=False и настройками, близкими к проду, и пройтись по основным страницам. Что при этом всплывает регулярно: ALLOWED_HOSTS не включает домен (Django отдаёт 400 — на проде с правильным конфигом не всплыло бы, но привычка проверять экономит инцидент); статика не собрана (collectstatic не запускали локально — CSS отсутствует, и становится понятно, почему «на проде пропал стиль» после прошлого релиза); CSRF_TRUSTED_ORIGINS не настроен для https-домена за прокси; логирование пишет не туда (dev-конфиг логирует в консоль, прод-файл — в файл, и на проде «логов нет»). Команда python manage.py check --deploy дополняет ручной прогон автоматической проверкой деплой-чеклиста: SECRET_KEY-заглушка, отсутствие SECURE_SSL_REDIRECT, незакрытые настройки заголовков — каждая находка с объяснением. Занимает процедура пятнадцать минут, а закрывает класс проблем, которые иначе обнаруживаются пользователями в первые минуты после релиза — худшее из возможных мест для находки.
FAQ
Можно ли начинать с SQLite и перейти потом? Можно, если проект маленький и миграции чистые: DATABASE_URL меняется, данные переносятся дампом. Но чем больше кода, тем дороже расхождения поведения — для командной разработки PostgreSQL сразу дешевле.
Почему DEBUG=True опасен? Отладочная страница Django показывает настройки, фрагменты кода и переменные окружения любому, кто вызовет ошибку. Плюс отключены некоторые проверки безопасности. На проде — строго False, а ALLOWED_HOSTS — явным списком.
Как ускорить локальный runserver на большом проекте?
--noreload (если не правите код постоянно), отключение неиспользуемых middleware в dev, кеш шаблонов, и главное — следить за SQL через debug-toolbar: медленная страница почти всегда про запросы, а не про сервер.
Нужен ли celery локально?
Если в проекте есть фоновые задачи — да, воркер в docker-compose рядом; для разработки без очередей задачи можно выполнять синхронно (CELERY_TASK_ALWAYS_EAGER=True) — проще отлаживать, о нюансах — в статье про Celery.
Источники: документация Django (tutorial, deployment checklist, settings) — ссылки в шапке.