Cómo migrar al complemento de Gradle basado en el SDK de Cloud

Si utilizas el complemento de Java basado en SDK de App Engine (com.google.appengine.appengine-gradle) y deseas cambiar al SDK de Google Cloud nuevo, debes migrar al complemento nuevo basado en el SDK de Google Cloud (com.google.cloud.tools.appengine-gradle).

Beneficios del complemento basado en el SDK de Cloud

La actualización al nuevo complemento brinda estos beneficios:

  • Usa las mismas credenciales de autenticación que todos los otros comandos basados en el SDK de Cloud, que se producen desde el flujo estándar gcloud auth login.

  • Es compatible con el entorno de App Engine Flexible.

  • Actualiza de manera automática el servidor de desarrollo local como parte del flujo de actualización estándar del SDK de Cloud.

  • Admite la implementación de las configuraciones del servicio de App Engine de cron, colas, dos, dispatch por separado de tu servicio.

  • Configura las variables del entorno en appengine-web.xml para ejecuciones del servicio local.

  • Admite varios servicios sin necesitar paquetes EAR.

Diferencias destacadas

Antes de migrar, ten en cuenta estas diferencias destacadas:

Dependencia del SDK de Cloud
El complemento anterior se ejecuta sin ninguna dependencia de entorno local en particular, sin contar Java, pero el complemento nuevo necesita que instales el SDK de Google Cloud.
Sin generación de documento de descubrimiento de Cloud Endpoints
El complemento nuevo no genera documentos de descubrimiento de Cloud Endpoints, una característica sí disponible en otro complemento. La ejecución de tu backend de Cloud Endpoints ya no requiere generar este archivo en un paso de compilación porque el servidor lo genera ahora en el entorno de ejecución. Deberías usar el complemento nuevo solo si necesitas generar bibliotecas cliente como para iOS o Android. Si quieres obtener más información sobre los complementos nuevos, revisa la guía Cómo migrar a marcos de trabajo de Endpoints para App Engine.
El formato de archivo EAR ya no es más compatible
El complemento nuevo ya no admite el formato de archivo EAR para implementar y ejecutar varios servicios a la vez.
Nuevo comando de implementación
El complemento anterior llama al comando appcfg para implementar aplicaciones, mientras que el complemento nuevo implementa con el nuevo CLI gcloud.
Las mejoras de JPA/JDO de Datanucleus se deben configurar de forma manual
Si en tu proyecto se utilizan las mejoras gradle-appengine-plugin de JPA/JDO de Datanucleus, tienes que configurar las mejoras de Datanucleus de forma manual luego de cambiar al complemento basado en SDK de Cloud. Observa un ejemplo desde Stackoverflow.
Android Studio no es compatible
Puedes cambiar tu proyecto de Android Studio de modo que use el complemento nuevo, pero la asistencia para la implementación y el servidor de desarrollo de Android Studio de la App Engine no funcionará con este complemento nuevo. Para implementar y ejecutar tu app, debes invocar a Gradle de forma directa.

Se admite el uso de los archivos de configuración XML, pero no los de YAML.

Cómo migrar al complemento nuevo

  1. Quita la configuración anterior gradle-appengine-plugin y las importaciones del archivo build.gradle.

  2. Agrega el complemento nuevo a classpath de la sección buildscript de tu archivo build.gradle:

    buildscript {
        repositories {
            mavenCentral()
        }
    
        dependencies {
            classpath 'com.google.cloud.tools:appengine-gradle-plugin:1.3.5'
        }
    }
    
  3. En la raíz de tu servicio, ejecuta el siguiente comando para verificar que puedas ejecutar tu aplicación de manera local:

    gradle appengineRun
    
  4. En la sección buildscript de tu archivo build.gradle, configura la implementación especificando tu ID del proyecto y la versión:

    appengine {
        deploy {
            version = 'v1'
            project = "your GCP project ID"
        }
    }
    

    La nueva herramienta ignora los elementos de la aplicación y la versión en tu archivo appengine-web.xml.

  5. En la raíz de tu servicio, ejecuta el siguiente comando para verificar que puedas implementar tu aplicación:

    gradle appengineDeploy
    

Cómo migrar configuraciones de varios servicios basadas en EAR

El complemento nuevo no admite paquetes de EAR. En su lugar, admite ejecutar varios servicios de forma local sin pasos de empaquetado especiales.

Para migrar tu proyecto Gradle basado en EAR:

  1. Elige un servicio principal que será el responsable de ejecutar el resto de los servicios. Debes elegir tu servicio predeterminado, que puede ser cualquiera de los servicios que se ejecutan en conjunto.

  2. En la configuración appengine modifica la entrada run.services para incluir todos los servicios que se deben ejecutar a través del servidor de desarrollador local.

    Ejemplo de estructura de proyecto:

    ../{projectRoot}/
      build.gradle
      settings.gradle (includes default-service & secondary-service)
           {your-default-service}/build.gradle {includes appengine-gradle-plugin}
              ….
           {your-default-service}/src/main/webapp/WEB-INF/appengine-web.xml
           {your-secondary-service}build.gradle {includes appengine-gradle-plugin}
              ….
           {your-secondary-service}/src/main/webapp/WEB-INF/appengine-web.xml
    

    Ejemplo de un buildscript build.gradle:

    appengine {
        deploy {
            version = '1'
            project = "positive-karma-844"
        }
    
        run {
            services = [
                    getExplodedAppDir(project),
                    getExplodedAppDir(project(":{your-secondary-service}"))
            ]
        }
    }
    
    // helper method to obtain correct directory and set up dependencies
    def getExplodedAppDir(Project serverProject) {
        // if not 'this' module, then do some setup.
        if (serverProject != project) {
            // make sure we evaluate other modules first so we get the right value
            evaluationDependsOn(serverProject.path)
            // make sure we build "run" depends on the other modules exploding wars
            project.tasks.appengineRun.dependsOn serverProject.tasks.explodeWar
        }
        return serverProject.tasks.explodeWar.explodedAppDirectory
    }
    

App Engine basada en SDK en comparación con los comandos de Gradle basados en el SDK de Cloud

La tabla a continuación muestra los distintos métodos para invocar el complemento de Gradle, según utilices el complemento de Gradle basado en el SDK de App Engine o el complemento de Gradle basado en el SDK de Cloud.

Acción Basado en el SDK de App Engine Basado en el SDK de Google Cloud
Ejecuta la aplicación de manera local. appengine:devserver appengineRun
Implementa una aplicación, versión o servicio nuevo. appengine:update appengineDeploy
Establece la versión predeterminada de la aplicación. appengine:set_default_version gcloud app services set-traffic o gcloud app versions migrate
Actualiza los trabajos cron de la aplicación. appengine:update_cron appengineDeployCron
Actualiza la configuración de despacho de la aplicación. appengine:update_dispatch appengineDeployDispatch
Actualiza la configuración de protección contra DoS de la aplicación. appengine:update_dos appengineDeployDos
Actualiza las definiciones de la lista de tareas en cola de la aplicación. appengine:update_queues appengineDeployQueue
Actualiza los índices de Datastore. appengine:update_indexes appengineDeployIndex
Borra los índices no usados de la aplicación. appengine:vacuum_indexes appengineDeployIndex
Inicia la versión del módulo especificado. appengine:start_module_version gcloud app versions start
Finaliza la versión del módulo especificado. appengine:stop_module_version gcloud app versions stop
Revierte una actualización en curso. appengine:rollback gcloud app versions start, gcloud app versions stop

Próximos pasos

  • Ahora que migraste de forma correcta al complemento nuevo, puedes probar y, además, implementar tu aplicación.
¿Te ha resultado útil esta página? Enviar comentarios:

Enviar comentarios sobre...

Entorno estándar de App Engine para Java