Cómo configurar un entorno de ensayo en Google App Engine

Question

Después de haber configurado correctamente un servidor Desarrollo y una servidor Producción, me gustaría establecer una ambiente Staging en Google App Engine útil para probar las nuevas versiones desarrolladas vivir antes de desplegarlos en producción.

sé dos enfoques diferentes:

A. La primera opción es modificando el parámetro app.yamlversión.

version: app-staging 

Lo que no me gusta de este enfoque es que los datos de producción está contaminada con mis exámenes de clasificación debido a que (corríjanme si me equivoco):

1. estadificación versión y la versión de producción de la cuota mismo almacén de datos
2. versión Puesta en escena y la versión de producción comparten los mismos registros

_{En cuanto t El primer punto, no sé si podría "arreglarse" usando el nuevo namespaces python API.}

B. La segunda opción es modificando el parámetro app.yamlaplicación

application: foonamestaging 

con este enfoque, me gustaría crear una segunda aplicación totalmente independiente de la versión de producción.
El único inconveniente que veo es que me veo obligado a configurar una segunda aplicación (configuración de administradores).
Con una herramienta de copia de seguridad \ restore como Gaebar esta solución también funciona bien.

¿Qué tipo de enfoque está utilizando para configurar un entorno de ensayo para su aplicación web?
Además, ¿tiene algún script automatizado para cambiar el yall antes de implementarlo?

Answer 1

Elegí la segunda opción en mi configuración, porque era la solución más rápida, y no hice ninguna secuencia de comandos para cambiar el parámetro de la aplicación en la implementación todavía.

Pero, tal como lo veo ahora, la opción A es una solución más limpia. Puede con un par de líneas de código de cambiar el espacio de nombres del almacén de datos basado en la versión, que se puede obtener de forma dinámica desde el CURRENT_VERSION_ID variable ambiental como se documenta aquí: http://code.google.com/appengine/docs/python/runtime.html#The_Environment

Answer 2

Si se requiere almacén de datos separada, la opción B parece la solución más limpia para mí porque:

1. Puede mantener la función de versiones para versiones reales de aplicaciones de producción.
2. Puede mantener la función de versiones para la división del tráfico.
3. Puede mantener la función de espacio de nombres para multicliente.
4. Puede copiar entidades fácilmente de una aplicación a otra. No es tan fácil entre espacios de nombres.
5. Pocas API todavía no admiten espacios de nombres.
6. Para equipos con múltiples desarrolladores, puede otorgar permiso de carga a la producción para una sola persona.

Answer 3

Utilizamos la opción B.

Además de Zygmantas sugerencias acerca de los beneficios de separar dev del prod a nivel de aplicación, también utilizamos nuestra aplicación dev para probar el rendimiento.

Normalmente, la instancia de desarrollo se ejecuta sin demasiada disponibilidad en el camino de los recursos, esto ayuda a ver dónde la aplicación "se siente" lenta. Luego, también podemos ajustar de forma independiente la configuración de rendimiento para ver qué hace la diferencia (por ejemplo, clase de instancia de front-end).

Por supuesto, a veces tenemos que morder la bala y ajustar el reloj & en vivo. Pero es bueno tener la otra aplicación para jugar.

Todavía usa espacios de nombres y versiones, solo dev es sucio y experimental.

Answer 4

que prefieren la opción A y estoy tratando de establecer un simple build script a automatizar para procesar

Answer 5

Fuimos con la opción B. Y yo creo que es mejor, en general, ya que aísla los proyectos por completo. Así que, por ejemplo, jugar con algunas de las configuraciones en el servidor de etapas no afectará ni comprometerá la seguridad ni provocará ningún otro efecto de mariposa en su entorno de producción.

En cuanto al script de despliegue, puede tener cualquier nombre de aplicación que desee en su app.yaml. Algunos ficticio nombre/dev y cuando se implementa, sólo tiene que utilizar un parámetro -A:

appcfg.py -A your-app-name update . 

que simplificará la secuencia de comandos de despliegue bastante tanto, no hay necesidad de reemplazar cadena o algo similar en su app.yaml