We're currently deploying Chromium Dash in a semi-structured way (dev_appserver.py for deployment, pick a number for a forward version as staging, increment to prod, etc).  However, per the infrastructure PRR process, we should be using gae.py for deployment, and sergiyb@ has suggested other alternatives as well:

"""
For most of our apps we use revision-based versions. This means that when you deploy code into the app you use current revision in the repo shortened to the first 7 hex digits, e.g. version e7c0c8c should correspond to https://.../chromiumdash/+/e7c0c8c34c73a1e9e4d2ad30491a148ab48d5d2d. If you are deploying a version that is not in the repo yet, e.g. for testing modifications that you only have locally, you add -tainted suffix, e.g. e7c0c8c-tainted. There are two advantages of this approach:
It is easy to see what version has been deployed already.
It is easy to revert to an old version.
To make it easy I typically use Makefile, e.g. https://chromium.googlesource.com/infra/infra/+/master/go/src/infra/appengine/test-results/Makefile

I think for staging instances it's fine to create a custom version called to your liking, e.g. amineer-staging. For my apps, I actually use a different app for staging instances to reduce the risk of breaking production app, e.g. http://chromium-try-flakes-staging.appspot.com/
"""

Filing this bug to track discussion / implementation of a better solution.  Once established, we should update the MD describing our process.