Deployment behavior

By default, once a new version of a service has been deployed, all traffic will be migrated from existing versions. For production systems, this is likely not an ideal behavior. Developers may desire to validate the new version before cutting traffic over, or to utilize a more complex strategy such as canary testing. For these cases, gcloud app deploy accepts the optional --no-promote flag. When provided, App Engine will not modify traffic, allowing a previous version of the service to handle all requests. Developers can then utilize the versioned URL to interact with the service without affecting end users.

The default behavior for previous versions of a service is to remain running. For services in the standard environment using automatic scaling, this is generally acceptable as previous versions will scale down to zero instances in the absence of network traffic. For services defining a minimum number of instances and services running in the flexible environment, these previous versions will continue to accrue costs. In many cases, such as deployments to lower lifecycles, it makes sense to stop these previous versions once a new version has been deployed. This behavior can be achieved by providing the gcloud app deploy command with the optional --stop-previous-version flag.

When deploying a new version of a service to App Engine, a new version is generated as a timestamp of the time of deployment. Most mature deployment processes will leverage some internal versioning system to track changes and associate releases with version control such as Git tags. To align App Engine service versions with these internal versioning systems, developers can specify the deployment version by providing the gcloud app deploy command with the optional --version flag, such as gcloud app deploy app.yaml --version 1.0.1.