Cómo implementar un flujo de trabajo de rama de tarea

El proceso comienza con una tarea en tu rastreador de problemas o sistema de gestión de proyectos: Jira, Bugzilla, Mantis, OnTime o tu propia solución interna. La clave aquí es que todo lo que hagas debe tener una tarea asociada. No importa si es parte de una nueva función o una corrección de errores: crea una tarea para ello.

A continuación, creas una rama para esa tarea.

Recomendamos una convención de nomenclatura de ramas sencilla: Un prefijo (“tarea” en el ejemplo) seguido del número de tarea en el rastreador de problemas. Esto te ayuda a mantener una trazabilidad completa de los cambios.

Trabaja en la rama de la tarea y haz tantas confirmaciones como sea necesario. Explica cada paso en los comentarios para proporcionar claridad a cualquier revisor.

Cuando la tarea esté terminada, establece un atributo de “estado” en la rama como “resuelto”.

Alternativamente, puedes marcarla como completada en tu rastreador de problemas. Todo depende de tu conjunto de herramientas particular y de cómo realmente terminarás implementando el flujo de trabajo.

Una vez que marques tu tarea como completada, puede ser revisada por un colega.

Ahora es el turno del revisor de mirar tus cambios y ver si puede detectar errores, fallos o inconsistencias en tu estilo de codificación, o cualquier aspecto del diseño que deba ser cambiado. Si es así, la tarea se reabrirá y el ciclo se reinicia.

La validación es un paso opcional.

Algunos equipos “validarán” la tarea: otro miembro del equipo realizará una prueba exploratoria corta para asegurarse de que la nueva función o cambio tenga sentido. No buscan errores (las pruebas automatizadas se encargan de eso), sino que analizan el cambio desde la perspectiva del cliente. El estado puede establecerse como “validado” en el atributo.

Configura tu sistema de integración continua (CI) para monitorear todas las ramas que tengan un atributo dado establecido. Una rama solo será considerada por el sistema CI cuando alcance un estado dado (en este caso, “validado”).

Una vez que la tarea sea revisada/validada, la rama de la tarea se prueba automáticamente antes de ser fusionada en la principal.

Si la suite de pruebas pasa la fusión, será confirmada y enviada al sistema CI para construir y probar. Este proceso ayuda a prevenir romper la construcción. Si falla, el proceso se reiniciará y tendrás que rebasear desde main para resolver cualquier conflicto.

Si las pruebas pasan, la fusión se registra y la rama está lista para ser entregada. Nota que el estado ahora está configurado como "fusionado".

Si la nueva versión está lista para ser desplegada, el nuevo conjunto de cambios en main se etiqueta como tal y el software se despliega en producción.

Puedes obtener una nueva versión después de que cada nueva tarea pase por este ciclo, o puedes decidir agrupar algunas. Al practicar el despliegue continuo, desplegar cada tarea en producción es el flujo de trabajo más lógico.

Con Unity Version Control, el paso de pruebas automatizadas y fusión se puede configurar usando el complemento para tu herramienta CI elegida, como Jenkins, Bamboo o Unity Cloud Build.

Este paso también se puede orquestar utilizando la función mergebot de Unity Version Control. El mergebot puede fusionar las ramas y activar una construcción para asegurarse de que funcione. Las fusiones se confirman solo si la construcción es buena, evitando construcciones rotas.

Nos gusta seguir la siguiente convención de nombres: prefijo + número de tarea. Por ejemplo, las ramas pueden llamarse tarea1213, tarea1209 y tarea1221. El prefijo es "tarea", y el número representa el número de tarea real en el rastreador de problemas asociado.

La captura de pantalla también muestra una descripción para cada rama junto con el número, ya que el explorador de ramas recupera el número del rastreador de problemas. También puedes ver la descripción de la rama seleccionando "mostrar información de tarea de rama".

Las reglas de Scrum establecen que las tareas no deben durar más de 16 horas. Esta práctica mantiene los plazos del proyecto bajo control.

Las ramas de tarea deben cerrarse rápidamente. Idealmente, deberías tener muchas tareas pequeñas que puedas cerrar en solo unas pocas horas. Esta estructura ayuda a mantener el ritmo de tu proyecto y facilita el despliegue continuo. Una tarea más grande que se extiende por una semana, por ejemplo, detiene el ciclo.

Una señal de alerta a tener en cuenta: No crees tareas de "corte de machete". Si necesitas dividir una tarea en piezas más pequeñas, asegúrate de que la tarea aún tenga sentido de forma aislada y pueda ser desplegada de forma independiente.

Los flujos de trabajo de ramas de tarea solo pueden tener éxito con la aceptación de todo el equipo.

Como cualquier proceso de DevOps, hay un componente cultural en este flujo de trabajo. Las ramas de tarea se tratan de comunicar abiertamente el progreso y evitar silos. Antes de imponer un flujo de trabajo o una forma particular de trabajar con tareas, necesitas buscar la alineación. Ayuda a los miembros del equipo a entender los beneficios de cerrar una pequeña parte de una tarea más grande hoy, en lugar de luchar con tareas más grandes durante más tiempo.

Pregúntate a ti mismo (o a tus compañeros de equipo): ¿Realmente necesitas el código que acabas de terminar en tarea1213 para comenzar tarea1209?

Las tareas tienden a ser mucho más independientes de lo que podrías pensar. Sí, pueden estar en el mismo tema, pero no necesitas tocar exactamente el mismo código. Simplemente puedes agregar algo nuevo y confiar en que la fusión hará su trabajo.

Supongamos que 1213 y 1209 en el ejemplo anterior eran correcciones de errores en lugar de tareas. No quieres que una dependa de la otra. Quieres que lleguen a la rama principal y se liberen lo más rápido posible. Incluso si tocan el mismo código, son correcciones diferentes.

Cada incorporación debe ayudar al revisor a seguir tu línea de pensamiento y proceso para entender cómo abordaste la tarea.

Dejar detalles en los comentarios de tu incorporación ayudará al revisor, ya que no necesitarán comparar toda la rama. En su lugar, compararán cambio por cambio. Y seguirán la explicación grabada que hiciste para aclarar cada etapa de la tarea. No se encontrarán mirando una lista extensa de más de 100 archivos modificados. En su lugar, irán paso a paso.

Cada rama de tarea debe estar lista para integrarse una vez finalizada. Si un cambio es frágil o hará que el producto se comporte de manera extraña, entonces la tarea no debería considerarse finalizada.

Este es un pequeño precio a pagar por los beneficios de la automatización. El equipo debe alinearse en la definición de "hecho", que significa "listo para producción". A cambio, puedes disfrutar de la tranquilidad sabiendo que mover tu tarea a producción es fácil, totalmente automatizado y no llevará a una situación de emergencia a las 2:00 am.

¿Qué son los toggles de características? Estos son críticos para el despliegue continuo. Esta técnica de desarrollo de software permite probar características antes de que estén completas y listas para su lanzamiento.

Un toggle de características puede ocultar, habilitar o deshabilitar la característica durante el tiempo de ejecución. Te permite habilitar una característica solo para el equipo de desarrollo, un pequeño número de adoptantes tempranos o para todos. Por ejemplo, un desarrollador puede habilitar una característica para pruebas y deshabilitarla para otros usuarios durante el desarrollo.

Veamos un ejemplo. Tienes una gran característica dividida en siete partes que se convertirán en tareas e implementarán utilizando ramas de tareas. ¿Cómo es posible desplegar la Parte 4 si nada más está listo?

La Parte 4 puede ser fusionada con la rama principal e incluso desplegada mientras aún está oculta usando un toggle de características.

Oculto no significa que el nuevo código omita las pruebas antes del lanzamiento. Cuando toda la característica esté lista para ser activada, las partes individuales ya habrán sido probadas varias veces. La integración de la última pieza no desencadenará una fusión de gran explosión; es solo una parte más pequeña que pasa a la principal.