El proceso comienza con una tarea en su sistema de seguimiento de problemas o de gestión de proyectos: Jira, Bugzilla, Mantis, OnTime o su 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 característica o una corrección de errores: cree una tarea para ello.

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

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

Trabaje en la rama de tareas y realice tantos checkins como sea necesario. Explique cada paso en los comentarios para proporcionar claridad a cualquier revisor.

Cuando finalice la tarea, establezca un atributo de “estado” en la rama como “resuelto”.

Alternativamente, puede marcarlo como completado en su rastreador de problemas. Todo depende de su conjunto de herramientas particular y de cómo terminará implementando el flujo de trabajo.

Una vez que marques tu tarea como completada, un colega podrá revisarla.

Ahora es el turno del revisor de revisar sus cambios y ver si puede detectar errores, fallas o inconsistencias en su estilo de codificación, o cualquier aspecto del diseño que deba cambiarse. Si es así, la tarea se volverá a abrir y el ciclo se reiniciará.

La validación es un paso opcional.

Algunos equipos “validarán” la tarea: otro miembro del equipo realizará una breve prueba exploratoria para asegurarse de que la nueva característica o el 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 se puede establecer como “validado” en el atributo.

Configure su sistema de integración continua (CI) para monitorear todas las sucursales que tengan un conjunto de atributos determinado. El sistema CI solo considerará una rama cuando alcance un estado determinado (en este caso, “validada”).

Una vez que se revisa/valida la tarea, la rama de la tarea se prueba automáticamente antes de fusionarse con la principal.

Si el conjunto de pruebas pasa la fusión, se confirmará y se enviará al sistema CI para compilarlo y probarlo. Este proceso ayuda a evitar romper la construcción. Si falla, el proceso se reiniciará y tendrás que volver a basarlo desde el principal para resolver cualquier conflicto.

Si las pruebas pasan, se registra la fusión y la rama ahora está lista para ser entregada. Observe que el estado ahora está establecido en “fusionado”.

Si la nueva versión está lista para implementarse, el nuevo conjunto de cambios en el servidor principal se etiqueta como tal y el software se implementa 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 la implementación continua, implementar cada tarea en producción es el flujo de trabajo más lógico.

Con Unity Version Control, el paso de prueba y fusión automatizadas se puede configurar usando el complemento para la 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 compilación para asegurarse de que funcione. Las fusiones se confirman solo si la compilación es buena, evitando compilaciones rotas.

Nos gusta seguir la siguiente convención de nomenclatura: prefijo + número de tarea. Por ejemplo, las ramas podrían 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 de 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 la tarea de la rama”.

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

Las ramas de tareas deben cerrarse rápidamente. Lo ideal es que tengas muchas tareas pequeñas que puedas cerrar en tan solo unas horas. Esta estructura ayuda a mantener el ritmo de su proyecto y facilita la implementación continua. Una tarea más grande que dure una semana, por ejemplo, detiene el ciclo.

Una señal de alerta a tener en cuenta: No cree tareas de “corte de machete”. Si necesita dividir una tarea en partes más pequeñas, asegúrese de que la tarea aún tenga sentido de forma aislada y pueda implementarse de forma independiente.

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

Como cualquier proceso de DevOps, este flujo de trabajo tiene un componente cultural. Las ramas de tareas tienen como objetivo comunicar abiertamente el progreso y evitar silos. Antes de imponer un flujo de trabajo o una forma particular de trabajar con las tareas, es necesario impulsar la alineación. Ayude a los miembros del equipo a comprender 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úntese a usted mismo (o a sus compañeros de equipo): ¿Realmente necesitas el código que acabas de terminar en la tarea 1213 para iniciar la tarea 1209?

Las tareas tienden a ser mucho más independientes de lo que uno piensa. Sí, puede que estén sobre el mismo tema, pero no es necesario que toquen exactamente el mismo código. Puedes simplemente agregar algo nuevo y confiar en que la fusión hará su trabajo.

Supongamos que 1213 y 1209 en el ejemplo anterior fueran correcciones de errores en lugar de tareas. No quieres que uno dependa del otro. Quieres que lleguen al nivel principal y se liberen lo más rápido posible. Incluso si tocan el mismo código, son soluciones diferentes.

Cada registro debe ayudar al revisor a seguir su línea de pensamiento y proceso para comprender cómo abordó la tarea.

Dejar detalles en los comentarios de tu check-in ayudará al revisor, ya que no necesitará comparar toda la rama. En lugar de eso, compararán los cambios conjunto por conjunto de cambios. Y seguirán la explicación pregrabada que hiciste para aclarar cada etapa de la tarea. No se encontrarán mirando una lista completa de más de 100 archivos modificados. Más bien, 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 debe considerarse finalizada.

Es un pequeño precio a pagar por los beneficios de la automatización. El equipo debe estar de acuerdo con la definición de “terminado”, que significa “listo para la producción”. A cambio, usted podrá disfrutar de la tranquilidad de saber que trasladar su tarea a producción es fácil, está totalmente automatizado y no provocará un simulacro de incendio a las 2:00 a. m.

¿Qué son los conmutadores de funciones? Estos son fundamentales para la implementación continua. Esta técnica de desarrollo de software permite probar las características antes de que estén completas y listas para su lanzamiento.

Un interruptor de función puede ocultar, habilitar o deshabilitar la función durante el tiempo de ejecución. Le permite habilitar una función solo para el equipo de desarrollo, una pequeña cantidad de usuarios pioneros o para todos. Por ejemplo, un desarrollador puede habilitar una función para probarla y deshabilitarla para otros usuarios durante el desarrollo.

Veamos un ejemplo. Tiene una gran característica dividida en siete partes que se convertirán en tareas y se implementarán mediante ramas de tareas. ¿Cómo es posible implementar la Parte 4 si no hay nada más listo?

La parte 4 se puede fusionar con la rama principal e incluso implementar mientras aún está oculta usando un interruptor de función.

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