Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to set up a staging environment on Google App Engine

Having properly configured a Development server and a Production server, I would like to set up a Staging environment on Google App Engine useful to test new developed versions live before deploying them to production.

I know two different approaches:

A. The first option is by modifying the app.yaml version parameter.

version: app-staging 

What I don't like of this approach is that Production data is polluted with my staging tests because (correct me if I'm wrong):

  1. Staging version and Production version share the same Datastore
  2. Staging version and Production version share the same logs

Regarding the first point, I don't know if it could be "fixed" using the new namespaces python API.

B. The second option is by modifying the app.yaml application parameter

application: foonamestaging 

with this approach, I would create a second application totally independent from the Production version.
The only drawback I see is that I'm forced to configure a second application (administrators set up).
With a backup\restore tool like Gaebar this solution works well too.

What kind of approach are you using to set up a staging environment for your web application?
Also, do you have any automated script to change the yaml before deploying?

like image 614
systempuntoout Avatar asked Sep 25 '10 12:09

systempuntoout


People also ask

Which programming environment is used for Google App Engine?

Google App Engine provides four possible runtime environments for applications, one for each of four programming languages: Java, Python, PHP, and Go. The environment you choose depends on the language and related technologies you want to use for developing the application.


2 Answers

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.
like image 108
Zygimantas Avatar answered Sep 23 '22 06:09

Zygimantas


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

like image 37
benwixen Avatar answered Sep 23 '22 06:09

benwixen