What Are The Best Practices for Managing Version Strings in Google App Engine Apps?

Question

In Google App Engine, you can upload up to 10 different versions on your appspot project. For instance, if I have a project called example, the URL would be:

http://example.appspot.com

Each version I upload is given a version string. Possible examples are:

• dev
• 1
• 1_2
• staging
• anystring

To access a specific version, I would prefix the domain with the version string, like so:

http://1.example.appspot.com

Of course, if that version is made the "default" version, then I can access it without prefixing with the version string, such as in the original URL at the beginning, http://example.appspot.com.

What are the current best practices for managing version strings on Google App Engine Apps, in your experience? Also, once I surpass the max 10 versions and have to start deleting them, what is the suggested practice?

Answer 1

The main issue is to make sure your release engineers (who may be the same as your developers) don't get confused about which version is which. Sequential build numbers (1, 2, 3, 4, ...) are usually fine for small projects. Using the date that you deployed the code (2011_05_29) would also work well.

If you have multiple developers and they deploy versions not intended to become the live version, calling them something like "myusername_test" will help avoid accidentally deploying it.

Sometimes there are special versions that aren't for testing but for a specific purpose. For example, sometimes I have a version named "down" which we make the default when we want to take the site down for maintenance. Or there could be an "admin" version, etc.

To be really safe you should use a different app id altogether for testing. Often each developer has his or her own app id. However, this requires either populating it with test data or copying the data from the production app id.

With regards to deleting versions, I would always keep one or two versions behind the live version just in case, but it's up to you.

Answer 2

Anything as long as it matches your commit message. I have saved myself a couple times by getting into the habit of saying what version it is deployed as before actually deploying.

I personally use something simple like crm-12 or blog-37