python - prices - google app engine standard environment

Cómo configurar un entorno de transición en Google App Engine

Question

Después de haber configurado correctamente un servidor de desarrollo y un servidor de producción , me gustaría configurar un entorno de ensayo en Google App Engine útil para probar nuevas versiones desarrolladas en vivo antes de implementarlas en producción.

Sé dos enfoques diferentes:

R. La primera opción es modificar el parámetro de la versión app.yaml .

version: app-staging

Lo que no me gusta de este enfoque es que los datos de producción están contaminados con mis pruebas de estadificación porque (corríjanme si me equivoco):

1. La versión de ensayo y la versión de producción comparten el mismo almacén de datos
2. La versión de ensayo y la versión de producción comparten los mismos registros

_{Respecto al primer punto, no sé si podría "arreglarse" usando la nueva API python de espacios de nombres .}

B. La segunda opción es modificar el parámetro de la aplicación app.yaml

application: foonamestaging

con este enfoque, crearía 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 / restauración 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 aún no hice ninguna secuencia de comandos para cambiar el parámetro de la aplicación en la implementación.

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

Answer 2

Fuimos con la opción B. Y creo que es mejor en general, ya que aísla completamente los proyectos. 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 a la secuencia de comandos de implementación, puede tener cualquier nombre de aplicación que desee en su app.yaml. Algún nombre ficticio / dev y cuando implemente, simplemente use un parámetro -A :

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

Eso simplificará bastante su script de implementación, sin necesidad de reemplazar cadenas o algo similar en su aplicación.yaml

Answer 3

Prefiero la opción A y estoy tratando de configurar un script de compilación simple para automatizar el proceso

Answer 4

Si se requiere un almacén de datos independiente, la opción B parece una 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 los equipos con múltiples desarrolladores, puede otorgar la carga al permiso de producción para una sola persona.

Answer 5

Usamos la opción B.

Además de las sugerencias de Zygmantas acerca de los beneficios de separar dev de prod en el nivel de aplicación, también usamos nuestra aplicación de desarrollo 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. 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 y ver en vivo. Pero es bueno tener la otra aplicación para jugar.

Aún usa espacios de nombres y versiones, solo dev es sucio y experimental.