За пределами .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, пароли к базе данных и важнейшие секретные ключи нашли убежище от любопытных глаз контроля версий.
Но в тот день, когда мы получили новое требование по реализации новой функции, которую можно было включить/отключить только в определенной среде, все изменилось.
Хотя это немного похоже на переключение функций, это требование имело уникальный оттенок.
Переключение функций (часто также называемое флагами функций) — это мощный метод, позволяющий командам изменять поведение системы без изменения кода. — Пит Ходжсон