Best practice for production and test environments in Google App Engin

Question

What are the best practices for production and test (staging) environments in Google App Engine? Is it a good idea to setup separate projects?

We also use Google Cloud Storage and Cloud SQL. I'd like to prevent accidents where someone is mistakenly working in production when they intend to work in test.

We'll be storing a lot of stuff in GCS. From my understanding GCS environments are separate between projects. This can be desirable for us. But, if we want to copy product to test, is it possible to duplicate GCS from one app to another?

Looking forward to hearing how others do this.

Answer 1

Bruyere's answer is technically right, you can either version your app or use separate projects.

In practice, I've done both and you always end up needing to separate the projects for a ton of good reasons :

• You might not want the same people to have the rights to update the staging env (all the devs would have this ability for example) and the production env (typically this would be restricted to the tech lead, or QA team, or you continuous integration server)
• Isolating two app engine versions is not that easy, in particular when you deal with cron jobs, email or XMPP reception
• You might not want the same people to be able to read/write the staging data and the prod data
• You want to make sure that the App Engine prod app does not write to the staging Cloud Storage bucket. If they are part of the same project, by default this is possible

My recommendation is to store the environment related data (cloud storage bucket, Cloud SQL url etc) in a configuration file that is loaded by the application. If you use Java, I personnally use a properties file that is populated by Maven based on two profiles (dev and prod, dev being the default one).

Another important point is to separate environments from the start. Once you've started assuming that both environments will live in the same application, a lot of your code will be developed based on that assumption and it will be harder to move back to two different projects.

Answer 2

I was also wondering if there was another option than project for UAT/Prod env, I found this article from Google Documentation says you should use different projects.

Best Practices for Enterprise Organizations

https://cloud.google.com/docs/enterprise/best-practices-for-enterprise-organizations

We recommend that you spend some time planning your project IDs for manageability. A typical project ID naming convention might use the following pattern:

[company tag]-[group tag]-[system name]-[environment (dev, test, uat, stage, prod)]

For example, the development environment for the human resources department's compensation system might be named acmeco-hr-comp-dev.

Answer 3

I can see two ways to do this, all depending on your needs:

1) Using versions on your app, a different instance in the Cloud SQL and different bucket name for GCS you can use the same project. You just have to be super careful about setting what target each of your calls go to and to re-direct them when it goes live.

2) Using a separate project is probably the safer option but either way you will need to use a unique bucket name. Bucket names must be unique across all GCS instances.

Its quite easy to copy from one bucket to another once you get your permissions setup. Using gsutil you can copy from bucket to bucket.