Как настроить промежуточную среду в Google App Engine

Правильно настроив сервер разработки и производственный сервер, я хотел бы настроить среду разработки Google App Engine для тестирования новых разработанных версий в прямом эфире до их развертывания.

Я знаю два разных подхода:

A.. Первый вариант - это изменить параметр app.yaml версия..

version: app-staging

Что мне не нравится в этом подходе, так это то, что производственные данные загрязняются моими промежуточными тестами, потому что (исправьте меня, если я ошибаюсь):

Простая версия и производственная версия используют один и тот же хранилище данных
~~Простая версия и производственная версия имеют одни и те же журналы~~

_{Что касается первого момента, я не знаю, может ли он быть "исправлен" с использованием нового пространства имен python API.суб >}

B. Второй вариант заключается в изменении параметра app.yaml приложение

application: foonamestaging

при таком подходе я бы создал второе приложение, полностью независимое от версии Production.
Единственный недостаток, который я вижу, заключается в том, что я вынужден настроить второе приложение (администраторы настроены).
С помощью средства резервного копирования\восстановления, такого как Gaebar, это решение также хорошо работает.

Какой подход вы используете для настройки промежуточной среды для своего веб-приложения?
Кроме того, есть ли у вас автоматическая script, чтобы изменить yaml перед развертыванием?

Ответ 1

Я выбрал второй вариант в моей настройке, потому что это было самое быстрое решение, и я не делал никаких script для изменения параметра приложения при развертывании.

Но, как я вижу это сейчас, вариант A является более чистым решением. Вы можете с помощью пары строк кода переключать пространство имен хранилища данных на основе версии, которую вы можете получить динамически из переменной среды CURRENT_VERSION_ID, как описано здесь: http://code.google.com/appengine/docs/python/runtime.html#The_Environment

Ответ 2

Если требуется отдельный хранилище данных, вариант B выглядит для меня более чистым решением, потому что:

Вы можете сохранить версию для реальной версии производственных приложений.
Вы можете сохранить функцию версий для разделения трафика.
Вы можете сохранить функцию namespaces для многопользовательской аренды.
Вы можете легко копировать объекты из одного приложения в другое. Это не так просто между пространствами имен.
Несколько API по-прежнему не поддерживают пространства имен.
Для команд с несколькими разработчиками вы можете предоставить загрузку для разрешения на производство для одного человека.

Ответ 3

Мы пошли с вариантом B. И я думаю, что это лучше вообще, поскольку он полностью изолирует проекты. Так, например, игра с некоторыми конфигурациями на промежуточном сервере не повлияет и не ставит под угрозу безопасность или вызывает какой-либо другой эффект бабочки в вашей рабочей среде.

Что касается развертывания script, вы можете указать любое имя приложения в своем приложении .yaml. Некоторое имя dummy/dev и при развертывании просто используйте параметр -A:

appcfg.py -A your-app-name update .

Это значительно упростит развертывание script, не нужно заменять строку или что-либо подобное в вашем приложении app.yaml

Ответ 4

Мы используем опцию B.

В дополнение к предложениям Zygmantas о преимуществах разделения dev от prod на уровне приложений мы также используем наше приложение для тестирования производительности.

Обычно экземпляр dev работает без особого доступа к ресурсам, это помогает увидеть, где приложение "чувствует" медленное. Затем мы также можем независимо настраивать параметры производительности, чтобы увидеть, что имеет значение (например, внешний класс экземпляра).

Конечно, иногда нам нужно укусить пулю и настроить и смотреть вживую. Но приятно иметь другое приложение для игры.

По-прежнему используйте пространства имен и версии, просто dev грязный и экспериментальный.

Ответ 5

Я предпочитаю вариант A, и я пытаюсь настроить простую сборку script для автоматизации процесса