Administrador de recursos y Cloud Gem Framework Control de versiones - Lumberyard Guía del usuario

Si proporcionásemos una traducción de la versión en inglés de la guía, prevalecerá la versión en inglés de la guía si hubiese algún conflicto. La traducción se proporciona mediante traducción automática.

Administrador de recursos y Cloud Gem Framework Control de versiones

Lumberyard ofrece un sistema de control de versiones que facilita la actualización un proyecto de una versión de Cloud Gem Framework y el Cloud Canvas Responsable de recursos a otro. El sistema de control de versiones tiene lo siguiente: ventajas:

  • Las gemas en la nube pueden tener versiones independientes.

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

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

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

  • Lumberyard puede innovar a la vez que respalda gemas que dependen de versiones tempranas del del marco de trabajo.

Este documento describe estos cambios en un nivel de arquitectura. Para pasos concretos en para actualizar los proyectos y gemas existentes para utilizar el control de versiones, consulte Actualización de proyectos y gemas en la nube a la versión 1.0.0 de la nube de Marco de gemas.

Convenciones de control de versiones

Lumberyard las gemas utilizan una control de versiones semánticas, que define los números de versión en el formulario major.minor.revision. Lumberyard incrementa la versión principal para los cambios que hacen que el código anterior no funcione, incluyendo cualquier cambio que rompa el código o la configuración que no esté directamente controlado por la nube Marco de gemas.

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

Las actualizaciones menores reemplazan el código en el campo \dev\Gems\CloudGemFramework\vN del directorio. Las versiones principales anteriores del marco de trabajo se siguen publicando con Lumberyard para un de tiempo antes de que se eliminen de la versión.

Varias versiones de la gema en la nube Gema de marco

La nueva estructura de directorios en Cloud Gem Framework 1.0.0 permite la coexistencia de varias Versiones de la gema Cloud Gem Framework. La implementación de la gema se ha movido del \dev\Gems\CloudGemFramework\ al directorio de \dev\Gems\CloudGemFramework\v<N>\ del directorio. La intención es que todos los cambios continuos se realicen en el campo v<Current> del directorio. Al romper se producen cambios, v<Next> el directorio es creado para contener la implementación actualizada. El v<Current> el contenido del directorio permanece sin cambios o actualizado sin romper los cambios. Una gema ahora puede tener diferentes versiones de es gem.json en el archivo v1 y v2 , por ejemplo. Esto permite que la gema especifique diferentes versiones de. LumberyardLas herramientas de configuración de compilación y proyecto de admiten gemas en subdirectorios.

nota

El Cloud Canvas Responsable de recursos ahora permite que las gemas estén en directorios que no sea \Gems\<gem-name>. El añadir-grupo-de-recursos lmbr_aws resource-group add del comando --gem ahora toma una opción valor opcional que especifica la ruta del directorio de la gema. La ruta de directorio especificada puede ser relativo al directorio de trabajo actual o a una ruta completa.

Aplicación Actualizaciones del marco de un proyecto

¿Cuándo? Lumberyard lanza una nueva versión principal del marco de trabajo, puede elegir cuándo deshabilitar la versión antigua del marco de trabajo y cuándo habilitar la nueva.

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

Después de que se detecte y habilite la nueva versión, el siguiente paso es actualizar el de infraestructura en AWS como dicta la nueva versión del marco de trabajo. El lmbr_aws y el administrador de recursos de Cloud Canvas detectan cuándo es necesaria una actualización comprobando el versión actual del marco de trabajo del proyecto en dos lugares: el local-project-settings.json y en el archivo del proyecto Amazon S3 del bucket de configuración de. Si cualquiera de los valores no es exactamente igual que la versión del marco, el El comando se cierra con un error y no realiza ninguna acción.

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

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

  2. Actualiza la pila del proyecto.

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

  4. : guarda la nueva versión del marco de trabajo en el local-project-settings.json y a la configuración del proyecto del bucket en Amazon S3.

La versión del marco de trabajo del proyecto se actualiza después de llamar correctamente a todos los enlaces y todos actualizaciones completadas.

Actualizar implementaciones manualmente

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

Para ayudar a las herramientas personalizadas a gestionar las pilas antiguas, la versión del marco de trabajo que está en vigor para la pila la proporciona el FrameworkVersion parámetro de plantilla. Si esto el parámetro no está presente, la herramienta debe asumir que la pila es anterior a la versión 1.1.0 de el marco de trabajo.

En el caso de un cambio de versión importante, Lumberyard herramientas (incluidas lmbr_aws) puede se niega a trabajar con cualquier pila de que aún no se haya actualizado. Sin embargo, para la versión secundaria , las herramientas deben seguir funcionando con pilas de implementación y grupos de recursos que aún no se han actualizado.

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

Recurso El administrador de se ha fusionado en la gema Cloud Gem Framework

En Lumberyard 1.10, la gema en la nube ha asumido la funcionalidad de administrador de recursos Gema de marco. En consecuencia, y para permitir que se controle la versión del administrador de recursos, el contenido de la \dev\tools\lmbr_aws\ se han movido al directorio dev\Gems\CloudGemFramework\v<N>\ResourceManager\ con las siguientes excepciones:

  • El \dev\tools\lmbr_aws\ del directorio aún contiene el cli.py y gui.py módulos. Estos módulos son cargado por el lmbr_aws.cmd y el usuario administrador de recursos interfaz en Lumberyard del. Estos módulos descubren qué proyecto es el actual mirando en el \dev\bootstrap.cfg del archivo. Luego, miran en el proyecto \dev\project_name\gems.json del archivo a obtener Version valor para CloudGemFramework. Los módulos reenviar la solicitud al cli.py o bien gui.py para la versión especificada del marco de trabajo. En caso negativo versión del marco de trabajo está habilitada, un mensaje de advertencia que indica que la gema debe estar habilitada es se muestra en.

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

Directorios de código de proyecto global y plantillas de proyecto

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

Código de proyecto Directorios

El \<project>\AWS\project-code del directorio anteriormente contenía código para lo siguiente Lambda funciones:

  • ProjectPlayerAccessTokenExchangeHandler

  • ProjectResourceHandler

  • ProjectServiceLambda

Anteriormente, esta Lambda se copió el código de la \dev\tools\lmbr_aws\AWSResourceManager\default-project-content\project-code al crear el proyecto.

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

nota

Uso de un <gem>\AWS\project-code o un resource-group\<resource-group>\project-code directorio para inyectar código en el proyecto Lambda ya no es compatible con la función.

Proyecto Plantillas

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

  • 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 el de plantillas reales del proyecto. A continuación, carga las plantillas en AWS CloudFormation.

nota

Empezando en Lumberyard 1.10, puede utilizar archivos de extensión para añadir recursos a cada uno de estos de plantillas de. Para obtener más información, consulte Extensión de plantilla Archivos.

Compartir código

El lmbr_aws cloud-gem-framework añada-servicio-recursos-api el comando añade un La API de servicio de a un grupo de recursos. Antes Lumberyard versión 1.10, copió el servicio Lambda código para enviar llamadas a la API de servicio desde la CloudGemFramework\AWS\resource-manager-code\default-resource-group-content\lambda-function-code al directorio del grupo de recursos lambda-function-code del directorio.

En la versión 1.10, Lumberyard añade un mecanismo de uso compartido de código general. Puedes utilizar esta para incluir una única copia del código de envío de la API de servicio en todos los Lambda funciones que lo requieren. Para obtener más información, consulte Uso del código compartido.