Esquemas de versionado
Pasos anteriores
Lee Definiciones e implementación de versionado para saber cuándo empezar a crear ramas en tu proyecto.
Existen dos esquemas estandarizados de versionado que pueden aplicarse al trabajar en Studio. El esquema basado en funcionalidades y el esquema unificado.
El esquema basado en funcionalidades fragmenta el desarrollo por funcionalidades. El desarrollo se organiza en ramas independientes por características, que luego se integran en una rama release. Se trata de un modelo más robusto y ordenado, recomendado para proyectos con evolución constante, múltiples funcionalidades en paralelo, grandes volúmenes de negocio o de alta rotación, y escenarios en los que los requisitos del cliente pueden cambiar con frecuencia y requieren una planificación flexible. Lee cómo implementar este esquema de versionado aquí.
El esquema trunk-based también se conoce como modelo de desarrollo unificado. Con este esquema, todo el desarrollo converge directamente en una rama común, sin separación previa por funcionalidades. Es más sencillo de aplicar y adecuado para equipos pequeños o proyectos con menos complejidad y variabilidad. Este modelo es más sencillo y consiste en una estrategia más lineal. Lee cómo implementar este esquema de versionado aquí.
Elegir el esquema adecuado dependerá del modelo de entrega, la madurez del equipo, los acuerdos con el cliente y la fase del proyecto. Sin embargo, el esquema elegido debe ser lo suficientemente flexible como para adaptarse a acontecimientos imprevisibles, como retrasos en el desarrollo y la entrega.
Sistema de versionado basado en funcionalidades
En el modelo de versionado basado en funcionalidades, el desarrollo se organiza teniendo una nueva funcionalidad por rama. Cada rama contiene los cambios necesarios para implantar una funcionalidad concreta, que luego se integran en una rama release común cuando se decide que esta funcionalidad está lista para entregarse.
Esta estrategia permite controlar con precisión las prestaciones que se entregan y su fecha de entrega. También proporciona una mayor trazabilidad y claridad en cuanto a los cambios incluidos en una versión.
Este régimen es adecuado para:
equipos medianos o grandes con perfiles de gestión definidos (desarrolladores, responsables técnicos y miembros encargados del lanzamiento);
proyectos con una evolución constante y un alto nivel de exigencia por parte de sus clientes (en auditoría y documentación); y
proyectos con funcionalidades que evolucionan en paralelo y tienen entregas que necesitan flexibilidad.
Estándares para versionar con un enfoque basado en funcionalidades
Estos estándares de versionado están diseñados para guiar a los usuarios hacia un enfoque de ramificación claro y estructurado a la hora de adoptar un esquema basado en funcionalidades.
Crea una rama feature por cada funcionalidad de la aplicación y una rama hotfix por cada error notificado.
Añade el número de ticket de JIRA a las ramas de funciones y revisiones. Además, puedes añadir una breve descripción de la funcionalidad o el arreglo. Esto ayudará a identificar fácilmente lo que contiene la rama.
Sugerencia
Si las correcciones están estrictamente relacionadas entre sí, puedes trabajar correcciones relacionadas en la misma rama y añadir una descripción y los números de ticket de JIRA.
Cómo generar ramas con el esquema de versiones basado en funcionalidades
¿Quién trabaja en la creación de ramas?
Las ramas de publicación deben ser creadas por el jefe de equipo o el miembro encargado de las publicaciones. Las ramas de funciones y revisiones pueden ser creadas por el responsable técnico, los miembros encargados de las versiones o cualquier desarrollador del equipo.
Sigue los pasos que se indican a continuación para empezar a crear ramas con el esquema de versionado basado en funcionalidades, en el que las ramas feature siempre derivan de una release previamente definida:
Importante
Por defecto, cada repositorio tiene una rama main. Trabaja en esta rama hasta que tengas una base funcional sólida que te permita empezar a fragmentar por funcionalidad, o hasta que tengas un conjunto de entregas para un cliente.
Crea una rama release.
Añade un nombre claro a la rama release. Puedes incluir el número de versión a entregar, el mes de entrega o cualquier alias definido con el cliente.
A partir de esta rama release, crea las ramas feature necesarias para empezar a fragmentar el desarrollo. También pueden crearse a medida que se detectan o solicitan nuevas funciones.
En cada rama de la función, incluye el ticket de JIRA vinculado a la función implementada y un nombre descriptivo breve.
Añade una descripción a cada rama feature. La descripción debe contener:
Nombre de la persona que trabaja en esa funcionalidad.
Alcance de la aplicación.
Cambios necesarios en la base de datos. Se incluirán en el mensaje del merge request.
Una vez fijada la fecha de entrega y lista la aplicación, integra los cambios. Para más detalles sobre el paso de integración, consulta Integración, y Resolución de conflictos si surge algún conflicto durante el paso de integración.
Una vez finalizada la etapa de integración, validadas las funcionalidades y entregada la versión al cliente, comienza un nuevo ciclo. Esto incluye crear una nueva rama release.
Importante
La nueva rama release debe crearse a partir de la rama release anterior, y debe incluir todos los cambios entregados previamente al cliente. Para comprobar que se está creando a partir de la rama correcta, compruebe que la rama de la versión anterior aparece en el campo de en la página Visión general de Studio.
Nota
Si se ha omitido alguna función en esta versión, puede incluirse en la siguiente.
En futuros ciclos, podría ser necesario corregir los errores detectados en la entrega anterior. Para ello, crea tantas ramas de hotfix como sea necesario, teniendo esto en cuenta:
Si la corrección es urgente, crea la rama hotfix a partir de la rama release entregada (es decir, la versión 1.0.0) y cree una nueva versión (es decir, la versión 1.0.1).
Si la corrección puede introducirse en la siguiente entrega, cree la rama hotfix a partir de la versión en curso (es decir, 1.1.0).
Utiliza la misma convención de nomenclatura que con las ramas release y feature, añadiendo un breve nombre descriptivo y el número de ticket de JIRA.
Lee Eliminar ramas para conocer los estándares sobre cómo eliminar las ramas después de una entrega.
Esquema de versionado unificado
En este modelo, todos los desarrollos se realizan en una sola rama (rama develop), sin separación por funcionalidad. Cuando se toma la decisión de entregar al cliente, se crea una rama release a partir de la rama develop, que contiene el estado actual de desarrollo.
Este enfoque pretende simplificar el proceso de versionado, reduciendo el número de ramas activas y minimizando el trabajo de gestión de ramas, beneficioso sobre todo para equipos pequeños.
El esquema unificado es adecuado para proyectos pequeños o medianos, que pueden coordinar fácilmente su trabajo; proyectos pequeños o medianos sin mucha evolución posterior a la entrega, con entregas funcionales fijadas estrechamente con el cliente, y bajos niveles de requisitos de auditoría.
Estándares para el control de versiones con un enfoque unificado
Estos estándares de versionado están diseñados para guiar a los usuarios hacia un enfoque de creación de ramas claro y estructurado a la hora de adoptar un esquema unificado.
Para mejorar la trazabilidad, se recomienda registrar en la descripción de cada rama de la versión los tickets de JIRA incluidos, junto con un resumen funcional. Esto permite un seguimiento más claro sin modificar la estructura de la rama.
Se sugiere trabajar continuamente en la rama develop, generar una rama release en el momento de una entrega a un cliente, probar en esa rama y, una vez aprobada, fusionar a la rama main.
Cómo generar ramas con el esquema de versionado unificado
¿Quién trabaja en la creación de ramas?
Las ramas de publicación deben ser creadas por el jefe de equipo o el gestor de publicaciones. Las ramas de funciones y revisiones pueden ser creadas por el responsable técnico, el gestor de versiones o cualquier desarrollador del equipo.
Lee a continuación un detalle paso a paso sobre cómo trabajar con un modelo de versionado unificado dentro de tu proyecto.
Importante
Por defecto, cada repositorio tiene una rama main. Trabaja en esta rama hasta que tengas una base funcional sólida que te permita empezar a fragmentar por funcionalidad, o hasta que tengas un conjunto de entregas para un cliente.
Crear una rama develop. Esta sucursal tendrá centralizado todo el trabajo diario.
Cuando llega el momento de entregar una funcionalidad al cliente, crea una rama release a partir de la rama develop. Esta rama se utiliza para realizar las pruebas correspondientes y se entrega al equipo de control de calidad para su certificación.
Mientras QA prueba la versión, los desarrolladores pueden reanudar el trabajo en la rama develop para incluir nuevas entregas.
El equipo de control de calidad puede detectar errores de la entrega anterior. Si es así, puedes arreglarlas teniendo esto en cuenta:
Si el fallo no es crítico, arréglalo directamente en la rama develop, para que forme parte de la próxima versión.
Si el fallo es crítico y requiere una solución inmediata, cree una rama de hotfix a partir de la versión afectada, corrija el fallo, pruébelo e intégrelo en la versión. Por último, entregue la versión corregida al equipo de control de calidad.
Para la rama hotfix, utilice la misma convención de nomenclatura que con las ramas de versiones y funciones, añadiendo un breve nombre descriptivo y el número de ticket de JIRA.
Una vez que la rama release pase a producción, intégrala en las ramas main y develop. La rama main refleja lo que se entregó al cliente, y la rama develop se mantendrá actualizada con cualquier corrección o cambio. Para más detalles sobre el paso de integración, consulta Integración, y Resolución de conflictos si surge algún conflicto durante el paso de integración.
Si necesitas generar una nueva versión cuando la versión anterior todavía se está validando (por ejemplo, cuando las pruebas están en cola o es necesario publicar un hotfix), crea la nueva versión desde develop y reinicia el ciclo desde el paso 1.