Integración Studio-GIT
A partir de la versión 3.0, Studio se integra con GIT —el sistema de control de versiones— y se gestiona a través de GitLab. Las características clave de esta integración incluyen:
Trabajo con ramas. Les permite a ti y a tu equipo trabajar en diferentes aspectos de la misma aplicación en paralelo y, a continuación, ejecutar commits, para evitar la implementación de cambios no deseados. También les permite crear ramas a partir de una rama productiva para solucionar problemas y probar las correcciones antes de aplicar cualquier cambio en la rama productiva. Esto garantiza la calidad de las correcciones implementadas.
Almacenamiento de entidades en GIT. Almacena y versiona entidades como pantallas, procesos legacy y lambda, pruebas y recursos en GIT. Las librerías de funciones y los módulos también se almacenan y versionan en GIT, pero los usuarios no pueden trabajar simultáneamente en diferentes versiones. Esto permite una mejor trazabilidad de todos los cambios introducidos en las entidades a través de su historial de commits, lo que elimina la necesidad de un archivo adicional para seguir esos cambios.
Control de versiones. Proporciona un mejor control sobre lo que se incluye en cada versión de la aplicación, gracias a la información proporcionada sobre cada cambio introducido en una rama o entidad almacenada en GIT. La integración con Jira te permite un conocimiento más completo de los requisitos que provocaron cada corrección o mejora. Además, puedes revisar fácilmente los cambios aplicados a una entidad revisando el historial de commits de la entidad.
Rollback Te permite restaurar pantallas, procesos legacy y lambda a una versión o un commit anterior.
Cuando creas una aplicación o un módulo en Studio, se crea una rama principal de forma predeterminada. Se sugiere utilizar la rama principal como una copia de la versión productiva y agregar etiquetas para cada versión publicada de esta rama. Esto proporciona un mejor control sobre lo que se incluye en cada versión de la aplicación. Solo puedes agregar y ver etiquetas de GitLab.
Luego, a medida que continuas trabajando en la aplicación, puedes crear tantas ramas como sea necesario según el tipo de actualizaciones que necesites realizar y la estrategia de ramas y entrega definidas con el cliente. Lee a continuación para conocer los diferentes tipos de ramas que puedes crear y sus usos.
Tipos de ramas
Puedes seleccionar entre cinco tipos diferentes de ramas en función de tus necesidades y de la estrategia de ramas del proyecto. Estos tipos tienen las mismas funcionalidades, pero incluyen un prefijo específico que organiza las ramas de acuerdo con las mejores prácticas. Por ejemplo, si creas una rama de feature con el nombre "pagos qr", su nombre completo será "feature/qr-payments" (branchtype/branchname).
Nota
Cuando creas una aplicación o módulo nuevo, siempre se crea una rama principal de forma predeterminada.
Lee a continuación para aprender sobre cada tipo de rama que puedes crear con Studio 3.0.
Desarrollar | Tipo de rama desde donde se crean las ramas de feature. Solo puedes haber una rama develop por aplicación o módulo. |
Característica | Tipo de rama creada para trabajar en nuevas características o funcionalidades. |
Hotfix | Rama que se usa para corregir problemas o errores menores en aplicaciones productivas o en entornos de desarrollo. Dependiendo del tipo de corrección, se pueden crear desde la rama productiva o desde cualquier rama develop si el problema aparece durante el proceso de desarrollo. Después de probar las correcciones implementadas, debes hacer un merge de la rama hotfix con la rama de la que surgió; además también puedes llevar los cambios a cualquier otra rama afectada por la corrección. |
Liberación | Rama utilizada para integrar ramas feature y ejecutar una prueba completa de lo que se publicará después. La rama release representa el paquete de versión que se va a entregar. |
Custom | Rama utilizada para casos especiales que no están contemplados en los tipos de rama anteriores. Se aconseja no utilizar este tipo de rama con demasiada frecuencia. |
Lee Branch Management para aprender a crear y eliminar ramas en Studio.
Gestión de sesiones
A partir de Studio 3.0, solo puedes trabajar con una aplicación o rama del módulo a la vez con las mismas credenciales de usuario. Esto significa que no podrás editar dos ramas diferentes al mismo tiempo. A continuación aprenderás cómo funcionan las sesiones en Studio 3.0.
Al trabajar en una rama en particular (sesión 1), si abres una nueva sesión de Studio con las mismas credenciales y navegas a la misma aplicación pero a una rama diferente (sesión 2), la sesión 1 se bloquea y se deja inactiva, como se muestra a continuación.
Aparece un banner amarillo informando que la sesión 1 está inactiva, mientras que la sesión 2 está disponible para edición. Para reactivar la sesión 1, haz clic en Activate this session. De esta manera, la sesión 2 quedará inactiva y se bloqueará su edición.
Aviso
Tenga cuidado al desactivar una sesión, ya que podría perder cualquier cambio pendiente, dependiendo de las entidades en las que esté trabajando. Actualmente, puede perder actualizaciones pendientes en cada entidad, excepto en los procesos lambda, transacciones configurables y pantallas.
Si necesitas tener diferentes ramas abiertas al mismo tiempo para comparar los cambios, puedes pedirle al administrador que cree un usuario de solo lectura (sin permisos de edición). Con este tipo de usuario, puedes trabajar con ambas ramas en paralelo sin afectar la integridad de ninguna de ellas. Para usar ambos usuarios simultáneamente, debes usar uno de ellos en una ventana en modo incógnito.
Las entidades, como las pantallas, los procesos legacy y lambda, las pruebas y los recursos, se almacenan y versionan en GIT. Las librerías de funciones y los módulos también se almacenan y versionan en GIT, pero los usuarios no pueden trabajar simultáneamente en diferentes versiones. El resto de las entidades se almacenan en la base de datos.
Importante
Debido a su conexión a GIT, el nombre de las pantallas, los procesos legacy y lambda, los recursos, las ramas y las aplicaciones, así como la secuencia, la vista y el área visual de las pantallas no se pueden editar una vez creadas.
Cada vez que guardas cambios en una entidad almacenada en GIT, envías una confirmación al repositorio, que luego puedes visualizar en el historial de commits de esa entidad.
Al guardar la entidad, aparece un modal para que describas la actualización en pocas palabras y agregues el ID del ticket de Jira relacionado con esa corrección o mejora.
Cuando vinculas el commit de la entidad en la que estás trabajando al ticket de Jira, tú y tu equipo pueden realizar un seguimiento detallado de cada cambio. Esto proporciona un mejor control sobre lo que se incluye en cada versión de la aplicación.
Concurrencia
Es posible que haya más de un usuario intentando editar la misma entidad simultáneamente. Si otro usuario edita y guarda los cambios realizados en una entidad en la que estás trabajando, e intenta guardar los cambios en esa misma entidad, aparece un modal de advertencia que le informa de que no se han podido guardar los cambios. Esto sucede porque el otro usuario guardó los cambios antes que tú, por lo que la versión que estás editando actualmente queda obsoleta.
Recibes la misma advertencia de concurrencia cuando otro usuario hace rollback de una entidad a una versión anterior antes de que puedas guardar los cambios.
Puede cerrar la página de edición de la entidad o volver a la entidad. En cualquier caso, no podrás guardar ningún cambio y tendrás que abrir la última versión de la entidad de nuevo.
Importante
Esto solo se aplica a las entidades que fueron migradas a GIT.
La función Historial de commit te permite realizar los cambios aplicados a una entidad con facilidad y te da más control sobre lo que se incluye en cada actualización. También podrás descargar el archivo de .xml de los commits de la entidad seleccionada para ver en detalle las actualizaciones aplicadas dentro de cada commit. Además, si hay un error con la entidad y necesitas restaurarla a una versión anterior, está la opción Rollback que te permite restaurar el commit anterior de una entidad.
Importante
[en] Make sure you have permission to the Commit History and Rollback features in Studio. If you do not see the History option in Studio, contact your lead.
Para ver el historial de commits de una entidad, busca la entidad en Studio, haz clic en el icono vertical de tres puntos Más opciones y, a continuación , en Commit history.
Importante
Las características Historial de commit y Rollback solo están disponibles para pantallas, procesos legacy y lambda.
En la página Historial de commit, verás una lista de todas las confirmaciones enviadas al repositorio con la siguiente información:
Mensaje de commit: El mensaje que explica las actualizaciones aplicadas en este commit y el autor.
Hash: Identificador único interno de GIT del commit Este ID te permite buscar el commit dentro de GitLab.
Fecha de commit: Fecha en que se envió el commit al repositorio.
Puedes ordenar los commits por nombre (en orden alfabético) o por número haciendo clic en los íconos de flecha de orden. También puedes buscar un commit escribiendo el nombre o el autor en la barra de búsqueda.
Para inspeccionar los cambios aplicados a una entidad en un commit específico, haz clic en el ícono vertical de tres puntos situado junto al commit y haz clic en el ícono vertical de tres puntos situado junto al commit y selecciona.
Cómo hacer rollback a un commit anterior
Es posible que debas hacer rollback de una entidad (una pantalla o un proceso) a una versión anterior porque dichos cambios introdujeron un error en tu app o porque deseas analizar la entidad en una versión anterior. Para ello, ve a la página Historial de commits de la entidad. Busca el commit al que deseas restaurar la entidad, haz clic en el ícono vertical de tres puntos situado junto al comit y selecciona Rollback.
En el siguiente ejemplo, el usuario debe revertir una pantalla a un commit anterior para descartar una modificación en la posición de un botón. Para ello, el usuario hace clic en Rollback en un commit que introdujo un color nuevo en un botón.
Una vez que el usuario confirma el rollback, aparece un commit nuevo en la parte superior de la lista que indica que la entidad volvió a una versión anterior y qué versiones se ven afectadas, como se muestra a continuación.
El nombre del nuevo commit, es decir, el resultado del rollback, contiene el nombre de la entidad, el hash del commit seleccionada (los primeros 8 caracteres alfanuméricos) y el hash del commit de la versión restaurada (los primeros 8 caracteres alfanuméricos), como en el ejemplo anterior: "Entidad [nombre de la entidad] Rollback de la versión [hash de 8 caracteres] a la versión [hash de 8 caracteres].
[en] After the rollback, the user can navigate to the screen that contains the affected button and visualize that the component went back to its previous position.
Importante
Si intentas hacer rollback de una entidad a una versión anterior y esa entidad contiene un elemento que se ha eliminado, es posible que obtengas un error de reversión.
Si el elemento se ha eliminado de Studio pero aún persiste en GIT, no afectará el rollback.
Si el elemento se ha eliminado de GIT, se producirá un error en el rollback.