O Python 2 não é mais compatível com a comunidade. Recomendamos que você migre aplicativos do Python 2 para o Python 3.

Como migrar para o Cloud NDB

Locais do App Engine

Como o App Engine é regional, a infraestrutura de execução dos aplicativos está localizada em uma determinada região e é gerenciada pelo Google. Assim, ela fica disponível de modo redundante em todas as zonas dessa região.

Atender aos requisitos de latência, disponibilidade ou durabilidade são os principais fatores para selecionar a região de execução dos aplicativos. Geralmente, é possível selecionar a região mais próxima aos usuários do seu aplicativo, mas considere a localização dos outros produtos e serviços do Google Cloud usados pelo seu aplicativo. Usar serviços em vários locais pode afetar a latência do seu aplicativo, bem como preços.

O App Engine está disponível nas regiões a seguir:

  • northamerica-northeast1 (Montreal)
  • us-central (Iowa)
  • us-west2 (Los Angeles)
  • us-west3 (Salt Lake City)
  • us-west4 (Las Vegas)
  • us-east1 (Carolina do Sul)
  • us-east4 (Norte da Virgínia)
  • southamerica-east1 (São Paulo)
  • europe-west (Bélgica)
  • europe-west2 (Londres)
  • europe-west3 (Frankfurt)
  • europe-west6 (Zurique)
  • asia-northeast1 (Tóquio)
  • asia-northeast2 (Osaka)
  • asia-northeast3 (Seul)
  • asia-east2 (Hong Kong)
  • asia-south1 (Mumbai)
  • australia-southeast1 (Sydney)

Não é possível alterar a região de um aplicativo depois de defini-la.

Se você já criou um aplicativo do App Engine, é possível visualizar a região seguindo um destes procedimentos:

O Google Cloud NDB é uma biblioteca de cliente para Python que substitui o App Engine NDB. O App Engine NDB permite que os aplicativos Python 2 armazenem e consultem dados em bancos de dados do Datastore. O Cloud NDB permite que aplicativos Python 2 e Python 3 armazenem e consultem dados nos mesmos bancos de dados. No entanto, o produto que gerencia esses bancos de dados mudou do Datastore para o Cloud Firestore no modo Datastore.

Recomendamos que você migre para o Cloud NDB antes de fazer upgrade do aplicativo para o Python 3, já que o ambiente de execução do App Engine para Python 3 não é compatível com a biblioteca de cliente NDB do App Engine. Essa abordagem incremental da migração permite manter um aplicativo funcional e testável durante todo o processo de migração.

O Cloud NDB destina-se a substituir os recursos no NDB do App Engine. Portanto, ele não será compatível com novos recursos do Firestore no modo Datastore. Novos aplicativos Python 3 devem usar a biblioteca de cliente do modo Datastore em vez do Cloud NDB.

Para mais informações sobre o Cloud NDB, consulte as seguintes páginas no GitHub:

Principais diferenças entre o App Engine NDB e o Cloud NDB

Embora o Cloud NDB seja projetado para substituir o NDB do App Engine, há algumas diferenças importantes entre as duas bibliotecas:

  • O Cloud NDB não usa o serviço Memcache do App Engine para armazenar dados em cache.

    Em vez disso, o Cloud NDB pode armazenar dados em cache em um armazenamento de dados na memória do Redis gerenciado pelo Memorystore, Redis Labs ou outros sistemas. Embora apenas armazenamentos de dados do Redis sejam compatíveis atualmente, o Cloud NDB generalizou e definiu o armazenamento em cache na interface GlobalCache abstrata, que pode aceitar implementações concretas adicionais.

    O Memorystore para Redis não tem um nível gratuito. Veja Preços do Memorystore para mais detalhes.

  • As APIs NDB do App Engine que dependem de serviços específicos do ambiente de execução Python 2.7 do App Engine foram atualizadas ou removidas do Cloud NDB.

  • Os novos recursos do Python 3 e do Django eliminaram a necessidade de google.appengine.ext.ndb.django_middleware. Em vez disso, é possível escrever seu próprio middleware facilmente com apenas algumas linhas de código.

  • Os aplicativos necessários do NDB do App Engine e o banco de dados do Datastore devem estar no mesmo projeto do Google Cloud, com o Google App Engine fornecendo as credenciais automaticamente. O Cloud NDB pode acessar bancos de dados do modo Datastore em qualquer projeto, desde que você autentique o cliente corretamente. Isso é consistente com outras APIs do Google Cloud e bibliotecas de cliente.

A lista completa de diferenças está disponível nas notas de migração do projeto GitHub do Cloud NDB.

Antes de começar a migração

Como configurar o Memorystore para Redis

O Cloud NDB pode armazenar dados em cache em um armazenamento de dados na memória Redis gerenciado por Memorystore, Redis Labs ou outros sistemas. Neste guia, descrevemos como usar o Memorystore para Redis para armazenar dados em cache.

Para configurar o Memorystore para Redis:

  1. Crie uma instância do Redis no Memorystore.

    Quando solicitado a selecionar uma região para sua instância do Redis, selecione a mesma região em que o aplicativo do App Engine está localizado.

  2. Observe o endereço IP e o número da porta da instância do Redis criada. Você usará essas informações quando ativar o armazenamento em cache de dados para o Cloud NDB.

  3. Conecte o App Engine a uma rede VPC. Seu aplicativo só pode se comunicar com o Memorystore por meio de um conector VPC.

    Use o comando gcloud beta para implantar as atualizações do app. Somente o comando Beta pode atualizar seu app para usar um conector VPC.

Depois de concluir essas etapas, ative o cache de dados para o Cloud NDB.

Como entender as permissões do modo Datastore

Toda interação com um serviço do Google Cloud precisa ser autorizada. Por exemplo, para armazenar ou consultar dados em um banco de dados do modo Datastore, o aplicativo precisa fornecer as credenciais de uma conta que está autorizada a acessar o banco de dados.

Por padrão, o aplicativo fornece as credenciais da conta de serviço padrão do App Engine, que está autorizada a acessar bancos de dados no mesmo projeto que o aplicativo.

Você precisará usar uma técnica de autenticação alternativa que forneça credenciais explicitamente se alguma das seguintes condições for verdadeira:

  • Seu aplicativo e o banco de dados do modo Datastore estão em projetos diferentes do Google Cloud.

  • Você alterou os papéis atribuídos à conta de serviço padrão do App Engine.

Para saber mais sobre técnicas de autenticação alternativas, veja Como configurar a autenticação para aplicativos de produção de servidor para servidor.

Visão geral do processo de migração

Para migrar para o Cloud NDB:

  1. Atualize seu aplicativo Python:

    1. Instale a biblioteca de cliente do Cloud NDB.

    2. Atualize as instruções de importação para importar módulos do Cloud NDB.

    3. Adicione um código que crie um cliente do Cloud NDB. O cliente pode ler as variáveis de ambiente do aplicativo e usar os dados para autenticar com o modo Datastore.

    4. Adicione o código que usa o contexto do ambiente de execução do cliente para manter o cache e as transações separados entre as linhas de execução.

    5. Remova ou atualize o código que usa métodos e propriedades que não são mais suportados.

  2. Teste as atualizações.

  3. Implante o aplicativo no App Engine.

    Como acontece com qualquer alteração feita no seu app, considere usar a divisão de tráfego para aumentar o tráfego lentamente. Monitore de perto o aplicativo em busca de problemas no banco de dados antes de direcionar mais tráfego para o aplicativo atualizado.

Como atualizar seu aplicativo Python

Como instalar a biblioteca do Cloud NDB para aplicativos Python 2

  1. Crie um diretório para armazenar bibliotecas de terceiros, como lib/.

  2. Crie um arquivo requirements.txt na mesma pasta que o arquivo app.yaml e adicione o nome de uma biblioteca cliente junto com a biblioteca googleapis_common_protos:

    googleapis_common_protos
    google-cloud-ndb
    

    Os aplicativos Python 2 exigem googleapis_common_protos para acessar os serviços do Google Cloud, como o Cloud Firestore no modo Datastore.

  3. Use pip (versão 6 ou posterior) com a sinalização -t <directory> para instalar as bibliotecas na pasta criada na etapa anterior. Exemplo:

    pip install -t lib -r requirements.txt
    
  4. Especifique a biblioteca RPC na seção libraries do arquivo app.yaml:

    libraries:
    - name: grpcio
      version: 1.0.0
    
  5. Crie um arquivo appengine_config.py na mesma pasta que seu app.yaml arquivo, se você ainda não tiver um. Adicione a instrução a seguir ao seu arquivo appengine_config.py:

    # appengine_config.py
    import pkg_resources
    from google.appengine.ext import vendor
    
    # Set path to your libraries folder.
    path = 'lib'
    # Add libraries installed in the path folder.
    vendor.add(path)
    # Add libraries to pkg_resources working set to find the distribution.
    pkg_resources.working_set.add_entry(path)
    

    Use o módulo pkg_resources, que garante que o aplicativo use a distribuição correta das bibliotecas de cliente.

    O arquivo appengine_config.py no exemplo anterior supõe que a pasta lib está localizada no diretório de trabalho atual. Se não for possível garantir que lib estará sempre no diretório de trabalho atual, especifique o caminho completo para a pasta lib. Exemplo:

    import os
    path = os.path.join(os.path.dirname(os.path.realpath(__file__)), 'lib')
    

Quando você implanta o aplicativo, o App Engine faz o upload de todas as bibliotecas no diretório especificado no arquivo appengine_config.py.

Como instalar a biblioteca do Cloud NDB para aplicativos Python 3

O ambiente de execução do Python 3 do App Engine usa o arquivo requirements.txt de um aplicativo para determinar quais pacotes e versões instalar para os aplicativos. Para instalar a biblioteca do Cloud NDB no ambiente de execução do Python 3, adicione a seguinte linha ao arquivo requirements.txt do seu aplicativo:

google-cloud-ndb

O App Engine faz o upload automaticamente de todas as bibliotecas no arquivo requirements.txt do aplicativo quando você implanta o aplicativo.

Como instalar dependências localmente

Ao desenvolver e testar seu aplicativo localmente, recomendamos que você use um ambiente virtual para isolar as dependências do seu aplicativo dos pacotes do sistema. Isso garante que o aplicativo carregue apenas as dependências declaradas no arquivo requirements.txt do app e sincronize as versões de dependência entre os ambientes local e de produção.

No Python 2, é possível usar o virtualenv para criar um ambiente virtual.

No Python 3, o venv é a maneira recomendada de criar um ambiente virtual.

Como atualizar declarações de importação

O local do módulo NDB foi movido para google.cloud.ndb. Atualize as instruções de importação do aplicativo, conforme mostrado na tabela a seguir:

Remover Substitua por
from google.appengine.ext import ndb from google.cloud import ndb

Como criar um cliente do Cloud NDB

Assim como acontece com outras bibliotecas de cliente baseadas nas APIs do Google Cloud, a primeira etapa para usar o Cloud NDB é criar um objeto Client. O cliente contém credenciais e outros dados necessários para se conectar ao modo Datastore. Exemplo:

from google.cloud import ndb

client = ndb.Client()

No cenário de autorização padrão descrito anteriormente, o cliente Cloud NDB contém credenciais da conta de serviço padrão do App Engine, que está autorizada a interagir com o modo Datastore. Se você não estiver trabalhando nesse cenário padrão, consulte Application Default Credentials (ADC) para informações sobre como fornecer credenciais.

Como usar o contexto de ambiente de execução do cliente

Além de fornecer as credenciais necessárias para interagir com o modo Datastore, o cliente do Cloud NDB contém o método context(), que retorna um contexto de ambiente de execução. O contexto do ambiente de execução isola as solicitações de cache e transação de outras interações simultâneas do modo Datastore.

Todas as interações com o modo Datastore precisam ocorrer em um contexto de ambiente de execução do NDB. Como a criação de uma definição de modelo não interage com o Datastore, defina sua classe de modelo antes de criar um cliente do Cloud NDB e recuperar um contexto de ambiente de execução, e depois use o contexto de ambiente de execução no manipulador de solicitação para obter dados do banco de dados.

Exemplo:

from google.cloud import ndb

class Book(ndb.Model):
    title = ndb.StringProperty()

client = ndb.Client()

def list_books():
    with client.context():
        books = Book.query()
        for book in books:
            print(book.to_dict())

Aplicativos em várias conversas

O contexto do ambiente de execução que o cliente do Cloud NDB retorna apenas se aplica a uma única linha de execução. Se o aplicativo usar várias linhas de execução para uma única solicitação, você precisará recuperar um contexto de ambiente de execução separado para cada linha de execução que usará a biblioteca do Cloud NDB.

Como usar um contexto de ambiente de execução com frameworks WSGI

Se o aplicativo da Web usa um framework WSGI, é possível criar automaticamente um novo contexto de ambiente de execução para cada solicitação criando um objeto de middleware que recupera o contexto de ambiente de execução e, em seguida, unindo o aplicativo no objeto de middleware.

No exemplo a seguir de uso de middleware com Flask:

  • O método middleware cria um objeto de middleware WSGI no contexto do ambiente de execução do cliente NDB.

  • O aplicativo Flask é encapsulado no objeto de middleware.

  • O Flask transmitirá cada solicitação pelo objeto de middleware, que recupera um novo contexto de ambiente de execução do NDB para cada solicitação.

from flask import Flask

from google.cloud import ndb

client = ndb.Client()

def ndb_wsgi_middleware(wsgi_app):
    def middleware(environ, start_response):
        with client.context():
            return wsgi_app(environ, start_response)

    return middleware

app = Flask(__name__)
app.wsgi_app = ndb_wsgi_middleware(app.wsgi_app)  # Wrap the app in middleware.

class Book(ndb.Model):
    title = ndb.StringProperty()

@app.route('/')
def list_books():
    books = Book.query()
    return str([book.to_dict() for book in books])

Como usar um contexto de ambiente de execução com o Django

O middleware do Django fornecido pela biblioteca NDB do App Engine não é compatível com a biblioteca do Cloud NDB. Se você usou esse middleware (google.appengine.ext.ndb.django_middleware) no aplicativo, siga estas etapas para atualizá-lo:

  1. Use o sistema de middleware do Django para criar um novo contexto de ambiente de execução para cada solicitação.

    No exemplo a seguir:

    • O método ndb_django_middleware cria um cliente do Cloud NDB.

    • O método middleware cria um objeto de middleware dentro do contexto do ambiente de execução do cliente NDB.

    from google.cloud import ndb
    
    # Once this middleware is activated in Django settings, NDB calls inside Django
    # views will be executed in context, with a separate context for each request.
    def ndb_django_middleware(get_response):
        client = ndb.Client()
    
        def middleware(request):
            with client.context():
                return get_response(request)
    
        return middleware
  2. No arquivo settings.py do Django, atualize a configuração MIDDLEWARE para que ela liste o novo middleware criado em vez de google.appengine.ext.ndb.NdbDjangoMiddleware.

O Django transmitirá cada solicitação pelo objeto de middleware que você listou na configuração MIDDLEWARE e esse objeto recuperará um novo contexto de ambiente de execução do NDB para cada solicitação.

Como ativar o armazenamento em cache de dados

O Cloud NDB pode armazenar dados em cache em um armazenamento de dados na memória Redis gerenciado por Memorystore, Redis Labs ou outros sistemas. Neste guia, descrevemos como usar o Memorystore para Redis para armazenar dados em cache.

Depois de configurar o Memorystore para Redis, siga estas etapas:

  1. Adicione o URL de conexão do Redis ao seu aplicativo.

  2. Crie um objeto RedisCache.

Como adicionar o URL de conexão do Redis

Conecte-se ao cache do Redis adicionando a variável de ambiente REDIS_CACHE_URL ao arquivo app.yaml do app. O valor de REDIS_CACHE_URL tem o seguinte formato:

redis://IP address for your instance:port

Por exemplo, é possível adicionar as seguintes linhas ao arquivo app.yaml do app:

     env_variables:
      REDIS_CACHE_URL: redis://10.0.0.3:6379

Como criar e usar um objeto de cache do Redis

Se você definiu REDIS_CACHE_URL como uma variável de ambiente, é possível criar um objeto RedisCache com uma única linha de código e, em seguida, usar o cache transmitindo-o para Client.context() ao configurar o contexto do ambiente de execução:

client = ndb.Client()
global_cache = ndb.RedisCache.from_environment()

with client.context(global_cache=global_cache):
  books = Book.query()
  for book in books:
      print(book.to_dict())

Se você não definir REDIS_CACHE_URL como uma variável de ambiente, você precisará construir um cliente Redis e passar o cliente para o ndb.RedisCache() construtor. Exemplo:

global_cache = ndb.RedisCache(redis.StrictRedis(host=IP-address, port=redis_port))

Observe que você não precisa declarar uma dependência na biblioteca de cliente do Redis, porque a biblioteca do Cloud NDB já depende da biblioteca de cliente do Redis.

Consulte o aplicativo de amostra do Memorystore para ver um exemplo de como construir um cliente Redis.

Como atualizar o código para APIs NDB removidas ou alteradas

As APIs NDB que dependem de APIs e serviços específicos do App Engine foram atualizadas ou removidas da biblioteca do Cloud NDB.

Você precisará atualizar seu código se ele usar qualquer uma das seguintes APIs NDB:

Modelos e propriedades do modelo

Os métodos a seguir de google.appengine.ext.ndb.Model não estão disponíveis na biblioteca do Cloud NDB porque usam APIs específicas do App Engine que não estão mais disponíveis.

API removida Substituição
Model.get_indexes e
Model.get_indexes_async
None
Model._deserialize e
Model._serialize
None
Model.make_connection None

A tabela a seguir descreve as propriedades google.appengine.ext.ndb.Model específicas que foram alteradas na biblioteca do Cloud NDB:

Property Change
TextProperty google.cloud.ndb.TextProperty não pode ser indexado. Se você tentar definir google.cloud.ndb.TextProperty.indexed, um NotImplementedError será gerado.
StringProperty StringProperty é sempre indexado. Se você tentar definir google.cloud.ndb.StringProperty.indexed, um NotImplementedError será gerado.
Todas as propriedades com argumentos name ou kind no construtor. name ou kind precisa ser do tipo de dados str, já que unicode foi substituído por str no Python 3.

As classes e métodos na tabela a seguir não estão mais disponíveis porque usam recursos específicos do App Engine que não estão mais disponíveis.

API removida Substituição
google.appengine.ext.ndb.msgprop.MessageProperty e
google.appengine.ext.ndb.msgprop.EnumProperty
None

Se você tentar criar esses objetos, um NotImplementedError será gerado.

de google.appengine.ext.ndb.model.Property:
_db_get_value
_db_set_value
_db_set_compressed_meaning
_db_set_uncompressed_meaning
__creation_counter_global
None

Esses métodos dependem de buffers de protocolo do modo Datastore que foram alterados.

Model.make_connection None

Keys

Os métodos a seguir de google.appengine.ext.ndb.Key não estão disponíveis na biblioteca do Cloud NDB. Esses métodos foram usados para transmitir chaves para e da API Datastore DB, que não é mais compatível (DB foi o predecessor do NDB do App Engine).

API removida Substituição
Key.from_old_key e
Key.to_old_key
None

Além disso, observe as seguintes alterações:

NDB do App Engine Cloud NDB
Os tipos e os IDs de string devem ter menos de 500 bytes Os tipos e os IDs de string devem ter menos de 1.500 bytes.
Key.app() retorna o ID do projeto especificado quando você criou a chave. O valor retornado por google.cloud.ndb.Key.app() pode ser diferente do ID original transmitido para o construtor. Isso ocorre porque os IDs de aplicativos com prefixo, como s~example, são identificadores legados do App Engine. Eles foram substituídos por IDs de projeto equivalentes, como example.

Consultas

Como o NDB do App Engine, o Cloud NDB fornece uma classe QueryOptions (google.cloud.ndb.query.QueryOptions) que permite reutilizar um conjunto específico de opções de consulta em vez de redefini-las para cada consulta. No entanto, QueryOptions no Cloud NDB não herda de google.appengine.datastore.datastore_rpc.Configuration e, portanto, não é compatível com métodos ...datastore_rpc.Configuration.

Além disso, google.appengine.datastore.datastore_query.Order foi substituído por google.cloud.ndb.query.PropertyOrder. Semelhante a Order, a classe PropertyOrder permite que você especifique a ordem de classificação em várias consultas. O construtor PropertyOrder é igual ao construtor de Order. Somente o nome da classe foi alterado.

API removida Substituição
de google.appengine.datastore.datastore_rpc.Configuration:
deadline(value)
on_completion(value)
read_policy(value)
force_writes(value)
max_entity_groups_per_rpc(value)
max_allocate_ids_keys(value)
max_rpc_bytes(value)
max_get_keys(value)
max_put_entities(value)
max_delete_keys(value)

Consulte o código-fonte para ver uma descrição desses métodos.

None
google.appengine.ext.ndb.Order
Por exemplo:
order=Order(-Account.birthday, Account.name)
google.cloud.ndb.PropertyOrder
Por exemplo:
google.cloud.ndb.PropertyOrder(-Account.birthday, Account.name)

Utils

O módulo ndb.utils (google.appengine.ext.ndb.utils) não está mais disponível. A maioria dos métodos nesse módulo era interna ao NDB do App Engine. Alguns métodos foram descartados devido a diferenças de implementação no novo ndb, enquanto outros métodos se tornaram obsoletos pelos novos recursos do Python 3.

Por exemplo, o decorador posicional no antigo módulo utils declarava que apenas os primeiros n argumentos de uma função ou método podem ser posicionais. No entanto, o Python 3 pode fazer isso usando argumentos somente de palavra-chave. O que costumava ser escrito como:

@utils.positional(2)
def function1(arg1, arg2, arg3=None, arg4=None)
  pass

Pode ser escrito assim no Python 3:

def function1(arg1, arg2, *, arg3=None, arg4=None)
  pass

Namespaces

Os namespaces permitem que um aplicativo multilocatário use silos de dados separados para cada locatário enquanto ainda usa o mesmo banco de dados do modo Datastore. Ou seja, cada locatário armazena dados em seu próprio namespace.

Em vez de usar o google.appengine.api.namespacemanager específico do App Engine, especifique um namespace padrão ao criar um cliente do Cloud NDB e use o namespace padrão chamando os métodos do Cloud NDB no contexto do ambiente de execução do cliente. Isso segue o mesmo padrão de outras APIs do Google Cloud compatíveis com namespaces.

API removida Substituição
google.appengine.api.namespacemanager.setnamespace(str) e
google.appengine.api.namespacemanager.getnamespace()

client=google.cloud.ndb.Client(namespace="my namespace")

with client.context() as context:
key = ndb.Key("SomeKind", "SomeId")
       
,

key-non-default-namespace=ndb.Key("SomeKind," "AnotherId",
namespace="non-default-nspace")
Todos os outros métodos google.appengine.api.namespacemanager None

Tasklets

Tasklets agora podem usar uma instrução return padrão para retornar um resultado em vez de aumentar uma exceção Return. Exemplo:

Biblioteca NDB do App Engine Biblioteca do Cloud NDB

        @ndb.tasklet
        def get_cart():
          cart = yield
        CartItem.query().fetch_async()
          raise Return(cart)
       

        @ndb.tasklet
        def get_cart():
          cart = yield
        CartItem.query().fetch_async()
          return cart
        

Observe que ainda é possível retornar resultados no Cloud NDB gerando uma exceção Return, mas isso não é recomendado.

Além disso, os seguintes métodos e subclasses Tasklets não estão mais disponíveis, principalmente devido a alterações na forma como um contexto do NDB é criado e usado na biblioteca do Cloud NDB.

API removida Substituição
de google.appengine.api.ext.ndb.tasklets:
add_flow_exception
make_context
make_default_context
set_context
None
de google.appengine.api.ext.ndb.tasklets:
QueueFuture
ReducedFuture
SerialQueueFuture
None

Exceções

Embora o módulo google.cloud.ndb.exceptions na biblioteca do Cloud NDB contenha muitas das mesmas exceções da biblioteca NDB do App Engine, nem todas as exceções antigas estão disponíveis na nova biblioteca. A tabela a seguir lista as exceções que não estão mais disponíveis:

API removida Substituição
de google.appengine.api.datastore_errors:
BadKeyError
BadPropertyError
CommittedButStillApplying
EntityNotFoundError
InternalError
NeedIndexError
QueryNotFoundError
ReferencePropertyResolveError
Timeout
TransactionFailedError
TransactionNotFoundError
google.cloud.ndb.exceptions

Como testar suas atualizações

Para configurar um banco de dados de teste e executar seu aplicativo localmente antes de implantá-lo no App Engine:

  1. Execute o emulador local no modo Datastore para armazenar e recuperar dados.

    Siga as instruções para definir variáveis de ambiente para que o aplicativo se conecte ao emulador em vez do ambiente de produção do modo Datastore.

    Você também pode importar dados para o emulador se quiser iniciar o teste com dados pré-carregados no banco de dados.

  2. Use o servidor de desenvolvimento local para executar o aplicativo.

    Para garantir que a variável de ambiente GOOGLE_CLOUD_PROJECT esteja definida corretamente durante o desenvolvimento local, inicialize dev_appserver usando o seguinte parâmetro:

    --application=PROJECT_ID

    PROJECT_ID precisa ser o ID do projeto do Google Cloud. Para encontrar o ID do projeto, execute o comando gcloud config list project ou consulte a página do projeto no Console do Google Cloud.

Implantar o app

Quando seu aplicativo estiver em execução no servidor de desenvolvimento local sem erros:

  1. Teste o aplicativo no App Engine.

  2. Se o aplicativo for executado sem erros, use a divisão de tráfego para aumentar gradualmente o tráfego de o aplicativo atualizado. Monitore de perto o aplicativo em busca de problemas no banco de dados antes de direcionar mais tráfego para o aplicativo atualizado.