Различия в Env vars и Docker между dev, staging и prod
Хотя мой конкретный пример включает Django, Docker и Heroku, я считаю, что это довольно общие вопросы тестирования/QA.
У меня есть докеризованное приложение Django, протестированное в dev с помощью Selenium и подтверждающее, что мои статические файлы правильно обслуживаются из моей локальной папки (EXPECTED_ROOT = '/staticfiles/'). Это приложение развернуто на Heroku, и я вижу (визуально и в инструментах разработчика), что статические файлы также корректно подтягиваются из CloudFront. Я хочу формализовать это с помощью того же теста, который я использую в dev. Мой первый вопрос связан с тем, используются ли/как переменные окружения для тестов:
- Нужно ли мне добавить, например,
EXPECTED_ROOT = 'https://<somehash>.cloudfront.net/'в качестве env var в Heroku и использовать его в Selenium-тесте?
Кроме того, для запуска этого теста в staging мне нужно будет установить Firefox в образ Docker, как я это делаю в dev. Возможно, это нормально в staging, но в prod я считаю, что должен стремиться к минимально возможному образу. Итак, вопрос заключается в различиях между staging и prod:
- Нужно ли мне сохранить Firefox в моем staging-образе, запустить тесты, а затем отправить в продакшн копию этого Dockerfile, но теперь без firefox?
Любая помощь будет принята с благодарностью.
Идея Config Var заключается в настройке конфигурационных переменных, которые отличаются в разных средах. При этом вы контролируете среду и можете определить то, что вам нужно.
Лично я использовал бы другой подход: создал бы тест, который не зависит от среды (например, вместо тестирования expected root я бы подтвердил, что найден данный DIV ID или какой-то другой элемент).
Этого будет достаточно, чтобы подтвердить, что тест прошел успешно и функциональность работает так, как ожидалось.
Производственный Dockerfile действительно не нуждается в Selenium и может отличаться от staging.