За пределами .env: объяснение поддержки нескольких сред Django

Недавно я погрузился в увлекательный проект — REST API, воплощенный в жизнь с помощью Python и фреймворка Django.

Готовясь вывести наше творение за пределы уютных рамок разработки, мы с моей командой подготовили почву для настоящего выступления. Мы подготовили звездную линейку сред:

  • местная игровая площадка, где идеи превращались в код,
  • испытательная арена, где тщательно проверялось каждое движение,
  • и грандиозная сцена производства, где вскоре соберутся пользователи со всех уголков.

Для точной настройки каждой из этих сред мы использовали надежные переменные среды. Но, как и в любой парадигме, здесь есть некий поворот. Эта простая практика имеет свои преимущества и особенности.

В области Django разработчики могут использовать в своих проектах файл .env, в котором они могут хранить переменные среды, такие как ключи, URL-адреса и другие проходы за кулисами:

DEBUG=True
AUTH_SERVER_URL=https://yourserver.com
MAX_REQUESTS_PER_USER=1000/day
...

Затем в стране файла settings.py — файла настроек среды, предоставляемого Django по умолчанию, они могут получать значения из мистического файла .env.

Эта стратегия хорошо сработала в нашем проекте. Мы были вполне удовлетворены улучшением безопасности конфиденциальной информации. Ключи API, пароли к базе данных и важнейшие секретные ключи нашли убежище от любопытных глаз контроля версий.

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

Хотя это немного похоже на переключение функций, это требование имело уникальный оттенок.

Переключение функций (часто также называемое флагами функций) — это мощный метод, позволяющий командам изменять поведение системы без изменения кода. — Пит Ходжсон