Testing and Deploying your Application

Region ID

The REGION_ID is a code that Google assigns based on the region you select when you create your app. Including REGION_ID.r in App Engine URLs is optional for existing apps and will soon be required for all new apps.

To ensure a smooth transition, we are slowly updating App Engine to use region IDs. If we haven't updated your Google Cloud project yet, you won't see a region ID for your app. Since the ID is optional for existing apps, you don't need to update URLs or make other changes once the region ID is available for your existing apps.

Learn more about region IDs.

Learn how to run your application locally, deploy it, and test on App Engine.

Running locally

To test your application's functionality before deploying, run your application in your local environment with the development tools that you usually use.

Before deploying your application

Before you can deploy your application:

Deploying your application

We recommend using the App Engine Maven plugin to build and deploy your application as described in Using Apache Maven and the App Engine Plugin. For example, after you set up the App Engine Maven plugin, you can enter the following command from the directory that contains your project's pom.xml file:

mvn package appengine:deploy -Dapp.deploy.projectId=PROJECT_ID

Replace PROJECT_ID with the ID of your Cloud project. If your pom.xml file already specifies your project ID, you don't need to include the -Dapp.deploy.projectId property in the command you run.

Alternative deployment options

You can use the gcloud command line tool to deploy your application by packaging your application into an executable JAR package. To create the JAR package, run the following Maven command from the directory that contains your project's pom.xml file:

    mvn package

Then, do one of the following depending on whether you've created an app.yaml file for your application:

  • If you created an app.yaml file:

    1. Copy the file into the same directory as the executable JAR file you created.

    2. From the directory that contains the app.yaml and your JAR, enter the following command:

      gcloud app deploy
  • If you haven't created an app.yaml file, enter the following command:

    gcloud app deploy your-executable.jar

    gcloud app deploy will create an app.yaml file that contains the minimum settings, using all default values.

To programmatically deploy your apps, use the Admin API.

What happens when you deploy

By default, the appengine:deploy goal generates a unique ID for the version that you deploy, deploys the version to the Google Cloud project you configured the gcloud tool to use, and routes all traffic to the new version.

Changing the deployment defaults

You can change the default deployment behavior by passing parameters in the appengine:deploy command. For example, you can:

  • Deploy the other configuration files of your service, such as cron.yaml, dispatch.yaml, and index.yaml files.
  • Specify a custom version ID.
  • Prevent traffic from being automatically routed to the new version.
  • Deploy to a specific Google Cloud project.

For example, to deploy the service defined in your pom.xml file to a specific Google Cloud project, assign it a custom version ID, and prevent traffic from being routed to the new version:

mvn appengine:deploy -Dapp.deploy.projectId=PROJECT_ID -Dapp.deploy.version=VERSION_ID -Dapp.deploy.promote=False

For information about these and other parameters, see the appengine:deploy reference.

If you use gcloud app deploy to deploy instead of the App Engine plugin, see the gcloud app deploy reference for information on changing default deployment behavior.

Ignoring files

You can use a .gcloudignore file to specify files and directories that will not be uploaded to App Engine when you deploy your services. This is useful for ignoring build artifacts and other files that do not need to be uploaded with your deployment.

Managing build images

Each time you deploy a new version, a container image is created using the Cloud Build service. That container image then runs in the App Engine standard environment.

Built container images are stored in the app-engine folder in Container Registry. You can download these images to keep or run elsewhere. Once deployment is complete, App Engine no longer needs the container images. Note that they are not automatically deleted, so to avoid reaching your storage quota, you can safely delete any images you don't need. For more information about managing images in Container Registry, see the Container Registry documentation.

Viewing your application

After you deploy your application to App Engine, you can run the following command to launch your browser and view it at https://PROJECT_ID.REGION_ID.r.appspot.com:

gcloud app browse

Testing on App Engine before shifting traffic

Before configuring a new version to receive traffic, you can test it on App Engine. For example, to test a new version of your default service:

  1. Deploy your new version, but prevent traffic from being automatically routed to the new version:

    mvn appengine:deploy -Dapp.deploy.projectId=PROJECT_ID -Dapp.deploy.promote=False

  2. Access your new version by navigating to the following URL:

    https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com

    Now you can test your new version in the App Engine runtime environment. You can debug your application by viewing its logs. For more information, see Writing Application Logs.

    Requests sent to https://PROJECT_ID.REGION_ID.r.appspot.com are be routed to the version previously configured to receive traffic.

  3. When you want to send traffic to the new version, use the Cloud Console to migrate traffic:

    Manage versions

    Select the version you just deployed and click Migrate traffic.

You can use the same process to test new versions of other services by replacing default in the URL with your service's name:

https://VERSION_ID-dot-SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com

For more information about targeting specific services and versions, see How Requests are Routed.