Compartir a través de

Elección de una estrategia de creación de ramas con una perspectiva de DevOps

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

¿Tiene pensado adoptar DevOps mediante el Control de versiones de Team Foundation (TFVC) con Azure DevOps? Probablemente tenga algunas preguntas, como las siguientes:

  • ¿Cómo se puede decidir la estrategia de creación de ramas correcta?
  • ¿Existe una estrategia eficaz para DevOps?
  • ¿Cómo se admiten las aplicaciones con una o varias versiones?

TFVC es un sistema de control de versiones centralizado que permite mantener el código y hacer que los equipos sean más eficaces. Proporciona colaboración y un uso compartido del código, publicación y características de revisión coherentes.

Hágalo sencillo.

Al adoptar una estrategia de creación de ramas eficaz, hará lo siguiente:

  • Fomentar una cultura de DevOps.
  • Promover el flujo de colaboración y aumentar la productividad.
  • Permitir que los equipos dediquen más tiempo al desarrollo y menos tiempo a la administración de código.

Para adoptar DevOps, es importante simplificar la estrategia de ramas y esforzarse por obtener una calidad alta. Algunas sugerencias:

  • Comience con una estrategia sencilla y evolucione según sea necesario.
  • Use convenciones de nomenclatura coherentes para ramas
    • features/username/description para el trabajo que haya realizado una persona, por ejemplo, features/sandra/sdk-java
    • bugfix/username/bugid para el trabajo realizado específico de un error de ingeniería, por ejemplo, bugfix/takashi/707
    • releases/version para versiones planeadas, por ejemplo, releases/V1.00
  • Realice con frecuencia la integración inversa (RI) y combine en la rama principal.
  • Fomente revisiones de código coherentes: incluir elementos no utilizados, excluir elementos no utilizados.
  • Implemente una canalización de CI/CD mediante lo siguiente:
    • Inserciones en el repositorio controladas
    • Pruebas automatizadas

Inicio con una estrategia de creación de ramas sencilla

Cree una estructura de control de código fuente que identifique las unidades de versión que pueden enviarse. El concepto de unidades que pueden lanzarse es una parte fundamental de esta estrategia, que Steve St Jean describe de la siguiente manera:

  • Unidad física de control de versiones y entrega.
  • Unidad principal para admitir los modelos de creación de ramas y versiones.
  • Puede estar en el nivel de conjunto, de aplicación o de componente.
  • Para Conjuntos, todas las aplicaciones deben aplicar revisiones y realizar versiones conjuntas. Por ejemplo, Microsoft Word y Excel forman parte del conjunto de Microsoft Office. Por el contrario, Visio no, ya que puede publicarse o aplicar revisiones independientemente del resto del conjunto de Microsoft Office.
  • En TFVC, este sería el nodo raíz en el nodo del proyecto de equipo.
  • Se puede equiparar a un repositorio en Git.

Normalmente, empieza por tener que admitir solo una versión de producción, con correcciones de defectos y desarrollo de nuevas características en paralelo. Entre los ejemplos típicos se incluyen sitios web, aplicaciones de línea de negocio corporativas y herramientas provisionales.

Comience con la sencilla estrategia de creación de ramas de tipo solo principal.

diagrama de rama inicial

Automatice la compilación para que se desencadene con cada inserción en la rama principal, ejecute pruebas automatizadas y, si se ejecuta correctamente, implemente la versión en un entorno de desarrollo.

Rama Build Entornos Notas
Método Main CI_Bld Desarrollo Se desencadena con cada inserción en la principal

Cuando complete un ciclo de versión, cree una rama de versión. Use la rama de versión para estabilizar la versión y continuar el desarrollo de la siguiente versión en principal. Realice una integración inversa (RI) y combine correcciones de errores validadas con la rama principal con frecuencia, para minimizar la deuda técnica general.

Se publica la versión 1.0

Automatice la compilación y la versión para lo siguiente:

  • Desencadenar con cada inserción en la rama de versión
  • Ejecutar pruebas automatizadas
  • Implementar para el desarrollo y otros entornos
Rama Build Pipelines Notas
Método Main CI_Bld Desarrollo Se desencadena con cada inserción en la principal
V1.00 RC_Bld Desarrollo -> QA -> UAT -> Almacenamiento provisional -> Producción Se desencadena con cada inserción que se va a lanzar

Cuando la versión 2 se convierte en la Versión candidata para lanzamiento, puede actualizar la canalización de compilación de RC existente para que apunte a la rama V2.00. Ahora se compilará y lanzará igual que hacía la versión V1.00 cuando era la versión actual.

Rama Build Pipelines Notas
Método Main CI_Bld Desarrollo Se desencadena con cada inserción en la principal
V2.00 RC_Bld Desarrollo -> QA -> UAT -> Almacenamiento provisional -> Producción Se desencadena con cada inserción que se va a lanzar
V1.00 Hotfix_Bld Corrección -> Almacenamiento provisional -> Producción Se desencadena con cada inserción para la corrección

Expansión de la estrategia de creación de ramas según sea necesario

Cuando surge la necesidad de admitir más de una versión de producción, por ejemplo, una solución comercial como Word, puede expandir la estrategia de creación de ramas.

Para cada ciclo de versión completado, debe admitir, crear una nueva rama de versión y continuar con el desarrollo de la versión siguiente en la rama principal, mediante el aislamiento de características. Fíjese en las combinaciones de integración inversa (RI) de v1.0 y v2.0 a principal. Representan correcciones de errores que se publican en producción.

Se publica la versión 2.0

Mediante el uso de una estrategia de creación de ramas sencilla y la adopción de una convención de nomenclatura coherente, podrá admitir lo siguiente:

  • Aplicaciones que tienen una o varias versiones compatibles
  • Desarrollo continuo de nuevas características
  • Entrega continua de valor a los usuarios

Lista de comprobación y lecciones sobre el terreno

Lista de comprobación

  • Haga la creación de ramas sencilla y aumente la complejidad según sea necesario.
  • Organice el código en unidades que se puedan enviar.
  • Use una estrategia de nomenclatura coherente para las ramas.
  • Compile con todas las inserciones.
  • Cree una canalización de CI/CD mediante inserciones en el repositorio controladas y pruebas automatizadas.

Lecciones sobre el terreno: cosas a evitar

  • Evite tener demasiadas ramas.
    • La combinación de cambios incluye complejidad y costos
    • No es necesario tener una rama independiente por entorno
  • Evite usar la selección exclusiva para pasar el código a producción.
  • No intente resolver problemas relacionados con personas o procesos con herramientas.