Cloud Gem Framework y control de versiones del administrador de recursos - Guía del usuario de Lumberyard

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Cloud Gem Framework y control de versiones del administrador de recursos

Open 3D Engine (O3DE), el sucesor de Lumberyard, ya está disponible en Developer Preview. Descargar O3DEo visite elBlog de AWS Game Techpara obtener más información.

Lumberyard ofrece un sistema de control de versiones que facilita actualizar un proyecto desde una versión de Cloud Gem Framework y eladministrador de recursos de Cloud Canvasa otro. El sistema de control de versiones presenta las siguientes ventajas:

  • Las gemas en la nube puede tener diferentes versiones.

  • Las gemas en la nube pueden especificar la versión de Lumberyard con la que trabajan.

  • El administrador de recursos y Cloud Gem Framework se implementan en las estructuras de directorio que admiten el control de versiones.

  • Lumberyard puede proporcionar varias versiones de Cloud Gem Framework y del administrador de recursos al mismo tiempo.

  • Lumberyard puede innovar pero seguir admitiendo gemas que dependen de versiones anteriores del marco.

En este documento se describen estos cambios en el nivel de la arquitectura. Para obtener medidas concretas sobre la actualización de gemas y proyectos existentes para el uso del control de versiones, consulte Actualización de proyectos y Cloud Gems a la versión 1.0.0 de Cloud Gem Framework.

Convención del control de versiones

Las gemas de Lumberyard utilizan una simplificaciónVersiones semánticas, que define los números de versión en el formulariomayor.menor.revisión. Lumberyard incrementa la versión principal para los cambios que hacen que el código anterior no funcione, incluido cualquier cambio que interrumpa el código o la configuración que no esté directamente controlada por Cloud Gem Framework.

Cada cambio de la versión principal se lanza creando una nueva base de código en un nuevo directorio \dev\Gems\CloudGemFramework\vN, donde N es el número de versión principal.

Las actualizaciones menores sustituyen el código del directorio \dev\Gems\CloudGemFramework\vN. Las versiones principales del marco de trabajo anteriores se siguen lanzando con Lumberyard durante una cantidad de tiempo no especificada antes de que se eliminen de la versión de lanzamiento.

Varias versiones de Cloud Gem Framework Gem

La nueva estructura de directorios de Cloud Gem Framework 1.0.0 permite la coexistencia de varias versiones de Cloud Gem Framework Gem. La implementación de la gema ha pasado del directorio \dev\Gems\CloudGemFramework\ al directorio \dev\Gems\CloudGemFramework\v<N>\. La intención es que todos los cambios menores se hagan en el directorio v<Current>. Cuando se hacen modificaciones mayores, se crea un directorio v<Next> para la implementación actualizada. El contenido del directorio v<Current> permanece inalterado o se actualiza sin los cambios mayores. Ahora, una gema puede tener diferentes versiones del archivo gem.json en los directorios v1 y v2, por ejemplo. Esto permite que la gema especifique distintas versiones. Las herramientas de configuración de proyectos y compilación de Lumberyard admiten gemas en los subdirectorios.

nota

Laadministrador de recursos de Cloud Canvasahora permite que las gemas estén en directorios que no sean\Gems\<gem-name>. La opción resource-group add de comando lmbr_aws resource-group add --gem ahora toma un valor opcional que especifica la ruta del directorio de la gema. La ruta del directorio especificado puede ser relativa al directorio de trabajo actual o una ruta completa.

Aplicar actualizaciones de marco de trabajo a un proyecto

Cuando Lumberyard publica una nueva versión principal del marco de trabajo, puede elegir cuándo deshabilitar la versión antigua y cuándo habilitar la nueva.

Si se publica una versión secundaria del marco de trabajo y sustituye la configuración del marco de trabajo en el directorio CloudGemFramework\vN, se producirán errores. Los errores se muestran en la consola al cargar su proyecto en el Lumberyard Editor.

Tras descubrir y habilitar la nueva versión, el siguiente paso consiste en actualizar la infraestructura del proyecto en AWS, según dicte la nueva versión del marco de trabajo. Lalmbr_awsy el administrador de recursos de Cloud Canvas detectan cuándo se necesita una actualización comprobando la versión del marco de trabajo actual del proyecto en dos lugares:local-project-settings.jsony en el bucket de configuración de Amazon S3 del proyecto. Si alguno de los valores no es exactamente igual a la versión del marco, el comando se cierra con un error y no realiza ninguna acción.

Para actualizar la infraestructura de su proyecto, use el comando lmbr_aws project update-framework-version. Si el comando update-framework-version detecta un cambio en la versión del marco de trabajo, realiza las siguientes acciones:

  1. Ejecuta el método de enlace before_project_framework_version_change(hook, from_version, to_version) en los módulos update.py del complemento.

  2. Actualiza la pila del proyecto.

  3. Ejecuta el método de enlace after_project_framework_version_change(hook, from_version, to_version) en los módulos update.py del complemento.

  4. Guarda la nueva versión del marco de trabajo en ellocal-project-settings.jsony al bucket de configuración del proyecto en Amazon S3.

La versión del marco de trabajo del proyecto se actualiza después de que todos los enlaces se invoquen correctamente y todas las actualizaciones se completen.

Actualización manual de las implementaciones

El comando lmbr_aws project update-framework-version nunca actualiza pilas de implementación, accesos a la implementación o pilas de grupos de recursos. Los enlaces de actualización pueden realizar cambios a las plantillas de recursos, el código de Lambda y otros elementos. Sin embargo, debe realizar todas las actualizaciones de las pilas de implementación, acceso a la implementación y grupos de recursos por separado, después de que se complete el comando project update-framework-version.

Para ayudar a las herramientas personalizadas a trabajar con pilas antiguas, la versión del marco de trabajo efectiva para la pila se proporciona en el parámetro de plantilla FrameworkVersion. Si este parámetro no está presente, la herramienta debería suponer que la pila es anterior a la versión 1.1.0 del marco de trabajo.

En el caso de un cambio de versión importante, las herramientas de Lumberyard (incluidaslmbr_aws) puede no funcionar con las pilas que no se hayan actualizado aún. Sin embargo, para cambios de versión secundarios, las herramientas deberían seguir funcionando con las pilas de implementación y grupos de recursos que no se hayan actualizado aún.

Para actualizar la pila de implementación (y todas sus pilas de grupos de recursos), puede utilizar el comando lmbr_aws deployment update. Para actualizar la pila de acceso de implementación, puede utilizar el comando deployment update-access.

Administrador de recursos fusionado en Cloud Gem Framework Gem

En Lumberyard 1.10, la funcionalidad del administrador de recursos se ha sustituido por la gema Cloud Gem Framework. Por lo tanto, y para permitir las versiones del administrador de recursos, el contenido del directorio \dev\tools\lmbr_aws\ se ha movido al directorio dev\Gems\CloudGemFramework\v<N>\ResourceManager\, con las siguientes excepciones:

  • El directorio \dev\tools\lmbr_aws\ aún contiene los módulos cli.py y gui.py. Estos módulos se cargan conlmbr_aws.cmdy la interfaz de usuario del administrador de recursos en Lumberyard Editor. Estos módulos descubren qué proyecto es el actual mirando en el archivo \dev\bootstrap.cfg. A continuación, buscan en el archivo \dev\project_name\gems.json del proyecto para obtener el valor Version para CloudGemFramework. Después, los módulos reenvían la solicitud al módulo cli.py o gui.py correspondiente para la versión especificada del marco de trabajo. Si no se habilita ninguna versión del marco, se mostrará un mensaje de advertencia indicando que debe habilitarse la gema.

  • El directorio dev\Tools\lmbr_aws\test\ aún contiene los archivos de los módulos RunAllTests.cmd, cleanup.cmd y Python que los admiten. El archivo RunAllTests.cmd se ha actualizado para ejecutar pruebas desde el directorio CloudGemFramework\v<N>\. A medida que se producen nuevos lanzamientos, el archivo se actualizará para incluir todas las versiones del marco de trabajo.

Directorios de código y plantillas de proyecto globales

En Cloud Gem Framework 1.0.0 (versión 1.10 de Lumberyard), los directorios de código del proyecto y las plantillas de proyecto también han cambiado para admitir el control de versiones.

Directorios de código de proyecto

La\<project>\AWS\project-codeantes contenía código para las siguientes funciones Lambda:

  • ProjectPlayerAccessTokenExchangeHandler

  • ProjectResourceHandler

  • ProjectServiceLambda

Anteriormente, este código Lambda se copiaba del\dev\tools\lmbr_aws\AWSResourceManager\default-project-content\project-codecuando se creaba el proyecto.

Este código se encuentra en\Gems\CloudGemFramework\vN\AWS\lambda-code\directorio en subdirectorios dividido por la función Lambda.

nota

Uso de una<gem>\AWS\project-codeo unresource-group\<resource-group>\project-codeEl directorio para inyectar código en la función Lambda del proyecto ya no es compatible.

Plantillas de proyecto

Los siguientes archivos de plantilla se han movido al directorio \Gems\CloudGemFramework\vN\ResourceManager\resource_manager\templates.

  • deployment-access-template.json

  • deployment-template.json

  • project-template.json

Cuando el marco de trabajo actualiza una pila, utiliza estas plantillas como base para crear las plantillas reales del proyecto. A continuación, carga las plantillas en AWS CloudFormation.

nota

A partir de Lumberyard 1.10, puede utilizar los archivos de extensión para añadir recursos a cada una de estas plantillas. Para obtener más información, consulte Archivos de extensión de plantilla.

Compartir código

El comando lmbr_aws cloud-gem-framework añade una API de servicio a un grupo de recursos. add-service-api-resources Antes de versión 1.10 de Lumberyard, copiaba el código Lambda del servicio para enviar llamadas a la API de servicio desde elCloudGemFramework\AWS\resource-manager-code\default-resource-group-content\lambda-function-codeal directorio del grupo de recursoslambda-function-codedirectory.

En la versión 1.10, Lumberyard añade un mecanismo de código compartido con fines generales. Puede utilizar este mecanismo para incluir una única copia del código de envío de la API de servicio en todas las funciones Lambda que lo necesiten. Para obtener más información, consulte Uso de código compartido.