Maintaining dev, qa, staging, prod environments

[Will H]

Hi all,

Is it best practice to maintain different google cloud projects for each environment (dev, qa, prod....) for all google cloud services. I.e. I mean your dev project might have a google app, sql database, and compute instance that mirror your prod (except of course for the feature you are developing).  Or do some people keep all their dbs, compute instance in one project and only create separate projects for the dev, qa, prod version of their google app engine?

I hope that makes sense...

Will

[Taher (Cloud Platform Support)]

Hello Will,

It is suggested for cloud-based software projects to be employed multiple environments. It's vital that these environments be completely isolated from one another, and they typically have very different operator-access permissions. However, it always depends on the user to choose the most suitable model which will fulfill the needs.

[Blaine Garrett]

This is generally the best practice for production grade applications.
For example, you might have loser permissions for a dev/qa environment but should have strict permissions for production.
Similarly, you might have smaller instances for dev/qa to save cost and help performance tune but have larger instances for prod to account for higher traffic.
Also, related to the first point, you can isolate each environments ENV/Settings/Runtime Variables per instance as per 12 factor applications.
https://12factor.net/

Hope that helps,
~Blaine

[Daniel Jimenez]

Hi Will,

From a development perspective, I have found that especially when using GAE there is sometimes no need for a dev environment that utilises GCP resources.
This is due to the SDK being very powerful in running applications on the developers local machine. 

Of course this does not always work completely as there are some products that the SDK, currently, does not support.

I have also found that for staging (with GAE), versions can be used to verify changes before you let that application accept traffic.

- Dan