Переменные окружения и конфигурация

Некоторые значения нельзя записать прямо в код: секретные ключи, пароли базы данных, адрес сервиса. А некоторые должны меняться в зависимости от того, где работает приложение. Код, который вы тестируете на ноутбуке (окружение dev), должен обращаться к тестовой базе данных; живое приложение, которым пользуются ваши пользователи (окружение prod, или продакшен), должно обращаться к настоящей — используя тот же код.

Ответ — переменные окружения (часто «env vars»): именованные значения, которые живут вне кода и подаются ему при запуске. Код говорит «дай мне DATABASE_URL», а окружение решает, какую именно передать.

# Файл конфигурации (например, .env) — значения живут здесь, а не в коде

DATABASE_URL=postgres://localhost/myapp_dev
STRIPE_SECRET_KEY=sk_test_51H...     # dev = тестовый ключ
SEND_REAL_EMAILS=false               # не слать письма реальным пользователям во время тестов

Два правила избавят вас от настоящей боли:

• Секреты никогда не попадают в код. Всё, что в вашем коде, может в итоге стать публичным (особенно в общем репозитории), а утёкший платёжный ключ или пароль базы данных — это настоящая чрезвычайная ситуация. Секретам место в env vars, вне системы контроля версий.
• Dev и prod — разные. Смысл в том, что один и тот же код ведёт себя правильно в обоих, потому что окружение — а не код — решает, какую базу данных и какие ключи использовать.

Один и тот же код, два дома — различаются именно переменные окружения:

        SAME CODE
       /         \
      ▼           ▼
   ┌─────────────────┐     ┌─────────────────┐
   │  DEV            │     │  PROD           │
   │  ваш ноутбук    │     │  хостинг(облако)│
   │  тест. БД       │     │  реальная БД    │
   │  тест. ключ     │     │  боевой ключ    │
   │  фейк. письма   │     │  реальные письма│
   └─────────────────┘     └─────────────────┘
     видите только вы        видят ваши юзеры