Exploración del modelo de rama de Git para la entrega continua

3 minutos

La entrega correcta de software depende de una estrategia de bifurcación que equilibre la velocidad, la calidad y la administración de riesgos. El objetivo es enviar mejoras rápidamente al tiempo que se mantiene la estabilidad de producción.

Equilibrio estratégico: velocidad frente a calidad

Un modelo de bifurcación eficaz debe alcanzar el equilibrio adecuado:

Minimice la sobrecarga del proceso para acelerar el tiempo de comercialización.
Mantener puertas de calidad para evitar que los defectos lleguen a la producción.
Habilite el desarrollo paralelo para la escalabilidad del equipo.
Soporte para el despliegue rápido de hotfixes para problemas críticos.

Aunque existen numerosas estrategias de bifurcación de Git, el enfoque más eficaz combina patrones probados con las necesidades específicas del equipo. Los equipos empresariales modernos suelen adoptar un modelo de desarrollo ligero basado en troncos centrado en ramas de características y solicitudes de cambios.

Principio fundamental: Rama principal siempre lista

Esta unidad le enseña a implementar un modelo de bifurcación listo para la entrega continua mediante ramas de características y solicitudes de cambios para mantener una rama principal que se pueda implementar de forma coherente.

Marco de estrategia de bifurcación empresarial

Los siguientes principios establecen una base sólida para la entrega continua:

Estabilidad de rama principal

Fuente única de la verdad: la rama principal es la ruta de acceso exclusiva para las versiones de producción.
Preparación para producción: la rama principal siempre debe estar en un estado desplegable.
Protección de rama: implemente directivas completas de rama para evitar confirmaciones directas.
Cambios gestionados: todas las modificaciones fluyen exclusivamente a través de pull requests.
Seguimiento de versiones: etiquete todas las versiones de producción con etiquetas de Git semánticas.

Disciplina de ramas de características

Desarrollo aislado: cree ramas dedicadas para todas las características y correcciones de errores.
Integración de marcas de características: administre características de larga duración con alternancias de características para reducir la duración de la rama.
Nomenclatura estratégica: use convenciones de nomenclatura descriptivas que reflejen el valor empresarial.
Flujo de trabajo de solicitud de cambios: fusione mediante combinación con la principal exclusivamente a través de solicitudes de cambios revisadas.

Estrategia de rama de versión

Preparación dedicada: cree ramas de lanzamiento a partir de puntos de integración de características estables.
Control de calidad: realice pruebas exhaustivas y estabilización en ramas de versión.
Endurecimiento de producción: aplique correcciones de errores finales y optimizaciones de rendimiento.
Seguimiento de hitos: marque hitos significativos de lanzamiento para asegurar la rastreabilidad.

Convenciones de nomenclatura para la escala de medición

# Bug fixes
bugfix/[ticket-id]-description
bugfix/AUTH-123-login-timeout

# Feature development
features/[area]/[feature-name]
features/authentication/oauth-integration
features/api/rate-limiting

# Hotfixes
hotfix/[severity]-description
hotfix/critical-payment-gateway

# Personal branches
users/[username]/[description]
users/john-doe/experimental-caching

Gestión de Pull Requests

Revisión de código obligatoria: no hay excepciones para las fusiones directas en Main.
Validación automatizada: integre canalizaciones de CI/CD para puertas de calidad.
Métricas de rendimiento: realice un seguimiento y optimice el tiempo de finalización de la solicitud de incorporación de cambios.
Compartición de conocimientos: Use revisiones para el aprendizaje en equipo y el cumplimiento de normas.

Requisitos previos y configuración

Herramientas esenciales para flujos de trabajo de Git empresariales

En este ejercicio práctico se aprovecha la cadena de herramientas completa de DevOps de Azure:

CLI de Azure: interfaz de línea de comandos nativa de la nube para los servicios de Azure.
CLI de Azure DevOps: extensión especializada para la integración directa de las herramientas git, CI/CD y Agile en Windows, Linux y macOS.

Configuración de la CLI de Azure DevOps

La CLI de Azure DevOps proporciona formato de salida flexible (JSON, YAML, table, TSV) para admitir varios escenarios de automatización. Configure el formato que prefiera mediante:

az devops configure --defaults output=table

Implementación Práctica: Flujo de Trabajo Empresarial de Git

En esta guía completa se muestra la ramificación de Git de nivel empresarial para la entrega continua, que abarca el desarrollo de funcionalidades, el despliegue de correcciones urgentes y la resolución de conflictos.

Paso 1: Creación y desarrollo de rama de función

Cree una rama de características siguiendo las convenciones de nomenclatura empresarial:

myWebApp

git checkout -b feature/myFeature-1

Salida:Cambiado a una nueva rama «feature/myFeature-1».

Compruebe el contexto de rama y el estado del árbol de trabajo:

myWebApp

git branch

Salida:✓ feature/myFeature-1

principal*

Paso 2: Implementación de características y control de versiones

Implemente los cambios de características:

myWebApp

# Edit your source files
code Program.cs  # Or your preferred editor

Siga el ciclo de vida de la confirmación completo:

myWebApp

git status

Resultado:On branch feature/myFeature-1Changes not staged for commit:

modificado: Program.cs*

myWebApp

git add .
git commit -m "feat: implement myFeature-1 with enhanced error handling"

Output:[feature/myFeature-1 70f67b2] feat: implementa myFeature-1 con un control mejorado de errores1 archivo cambiado, 1 inserción(+)

Publicar en el repositorio remoto:

myWebApp

git push -u origin feature/myFeature-1

Salida:To https://dev.azure.com/organization/teamproject/_git/MyWebApp

[new branch] feature/myFeature-1 -> feature/myFeature-1Branch feature/myFeature-1 set up to track remote branch feature/myFeature-1 from origin.

Paso 3: Configuración de la CLI de Azure DevOps y creación de pull requests

Configure Azure DevOps CLI para su organización y proyecto. Reemplace el nombre de la organización y de proyecto:

az devops configure --defaults organization=https://dev.azure.com/organization project="project name"

Cree una solicitud de incorporación de cambios (mediante la CLI de Azure DevOps) para revisar los cambios en la rama feature-1:

az repos pr create --title "Review Feature-1 before merging to main" --work-items 38 39 `
--description "#Merge feature-1 to main" `
--source-branch feature/myFeature-1 --target-branch main `
--repository myWebApp --open

Use el conmutador --open al generar el pull request para abrirlo en un navegador web después de crearlo. El --deletesource-branch conmutador se puede usar para eliminar la rama una vez completada la solicitud de pull. Además, considere la posibilidad de usar --auto-complete para completarse automáticamente cuando se hayan aprobado todas las políticas y la rama de origen pueda fusionarse en la rama de destino.

Nota

Para obtener más información sobre el parámetro az repos pr create, consulte Creación de una solicitud de incorporación de cambios para revisar y combinar código.

El equipo revisa conjuntamente los cambios de código y aprueba la solicitud de incorporación de cambios:

Captura de pantalla de la solicitud de cambios con los cambios de código aprobados y completados.

La rama principal está lista para su lanzamiento. El equipo etiqueta la rama principal con el número de versión:

Captura de pantalla de la creación de una etiqueta de ejemplo.

Paso 4: Desarrollo de características paralelas

Empiece a trabajar en feature-2. Cree una rama en el repositorio remoto desde la rama principal y realice la extracción del repositorio localmente:

myWebApp

git push origin main:refs/heads/feature/myFeature-2

Resultado:Total 0 (delta 0), reused 0 (delta 0) To https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [new branch] origin/HEAD -> refs/heads/feature/myFeature-2.

myWebApp

git checkout feature/myFeature-2

Resultado:Switched to a new branch 'feature/myFeature-2' Branch feature/myFeature-2 set up to track remote branch feature/myFeature-2 from origin.

Modifique Program.cs cambiando la misma línea de comentario en el código cambiado en feature-1:

```
public class Program
{
    // Editing the same line (file from feature-2 branch)
    public static void Main(string[] args)
    {
        BuildWebHost(args).Run();
    }

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>()
            .Build();
```

Paso 5: Escenario de solicitud de cambios para la característica 2 y corrección

Confirme los cambios localmente, envíelos al repositorio remoto y, luego, realice una solicitud de incorporación de cambios para combinar los cambios de feature/myFeature-2 en la rama principal:

az repos pr create --title "Review Feature-2 before merging to main" --work-items 40 42 `
--description "#Merge feature-2 to main" `
--source-branch feature/myFeature-2 --target-branch main `
--repository myWebApp --open

Se notifica un error crítico en producción en la versión feature-1 con la solicitud de incorporación de cambios en curso. Para investigar el problema, debe depurar con la versión de código implementada actualmente en producción. Para investigar el problema, cree una rama fof con la etiqueta release_feature1:

myWebApp

git checkout -b fof/bug-1 release_feature1

Salida:Se cambió a una nueva rama, 'fof/bug-1'.

Paso 6: Implementación crítica de parches urgentes

Modifique Program.cs cambiando la misma línea de código que cambió en la versión feature-1:

public class Program
{
    // Editing the same line (file from feature-FOF branch)
    public static void Main(string[] args)
    {
        BuildWebHost(args).Run();
    }

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>()
            .Build();

Agregue al "stage" y confirme los cambios localmente y, luego, envíe los cambios al repositorio remoto:

myWebApp

git add .
git commit -m "Adding FOF changes."
git push -u origin fof/bug-1

Resultado:To https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [new branch] fof/bug-1 - fof/bug-1 Branch fof/bug-1 set up to track remote branch fof/bug-1 from origin.

Paso 7: Integración de hotfixes y resolución de conflictos

Inmediatamente después de que los cambios se hayan implementado en producción, etiquete la rama fof_bug-1 con la etiqueta release_bug-1 y, después, realice una solicitud de incorporación de cambios para combinar los cambios de fof/bug-1 de nuevo en la rama principal:

az repos pr create --title "Review Bug-1 before merging to main" --work-items 100 `
--description "#Merge Bug-1 to main" `
--source-branch fof/Bug-1 --target-branch main `
--repository myWebApp --open

Como parte de la solicitud de incorporación de cambios, se elimina la rama. Aun así, todavía puede hacer referencia a todo el historial mediante la etiqueta.

Ahora que ya hemos realizado la corrección de errores críticos, revisemos la solicitud de incorporación de cambios de feature-2.

La página de ramas muestra claramente que la rama feature/myFeature-2 está un cambio por delante de la rama principal y dos por detrás de la rama principal:

Captura de pantalla de la página de ramas. la función myFeature two branches tiene dos cambios por delante de la principal y dos cambios por detrás de la principal.

Si ha intentado aprobar la solicitud de incorporación de cambios, verá un mensaje de error en el que se le informa de un conflicto de combinación:

Captura de pantalla de los conflictos de fusión mediante combinación a partir de la solicitud de cambios.

Resolución de conflictos de combinación

Para resolver conflictos de combinación, puede usar la interfaz web de Azure DevOps o resolverlos localmente mediante comandos de Git. Para la resolución local, actualice primero la rama de características con los cambios más recientes de la principal:

```CMD
git checkout feature/myFeature-2
git fetch origin
git merge origin/main
```

Resuelva los conflictos en el editor preferido y complete la combinación:

```CMD
git add .
git commit -m "Resolve merge conflicts between feature-2 and main"
git push origin feature/myFeature-2
```

Con los conflictos resueltos, la solicitud de incorporación de cambios se puede completar con éxito.

En este punto, puede crear una rama de versión basada en la corrección de errores críticos implementada en la rama fof/bug-1 y fusionada mediante combinación en la principal. Con el comando git checkout, cree una rama de versión dedicada desde la rama principal.

git checkout -b release/v1.1 main

Este comando crea una nueva rama denominada release/v1.1 basada en la rama principal.

A medida que se alcancen hitos significativos durante el proceso de publicación, etiquete las publicaciones en la rama de publicación mediante etiquetas Git. Las etiquetas sirven como marcadores para indicar versiones específicas del software.

git tag -a v1.1 -m "Release version 1.1"

Este comando crea una etiqueta llamada v1.1 para marcar la versión de lanzamiento 1.1 en la rama de lanzamiento.

Cómo funciona

Hemos aprendido la forma en que el modelo de rama de Git ofrece la flexibilidad de trabajar en las características en paralelo mediante la creación de una rama para cada característica.

El flujo de trabajo de solicitud de incorporación de cambios permite revisar los cambios en el código mediante las directivas de rama.

Las etiquetas de Git son una excelente manera de registrar hitos, como la versión del código publicado. Las etiquetas ofrecen una manera de crear ramas a partir de etiquetas.

Hemos creado una rama a partir de una etiqueta de versión anterior para corregir un error crítico en producción.

La vista de ramas del portal web facilita la identificación de las ramas situadas delante de la rama principal. Además, fuerza un conflicto de combinación si alguna solicitud de incorporación de cambios en curso intenta combinarse con la rama principal sin resolver los conflictos de combinación.

Un modelo de bifurcación lean permite crear ramas de corta duración y enviar cambios de calidad a producción con más rapidez.

Comentarios

¿Le ha resultado útil esta página?