How to set up a staging environment on Google App Engine

Question

Having properly configured a Development server and a Production server, I would like to set up a Staging environment on Google App Engine useful

Answer 1

No need to create a separate project. You can use dispatch.yaml to route your staging URL to another service (staging) in the same project.

1. Create a custom domain staging.yourdomain.com

2. Create a separate app-staging.yaml, that specifies staging service.

   ... service: staging ...

3. Create distpatch.yaml that contains something like

   ...

   • url: "*staging.mydomain.com/" service: staging

   • url: "*mydomain.com/" service: default ...

4. gloud app deploy app-staging.yaml dispatch.yaml

Answer 2

I chose the second option in my set-up, because it was the quickest solution, and I didn't make any script to change the application-parameter on deployment yet.

But the way I see it now, option A is a cleaner solution. You can with a couple of code lines switch the datastore namespace based on the version, which you can get dynamically from the environmental variable CURRENT_VERSION_ID as documented here: http://code.google.com/appengine/docs/python/runtime.html#The_Environment

Answer 3

We went with the option B. And I think it is better in general as it isolates the projects completely. So for example playing around with some of the configurations on the staging server will not affect and wont compromise security or cause any other butterfly effect in your production environment.

As for the deployment script, you can have any application name you want in your app.yaml. Some dummy/dev name and when you deploy, just use an -A parameter:

appcfg.py -A your-app-name update .

That will simplify your deploy script quite much, no need to string replace or anything similar in your app.yaml

Answer 4

We use option B.

In addition to Zygmantas suggestions about the benefits of separating dev from prod at application level, we also use our dev application to test performance.

Normally the dev instance runs without much available in the way of resources, this helps to see where the application "feels" slow. We can then also independently tweak the performance settings to see what makes a difference (e.g. front-end instance class).

Of course sometimes we need to bite the bullet and tweak & watch on live. But it's nice to have the other application to play with.

Still use namespaces and versions, just dev is dirty and experimental.

Answer 5

If separate datastore is required, option B looks cleaner solution for me because:

1. You can keep versions feature for real versioning of production applications.
2. You can keep versions feature for traffic splitting.
3. You can keep namespaces feature for multi-tenancy.
4. You can easily copy entities from one app to another. It's not so easy between namespaces.
5. Few APIs still don't support namespaces.
6. For teams with multiple developers, you can grant upload to production permission for a single person.