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

Question

После правильно настроил развитие сервера и сервера в Production, я хотел бы создать Staging среды на Google App Engine полезно для тестирования новых развитых версий до развертывания их до производства.

Я знаю, что два различных подхода:

А. Первый вариант является модификацией app.yamlверсии параметр.

version: app-staging 

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

1. Балетмейстер версии и версия производства разделяет же Datastore
2. версия Постановка и версия производства одни и те же журналы

_{что касается т он первый раз, я не знаю, может ли он быть «исправлен» с использованием нового namespaces python API.}

B. Второй вариант путем изменения параметра

application: foonamestaging 

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

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

Answer 1

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

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

Answer 2

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

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

Answer 3

Мы используем вариант Б.

В дополнении к Zygmantas предложений о пользе разделения Дев от прода на уровне приложений, мы также используем наше Dev приложение для тестирования производительности.

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

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

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

Answer 4

Я предпочитаю вариант А, и я пытаюсь создать simple build script для automatise обрабатывать

Answer 5

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

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

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

Это упростит вашу Deploy сценарий довольно много, нет необходимости в строке не заменить или что-нибудь подобное в вашем app.yaml