предыдущие части:
Google Cloud Endpoints на Java: Руководство. ч. 1
Google Cloud Endpoints на Java: Руководство. ч. 2 (Frontend)

Работа с версиями

Google App Engine предоставляет возможность загрузить до 10 различных версий приложения.
Одна из них (по умолчанию — первая загруженная) является основной (default) и доступна по основному адресу приложения, и соответственно по адресу собственного домена(ов).

Остальные доступны по адресу вида {версия}-dot-{проект ID}.appspot.com
Версии называть можно как угодно, это не обязательно должно быть 1-dot-{проект ID}.appspot.com, можно применять более сложные обозначения, что в частности делает адрес сырой версии труднодоступным для широкой аудитории
Но, естественно, поскольку имя версии становиться частью веб-адреса, то там не должно быть точки или символов недопустимых в веб-адресах.

Для A/B тестирования, можно включить traffic splitting и перенаправлять определенный процент посетителей на версию отличную от версии по умолчанию.

Управление версиями доступно в меню разработчика: Compute -> App Engine -> Versions:

В приложении мы указываем версии в двух местах в /src/main/webapp/WEB-INF/appengine-web.xml:

<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
    <application>{проект ID}</application>
    <version>{наименование версии}</version>

— это собственно версия приложения в GAE,

и в pom.xml:

    <modelVersion>4.0.0</modelVersion>
    <packaging>war</packaging>
    <version>{версия}</version>

— это будет часть названия .war-файла: target/{проект ID}-{версия}.war

Собственно обозначения версии в appengine-web.xml и pom.xml технически не связаны и могут быть совершенно разными, но с точки зрения поддержания порядка логично чтобы они совпадали.

Команда mvn appengine:update размещает обновления в версию с именем '1' независимо от версии .war файла и значения версии указанного в /src/main/webapp/WEB-INF/appengine-web.xml

Поэтому для работы с разными версиями приложения нам потребуется Google App Engine SDK. На момент написания данной статьи последняя версия 1.9.28. Скачиваем на: cloud.google.com/appengine/downloads#Google_App_Engine_SDK_for_Java и разархивируем в директорию по выбору, и, для удобства, прописываем в PATH, например:

mkdir ~/GAE-SDK # any path you like
cd $_
wget https://storage.googleapis.com/appengine-sdks/featured/appengine-java-sdk-1.9.28.zip
unzip appengine-java-sdk-1.9.28.zip
cd appengine-java-sdk-1.9.28/bin
echo 'export PATH=$PATH:'$(pwd) >> ~/.bashrc # adds current dir to PATH
source ~/.bashrc
cd

Для деплоя используется утилита appcfg.sh, в директории проекта, запускаем команды:

mvn clean install
appcfg.sh update ./target/{проект ID}{номер версии} --noisy

Утилита производит аутентификацию пользователя через браyзер, и сохраняет токены в ~/.appcfg_oauth2_tokens_java
В качестве параметров указываем путь к директории, которая создана командой mvn install ( ./target/{проект ID}{номер версии} ) и в которой располагается WEB-INF, где в свою очередь находиться appengine-web.xml, и проект будет загружен на сервер в версию наименование которой указанно в appengine-web.xml

Ну и при смене версий надо не забывать обозначать смену версий в комментариях коммитов git.

(UPD: Google App Engine SDK 1.9.30 с Maven 3.3.3 — с версиями уже работает корректно)

Скачивание файлов проекта с сервера

С помощью утилиты также можно скачать файлы проекта с сервера. Это делается командой вида:
appcfg.sh -A {проект ID} -V {имя версии} download_app {директория для скачивания}
например:

appcfg.sh -A hello-habrahabr-api -V '1' download_app temp_hello-habrahabr-api.1

Скачанный проект будет выглядеть примерно так:

или так:

Т.е. это результат развертывания .war на сервере но не сам .war и не исходный код.

Скачивание логов с сервера

Логи могут быть скачаны с сервера на локальную машину с помощью той же утилиты в формате простого текстового файла командой вида:

appcfg.sh -A {проект ID, можно упускать — используется из appengine-web.xml} -V {имя версии} --num_days={количество дней, по умолчанию: 1, доступно до 90} --severity={уровень 0 (DEBUG) дo 4 (CRITICAL), если этот параметр пропущен, скачиваются только логи запросов} request_logs src/main/webapp/ {файл для сохранения информации)

Можно также указать опции:
--append (добавить к существующему файлу)
--include_all (включить все содержимое log messages)
--noisy (выводить больше информации о работе утилиты)

Например:

appcfg.sh -A 'hello-habrahabr-api' -V '1' --num_days=90 --noisy request_logs src/main/webapp/ ../$(date '+%Y-%m-%d').LOGS.txt

Google Cloud Shell

Еще одной интересной функцией консоли разработчика является Google Cloud Shell.

По клику на пиктограмму изображающую терминал в верхней панели в нижней части страницы запускается консоль, и мы получаем доступ в виртуальную машину Debian-based Linux с предустановленными инструментами необходимыми для работы с облачными сервисами Google, в частности: стандартные утилиты Debian-based Linux, в т.ч. apt-get, wget и др.; Java 7; Maven 3.2; Git; Python 2.7 и pip; Node.js и npm; Google Cloud SDK; Google App Engine SDK; Vim, Nano, Emacs.

Пользователю выделяется 5GB постоянного места на диске, но сохраняется между перезапусками только домашняя директория пользователя. То есть программы, файлы, и настройки в домашней директории будут доступны при каждом новом входе. Можно устанавливать программы с помощью но apt-get — но только на один сеанс.
Доступна также функция Web preview: можно запустить веб сервер (например python -m SimpleHTTPServer) с портом в диапазоне от 8080 до 8084, и открыть его в отдельном окне/вкладке браузера кнопкой «web preview» (доступен только данному пользователю)

Так выглядит Cloud Shell. Стрелками обозначены кнопки запуска консоли и Web preview.

UPD:
Продолжение:

Работа с базой данных в Google App Engine/Google Cloud Endpoints на Java: фреймворк Objectify

Google Cloud Storage c Java: изображения и другие файлы в облаках

Google Cloud Endpoints на Java: Руководство. ч. 3