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 administra a través de GitLab. Estas son algunas de las características claves de esta integración:
Construcción con ramas.Tú y tu equipo pueden trabajar en diferentes aspectos de la misma app en paralelo y luego ejecutar commits para evitar la implementación de cambios no deseados. También pueden crear ramas a partir de una rama productiva para solucionar problemas y probar las correcciones antes de aplicar cualquier cambio en la rama productiva, lo que garantiza la calidad de las correcciones implementadas.
Almacenamiento de entidades en GIT. Se pueden almacenar y versionar entidades como pantallas, procesos legacy y lambda, pruebas y recursos en GIT. Las librerías de función y los módulos también se almacenan y versionan en GIT, pero los usuarios no pueden trabajar simultáneamente en diferentes versiones. De esta forma, se obtiene una mejor trazabilidad de todos los cambios introducidos en las entidades a través del historial de commits, lo que elimina la necesidad de un archivo adicional para seguir esos cambios.
Control de versiones. Puedes tener un mejor control sobre lo que incluyes en cada versión de tu app, gracias a la información proporcionada sobre cada cambio introducido en una rama o una entidad almacenada en GIT. Mediante la integración con Jira, puedes tener un conocimiento más completo de los requisitos que llevaron a cada corrección o mejora. Además, puedes revisar fácilmente los cambios aplicados a una entidad revisando el historial de commits.
Rollback. Puedes restaurar tanto pantallas como procesos legacy y lambda a una versión o un commit anterior.
Cuando creas una app o un módulo en Studio, se crea una rama main por defecto. Se sugiere utilizar la rama main como una copia de la versión productiva y agregar etiquetas para cada versión publicada de esta rama. De esta manera, tienes un mejor control sobre lo que se incluye en cada versión de la app. Solo puedes agregar y ver etiquetas desde GitLab.
Luego, a medida que continúas trabajando en la app, puedes crear tantas ramas como sea necesario según el tipo de actualizaciones que necesites realizar y la estrategia de construcción con ramas y de entrega definidas con el cliente. Consulta la sección a continuación para conocer los tipos diferentes de ramas que puedes crear y sus usos.
Tipos de ramas
Puedes seleccionar entre cinco tipos diferentes de ramas según tus necesidades y la estrategia de construcción con 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 feature con el nombre "qr payments", el nombre completo será "feature/qr-payments" (tipo de rama/nombre de la rama).
Nota
Los espacios entre palabras en el nombre de la rama se reemplazan por guiones automáticamente.
Consulta la tabla a continuación para aprender sobre cada tipo de rama que puedes crear en Studio, sin importar tu estrategia de construcción con ramas.
Desarrollo | Tipo de rama desde donde se crean las ramas feature. La rama de desarrollo se crea inicialmente como una copia de la rama main y se modifica luego de cada actualización o corrección implementadas. Se puede usar para integrar y probar funcionalidades o correcciones nuevas antes de enviarlas a la versión productiva. Solo puede haber una rama de desarrollo por app o módulo. |
Feature | Tipo de rama creada para trabajar en una nueva funcionalidad. Una vez que la funcionalidad esté lista, puedes hacer merge entre la rama feature y una rama release para probarla junto con cualquier otra funcionalidad incluida en esa versión. Esto garantiza más control sobre los cambios que se enviarán a la versión productiva. |
Hotfix | Tipo de rama que sirve para corregir problemas o errores menores en apps productivas o en entornos de desarrollo. Según el tipo de corrección, se pueden crear desde la rama productiva o desde cualquier rama de desarrollo, si el problema aparece durante el proceso de desarrollo. Luego de probar las correcciones implementadas, debes hacer merge entre la rama hotfix y la rama de la que surgió, y los cambios también deben introducirse en cualquier otra rama afectada por la corrección. |
Release | Tipo de rama utilizada para integrar ramas feature y ejecutar una prueba completa de lo que se publicará luego. La rama release representa el paquete de versión que se entregará. |
Personalización | Tipo de 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. |
Consulta el artículo Branch Management para aprender cómo crear y eliminar ramas en Studio.
Administración de sesiones
En Studio 3.0, solo puedes trabajar con una rama de la app o del módulo a la vez con las mismas credenciales de usuario. Esto significa que no puedes editar dos ramas diferentes al mismo tiempo. Sigue leyendo para conocer cómo funcionan las sesiones en Studio 3.0.
Si estás trabajando en una rama en particular (sesión 1) e inicias una nueva sesión de Studio (sesión 2) con las mismas credenciales para acceder a la misma app pero a una rama diferente, la sesión 1 se bloquea y se deja inactiva, como se muestra a continuación.
Aparece un banner amarillo en el que se informa 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 queda inactiva y se bloquea su edición.
Aviso
Debes tener cuidado al desactivar una sesión, ya que podrías perder cualquier cambio pendiente, según las entidades en las que estés trabajando. Actualmente, puedes perder actualizaciones pendientes en cada entidad, excepto en los procesos lambda, las transacciones configurables y las 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 en simultáneo, debes iniciar sesión con 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 función 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 con GIT, el nombre de las pantallas, los procesos legacy y lambda, las pruebas, los recursos, las ramas y las apps, así como la secuencia, la vista y el área visual de las pantallas, no se pueden editar una vez creadas.
Cada vez que guardas los cambios en una entidad almacenada en GIT, envías un commit 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 identificador 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. De esta manera, tienes un mejor control sobre lo que incluyes en cada versión de la app.
Concurrencia
Es posible que haya más de un usuario intentando editar la misma entidad al mismo tiempo. Si otro usuario edita y guarda los cambios realizados en una entidad en la que estás trabajando, e intentas guardar los cambios en esa misma entidad, aparece un modal de advertencia en el que se informa 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 previa antes de que puedas guardar los cambios.
Puedes 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 almacenadas en GIT.
Con la funcionalidad Commit History, puedes revisar los cambios aplicados a una entidad con facilidad y tener más control sobre lo que se incluye en cada actualización. También puedes descargar el archivo .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 en la entidad y necesitas restaurarla a una versión anterior, existe una opción de Rollback con la que puedes restaurar el commit anterior de una entidad.
Importante
Asegúrate de tener permiso para usar las funcionalidades Commit History y Rollback en Studio. Si no ves la opción History en Studio, ponte en contacto con tu referente.
Para ver el historial de commits de una entidad, busca la entidad en Studio, haz clic en los tres puntos verticales de More options, y luego en History.
Importante
Las funcionalidades Commit History y Rollback solo están disponibles para pantallas y para procesos legacy y lambda.
En la página del historial de commits, puedes ver una lista de todos los commits enviados al repositorio con la siguiente información:
Commit message: mensaje en el que se explican las actualizaciones aplicadas en este commit.
Hash: identificador interno único de GIT del commit. Con este identificador, puedes buscar el commit dentro de GitLab.
Commit date: fecha en que se envió el commit al repositorio, y el autor.
Puedes ordenar los commits por nombre (en orden alfabético) o por número haciendo clic en los íconos de flecha de ordenación. 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 los tres puntos verticales ubicados al lado del commit y selecciona Download. Se descargará un archivo .xml a tu dispositivo, desde donde puedes analizar la entidad y ver las actualizaciones aplicadas.
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 hacerlo, dirígete a la página Commit History de la entidad. Busca el commit al que deseas restaurar la entidad, haz clic en los tres puntos verticales ubicados al lado del commit y selecciona Rollback.
En el ejemplo siguiente, el usuario debe hacer rollback de una pantalla a un commit anterior para descartar una modificación en la posición de un botón. Para hacerlo, el usuario hace clic en Rollback en un commit anterior que introdujo un color nuevo al botón, pero este componente se mantiene en su posición original.
Una vez que el usuario confirma el rollback, aparece un commit nuevo en la parte superior de la lista en el que se 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 commit nuevo, es decir, el resultado del rollback, contiene el nombre de la entidad, el hash del commit seleccionado (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 from version [hash de 8 caracteres] to version [hash de 8 caracteres]".
Luego del rollback, el usuario puede navegar a la pantalla que contiene el botón afectado y ver que el componente regresó a su posición anterior.
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 ocurra un error de rollback.
Si el elemento se eliminó de Studio pero aún se mantiene en GIT, el rollback no se verá afectado.
Si el elemento se eliminó de GIT, el rollback fallará.