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

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

Conozco dos enfoques diferentes:

A. La primera opción es modificando 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 clasificación porque (corríjame 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 provisional y la versión de producción comparten los mismos registros.

Con respecto al primer punto, no sé si podría ser “arreglado” usando la nueva API de python de espacios de nombres .

    B. La segunda opción es modificando 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 (configurada por los 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 prueba para su aplicación web?
    Además, ¿tiene algún script automatizado para cambiar el yaml antes de implementarlo?

    Escogí la segunda opción en mi configuración porque era la solución más rápida y aún no hice ningún script 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. Puede con un par de líneas de código cambiar el espacio de nombres del almacén de datos según la versión, que puede obtener dinámicamente de la variable de entorno CURRENT_VERSION_ID como se documenta aquí: http://code.google.com/appengine/docs/python/runtime.html #El entorno

    Si se requiere un almacén de datos separado, la opción B me parece una solución más limpia porque:

    1. Puede mantener la función de versiones para la versión real 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 espacios de nombres para multi-tenancy.
    4. Puede copiar fácilmente entidades de una aplicación a otra. No es tan fácil entre los espacios de nombres.
    5. Algunas APIs todavía no admiten espacios de nombres.
    6. Para equipos con múltiples desarrolladores, puede otorgar permisos de carga a producción para una sola persona.

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

    En cuanto al script de implementación, puede tener cualquier nombre de aplicación que desee en su app.yaml. Algún nombre ficticio / dev y cuando lo implementas, solo usa un parámetro -A :

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

    Eso simplificará su script de implementación bastante, sin necesidad de reemplazar cadenas ni nada similar en su app.yaml

    Utilizamos la opción B.

    Además de las sugerencias de Zygmantas sobre los beneficios de separar dev de 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 muchos recursos disponibles, 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 una diferencia (por ejemplo, clase de instancia de front-end).

    Por supuesto, a veces necesitamos morder la bala y modificar y ver en vivo. Pero es bueno tener la otra aplicación para jugar.

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

    Prefiero la opción A y estoy tratando de configurar un script de comstackción simple para automatizar y procesar