Yannick Clybouw

Blog about Google Cloud

Test, Staging And Beta on Google App Engine

Summary

Google App Engine (GAE) is a serverless approach to quickly ship your code to production. However, often you want to have a test, staging and/or beta environment. In this blog post, we describe how to achieve this.

Introduction

Google App Engine (GAE) is one of the older, but probably less known, products of the Google Cloud Platform. GAE is serverless before that word was popular. It allows software companies to focus on writing code and offload the infrastructural challenges to Google.

In GAE you can choose to have one monolith service, a bunch of micro-services, or something in between. The architecture of this blog post assumes that you have only one main service where all external HTTP requests are processed, while the other services (if any) are called internally (e.g. workers for asynchronous processing).

In GAE, such a main service is called the default service. This service is accessible through https://myproject.appspot.com¹, but you can add a custom domain with SSL managed by Google.

Types of Pre-Production Environments

Even if you have tested your app locally or on a non-GAE test environment, it is always scary to publish a new version of your code right away. Typically, you want to have a pre-production phase on GAE, where you or some friendly customers can experiment with the newest version.

Depending of your application and your business, and the depending of the definition you are using, this pre-production environment can be called test, staging, beta or EFT (early field trial). We will define them based on the different levels of data access they require:

  • Testing: Access to mock or anonymised data

  • Staging: Access to a recent copy of the production data

  • Beta/EFT: Direct access to production data (DB, cloud storage, etc.)

If you have a good testing and backup strategy, having a beta/EFT version is ideal to involve real customers!

Implementations in Google App Engine

To implement a pre-production environment in GAE, there are several options:

A new separate GAE project

    • Easy to separate testing/staging data from production data

    • Inconvenience: you need to redeploy to go live.

→ Ideal for testing and staging

A new separate service within your current GAE project

    • For staging/testing, you need security rules to protect your production data.

    • Inconvenience: you need to redeploy to go live.

→ Can be used for testing, staging and beta/EFT

Using a non-promoted version of your current service

    • This is the simplest and leanest setup to access production data.

    • You don't need to redeploy to go live (just change traffic allocation).

→ Ideal for beta/EFT

In the rest of this blog post, we will focus on beta (direct access to production data), using a non-promoted version of our service.

Deploying Versions

If you only have a production environment, the only thing you need to do when you have new code ready to deploy:

$ gcloud app deploy

When doing so, a new version of your default service will be available and receive 100% of the incoming traffic. Depending of your GAE environment, the previous version might be still running.

In the Google Cloud Console, you can manually start/stop previous versions. Each running version can be reached through following URL, even when they have 0% traffic allocation:

https://version-dot-myproject.appspot.com

Deploying a Beta Version

To release a beta version instead pushing directly to production:

$ gcloud app deploy --no-promote

Now, the previous version still has 100% traffic allocation and is thus reachable on the default URL, while the new version is your beta version, has 0% traffic allocation, but is directly accessible on:

https://new_version-dot-myproject.appspot.com

Now you, or your friendly customers, can use that URL as beta environment!

When you decide to go live, you go to the Google Cloud Console, and you change the traffic allocation to give the new version 100%. For now on, the new version is reachable on the production URL.

Note that this URL is different for each release, which might be problematic in some cases (e.g. for OAuth flow with fixed redirect_uri). In next blog post, we describe a solution for this.

Conclusion

By using the versioning system of Google App Engine, you can easily have a beta environment (using the production database) out-of-the-box. This includes an easy way to promote your beta version into production by just changing the traffic allocation.

Notes

¹ For new projects, the URLs have a region ID:

https://myproject.region_id.r.appspot.com