Производственные среды Google App Engine

Было бы неплохо, если бы после тестирования нового кода я мог опубликовать изменения либо в конкретном субдомене моего приложения GAE (например, demo.my-gae-app.com вместо моей рабочей среды в my-gae-app.com), либо в конкретном экземпляре бэкэнда (если субдомены запрещены или не разрешены). правильное решение здесь).

Затем я могу продемонстрировать новые изменения кода своим бета-тестерам и запустить тесты производительности в реальной среде GAE. Я знаю, что GAE SDK поставляется с сервером приложений для разработчиков, но он заглушает большинство вызовов API и вообще не обрабатывает масштабирование, как в производственной среде. И хотя мы обязательно будем использовать его для локальных песочниц разработчиков, а также для нашей среды контроля качества, я просто не считаю нужным выпускать код в рабочую среду, которая не работала в среде, которая действительно имитирует производственную среду.

Как с этим справляются другие разработчики/команды GAE? Я действительно просто хочу иметь предварительную среду (например, «Демо») ... но на самом деле на живых серверах приложений GAE. Конечно, мне нужно ограничить доступ к этому коду, чтобы только я, мои разработчики, мои бета-тестеры и наши автоматизированные тесты производительности могли получить к нему доступ... (вот в чем фишка).


person IAmYourFaja    schedule 08.09.2012    source источник


Ответы (2)


Вы можете развернуть свой код в версии приложения, отличной от версии по умолчанию, одним из следующих способов:

  • изменение значения тега version в appengine-web.xml
  • вызов appcfg.sh с аргументом -V version
  • изменение версии в параметрах развертывания плагина Google Eclipse

После этого вы можете получить доступ к своему приложению, посетив version.appid.appspot.com

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

person proppy    schedule 09.09.2012
comment
Спасибо @proppy (+1) - быстрый вопрос: мое понимание заключалось в том, что серверные экземпляры являются отдельными заданными поддоменами, поэтому на них можно ссылаться напрямую. Таким образом, у myapp.appid.appspot.com может быть серверный экземпляр, cronjobs.myapp.appid.appspot.com который запускает задания cron в течение дня. Как бы это помешало demo.myapp.appid.adppspot.com, если бы я использовал аргумент -V demo, как вы здесь предлагаете? Очевидно, что мне нужен обычный производственный бэкэнд cronjob, но мне также нужен демонстрационный бэкенд cronjob. Еще раз спасибо! - person IAmYourFaja; 11.09.2012
comment
Бэкэнды не имеют версии, фактически каждый бэкэнд действует как отдельная версия приложения. Я бы предложил создать серверную часть с именем cronjobs-demo. - person proppy; 11.09.2012

Я зарегистрировал новое приложение в движке приложений Google и развернул в нем бета-версию, изменив настройки проекта в eclipse. Затем с помощью инструментов Google (см. документ Google) я скопировал содержимое производственного хранилища данных в новое бета-приложение.

  • хранилище данных в режиме только для чтения при извлечении данных
  • Ключи сущностей могут быть проблематичными при работе с бесхозными отношениями - есть ли у кого-нибудь информация об этом?

Это дает мне идеальную среду для бета-тестирования.

person Gaël Oberson    schedule 10.09.2012