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.

Python |Java |Node.js |Go |Ruby |PHP |.NET

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.

Deploying your application

Deploy your application to App Engine using the gcloud app deploy command. This command automatically builds a container image by using the Cloud Build service and then deploys that image to the App Engine flexible environment. The container will include any local modifications that you've made to the runtime image.

To programmatically deploy your apps, use the Admin API.

Before you begin

Before you can deploy your application:

The Owner of the Cloud project must enable App Engine.
Ensure that your user account includes the required privileges.

Deploying a service

You deploy your application to App Engine by deploying versions of your application's services and each of their configuration files.

To deploy a version of your application's service, run the following command:

gcloud app deploy .\bin\Debug\netcoreapp2.1\publish\app.yaml

By default the deploy command automatically generates a new version ID each time that you use it and will route any traffic to the new version.

To override this behavior, you can specify the version ID with the version flag:

gcloud app deploy .\bin\Debug\netcoreapp2.1\publish\app.yaml --version myID

You can also specify not to send all traffic to the new version immediately with the --no-promote flag:

gcloud app deploy .\bin\Debug\netcoreapp2.1\publish\app.yaml --no-promote

Ignoring files

You can use a .gcloudignore file to specify files and directories not to upload to Google Cloud 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.

Learn more about the syntax of the .gcloudignore file in the gcloud reference.

Manually building a container for deployment

To build your container images outside of Google Cloud Platform, you must first upload your images to a container image repository before you can deploy your images to App Engine with the gcloud app deploy command.

For example, if you build your container images locally with Docker, you can push those images to Google Container Registry and then specify the URL of your image in the --image-url flag of the command:

gcloud app deploy .\bin\Debug\netcoreapp2.1\publish\app.yaml --image-url gcr.io/YOUR_PROJECT_ID/YOUR_CONTAINER_IMAGE

Using automated continuous deployment pipelines

You can use Cloud Build to automate deployments in continuous deployment pipelines. For more information, see Deploying artifacts, and Automating Builds using Build Triggers in the Cloud Build documentation.

Docker base images for .NET

If you'd like to build a .NET custom runtime application from scratch, use a provided base image in your Dockerfile:

Runtime	Docker command
.NET	`FROM gcr.io/google-appengine/aspnetcore:1.0.11`
.NET	`FROM gcr.io/google-appengine/aspnetcore:1.1.8`
.NET	`FROM gcr.io/google-appengine/aspnetcore:2.0.7`
.NET	`FROM gcr.io/google-appengine/aspnetcore:2.1.0`

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 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:

Deploy your new version and include the --no-promote flag:

gcloud app deploy .\bin\Debug\netcoreapp2.1\publish\app.yaml --no-promote

Access your new version by navigating to the following URL:

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

Note: You can find the version ID in the Cloud Console, or specify one when you deploy with the --version flag. The gcloud tool also outputs the version ID when you deploy.

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

Requests sent to https://PROJECT_ID.REGION_ID.r.appspot.com will still be routed to the version previously configured to receive traffic.
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:

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

Troubleshooting

The following are common error messages that you might encounter when deploying apps:

PERMISSION_DENIED: Operation not allowed
The "appengine.applications.create" permission is required.: If the Cloud project does not include the required App Engine application, the gcloud app deploy command can fail when it tries to run the gcloud app create command. Only accounts with Owner role have the necessary permissions to create App Engine applications.
502 Bad Gateway: The Cloud project can fail to start if the app.yaml is misconfigured. Check the app logs for more detailed error messages.