¿Qué es un flujo de trabajo basado en versiones?
Aquí se explica cómo se puede crear un flujo de trabajo basado en versiones mediante GitHub.
¿Qué es un flujo de trabajo basado en versiones?
Un flujo de trabajo basado en versiones es un conjunto de patrones y directivas que se centran en las versiones de software. Aunque podría parecer un objetivo obvio para un equipo de desarrollo, este concepto tiene matices adicionales. En esta unidad se explica cómo impulsa tres partes diferentes del ciclo de versión: la administración del proyecto, la selección de una estrategia de rama y la publicación a los clientes.
Planificación del trabajo con paneles de proyecto de GitHub
Desde el punto de vista de la planificación, el hecho de centrarse en la versión conlleva dividir los problemas en diferentes iteraciones que producen una nueva versión. Estas iteraciones suelen denominarse sprints y se les aplica una duración fija en períodos prácticamente iguales para producir cambios incrementales. Otros equipos prefieren empaquetar versiones de lanzamiento completas en una sola iteración que puede durar unos meses o más. En GitHub, estas iteraciones se administran como proyectos.
La principal característica de un proyecto es su panel. El panel es el plan de registro central de la iteración y contiene todas las tarjetas que se van a resolver. Una tarjeta puede representar un problema, una solicitud de incorporación de cambios o incluso una simple nota genérica.
De forma predeterminada, cada tarjeta comienza en la columna Tareas pendientes y se mueve a En curso una vez que ha empezado el trabajo, para terminar en Listo. Es posible personalizar estas columnas, agregar otras o aplicar automatización al movimiento de las tarjetas y sus propiedades para que se adapten al proceso del equipo.
Obtenga más información sobre la administración de paneles de proyecto.
El estado del proyecto de la tarjeta se integra en todo el repositorio. Por ejemplo, si arrastra una tarjeta de Tareas pendientes a En curso, su estado cambia y se actualiza el indicador visual situado junto al título del proyecto. En la sección verde se indica la cantidad de las tarjetas con la indicación Listo, mientras que el color morado se usa para las tarjetas En curso. El espacio restante representa la cantidad de tarjetas pendientes de iniciarse. Además de arrastrar las tarjetas por el tablero, es posible actualizarlas desde la vista principal.
Al usar un panel de proyecto, todas las partes interesadas disponen de una forma sencilla de comprender el estado y la velocidad de un proyecto. También se pueden crear paneles que tengan como ámbito usuarios individuales o una colección de repositorios que pertenecen a una organización.
Obtenga más información sobre cómo realizar el seguimiento del progreso del trabajo con paneles de proyecto.
Seguimiento de hitos específicos
GitHub ofrece el seguimiento de hitos para equipos o subconjuntos de equipos.
Los hitos son similares al seguimiento de proyectos, en el sentido de que se hace hincapié en la resolución de los problemas y las solicitudes de incorporación de cambios en función de las prioridades. Sin embargo, aunque un proyecto puede centrarse en el proceso del equipo, un hito se centra en el producto.
Obtenga más información sobre cómo realizar el seguimiento del progreso del trabajo con hitos.
Selección de una estrategia de rama
Los repositorios en los que trabajan en paralelo varios desarrolladores necesitan una estrategia de rama bien definida. Si se establece un enfoque unificado al principio del proyecto, se evitan la confusión y la frustración a medida que el equipo y el código base escalan.
El flujo de GitHub
Además de ser una plataforma de desarrollo de software colaborativo, GitHub ofrece también un flujo de trabajo especificado diseñado para optimizar el uso de sus diversas características. Aunque GitHub puede funcionar con prácticamente cualquier proceso de desarrollo de software, se recomienda considerar la posibilidad de usar el flujo de GitHub si el equipo todavía no se estableció en un proceso.
Trabajo con ramas de larga duración
Una rama de larga duración es una rama de Git que nunca se elimina. Algunos equipos prefieren evitarlas a favor de la característica de corta duración y las ramas de corrección de errores. Para estos equipos, el objetivo de sus esfuerzos consiste en generar una solicitud de incorporación de cambios que combine su trabajo en main. Este enfoque puede resultar eficaz para proyectos que no tengan necesidades retrospectivas, como las aplicaciones web propias que no tengan que admitir versiones anteriores.
Aun así, hay algunos escenarios en los que una rama de larga duración resulta mucho más práctica para los intereses de un equipo. El caso más común de una rama de larga duración es cuando un producto tiene varias versiones que deben admitirse durante un período de tiempo prolongado. Cuando un equipo necesita planificarse para este compromiso, el repositorio debe seguir una convención estándar, como release-v1.0, release-v2.0, etc. Dichas ramas también se deben marcar como protegidas en GitHub, de modo que el acceso de escritura esté controlado y no se puedan eliminar accidentalmente.
Los equipos seguirán manteniendo main como rama raíz y combinarán los cambios de la rama de versión de manera ascendente, siempre y cuando se ajusten al futuro del proyecto. Cuando llegue el momento, release-v3.0 deberá basarse en main para que los trabajos de mantenimiento de release-v2.0 no compliquen el repositorio.
Mantenimiento de ramas de larga duración
Supongamos que se fusionó una corrección de errores en la rama release-v2.0 y, luego, se volvió a fusionar ascendentemente en main. Se descubrió más tarde que este error también existía en la rama release-v1.0 y que la corrección debía ser retroportada para los clientes que todavía usaban esa versión. ¿Cuál es la mejor manera de aplicar un parche anterior a esta corrección?
Combinar la rama main con release-v1.0 no sería una opción factible, ya que contendría un número considerable de commits que no estaban diseñados para formar parte de esa versión. Por la misma razón, la reorganización de release-v1.0 en la confirmación main actual tampoco sería una opción.
Otra opción sería volver a implementar manualmente la corrección en la rama release-v1.0, si bien este enfoque requeriría mucho trabajo y no escala bien en varias versiones. Pero Git ofrece una solución automatizada a este problema en forma de comando cherry-pick.
¿Qué es el comando cherry-pick de Git?
git cherry-pick es un comando que permite aplicar confirmaciones específicas de una rama a otra. Simplemente itera las confirmaciones seleccionadas y las aplica a la rama de destino como nuevas confirmaciones. Si es necesario, los desarrolladores pueden combinar los conflictos antes de completar la modificación.
Obtenga más información sobre el comando cherry-pick de Git.
Lanzamiento a los consumidores
Cuando una versión de producto está lista para su lanzamiento, GitHub simplifica el proceso de empaquetarla y notificar a los consumidores.
El proceso de crear una versión es tan sencillo como rellenar un formulario:
- Especifique una etiqueta de Git que quiera aplicar, que debe seguir Versionamiento Semántico, como
v1.0.2. GitHub administra el proceso de creación de la etiqueta Git que especifique. - Especifique un nombre para la versión. Estos son algunos procedimientos habituales:
- Usar un nombre descriptivo.
- Usar la versión de Git.
- Use un resumen conciso de cómo cambió la versión desde la anterior
- Usar un nombre de código o una frase aleatoria.
- Proporcione notas de la versión. Es posible automatizar esta tarea con la aplicación Release Drafter, que analiza los cambios desde la versión anterior e incluye los títulos de la solicitud de incorporación de cambios asociada.
- Si desea proporcionar archivos como parte de la versión (por ejemplo, instaladores precompilados), arrástrelos y colóquelos en el formulario. No es necesario empaquetar el origen, ya que GitHub se encarga de ello automáticamente.
- Para indicar si se trata de una versión preliminar, active la casilla en cuestión. Esta indicación ayuda a los clientes a evitar las versiones preliminares, en caso de que lo prefieran.
Una vez que se publica una versión, todos los usuarios que vean el repositorio recibirán una notificación.
Obtenga más información sobre las versiones de GitHub.