Resumen Requisitos previos y limitaciones Arquitectura Tools (Herramientas)Prácticas recomendadas Epics Resolución de problemas Recursos relacionados

Implementa una estrategia de ramificación de Gitflow para entornos de múltiples cuentas DevOps

Mike Stephens, Stephen DiCato, Abhilash Vinod y Tim Wondergem, Amazon Web Services

Resumen

Al administrar un repositorio de código fuente, las diferentes estrategias de ramificación afectan a los procesos de desarrollo y lanzamiento de software que utilizan los equipos de desarrollo. Algunos ejemplos de estrategias de ramificación habituales son Trunk, Gitflow y Flow. GitHub Estas estrategias utilizan diferentes ramificaciones y las actividades que se llevan a cabo en cada entorno son diferentes. Organismos que están implementando DevOps procesos se beneficiarían de una guía visual que les ayude a entender las diferencias entre estas estrategias de ramificación. El uso de este elemento visual en su organización ayuda a los equipos de desarrollo a alinear su trabajo y seguir los estándares de la organización. Este patrón proporciona este elemento visual y describe el proceso de implementación de una estrategia de ramificación de Gitflow en su organización.

Este patrón forma parte de una serie de documentos sobre la elección e implementación de estrategias de DevOps ramificación para organizaciones con múltiples sucursales. Cuentas de AWS Esta serie está diseñada para ayudarlo a aplicar la estrategia correcta y las prácticas recomendadas desde el principio, a fin de optimizar su experiencia en la nube. Gitflow es solo una posible estrategia de ramificación que su organización puede utilizar. Esta serie de documentación también cubre los modelos de ramificación de Trunk y GitHub Flow. Si aún no lo has hecho, te recomendamos que revises Cómo elegir una estrategia de ramificación de Git para DevOps entornos de múltiples cuentas antes de implementar la guía de este patrón. Utilice la diligencia debida para elegir la estrategia de ramificación adecuada para su organización.

En esta guía se proporciona un diagrama en el que se muestra cómo una organización podría implementar la estrategia de Gitflow. Se recomienda revisar la Guía de AWS DevOps Well-Architected para revisar las mejores prácticas. Este patrón incluye las tareas, los pasos y las restricciones recomendados para cada paso del DevOps proceso.

Requisitos previos y limitaciones

Requisitos previos

Git instalado. Se utiliza como herramienta de repositorio de código fuente.
Draw.io instalado. Esta aplicación se utiliza para ver y editar el diagrama.
(Opcional) Plugin de Gitflow instalado.

Arquitectura

Arquitectura de destino

El siguiente diagrama se puede usar como un cuadro de Punnett (Wikipedia). Alinee las ramas en el eje vertical con los AWS entornos en el eje horizontal para determinar qué acciones realizar en cada escenario. Los números indican la secuencia de las acciones del flujo de trabajo. En este ejemplo, se pasa de una ramificación de características a la implementación en producción.

Cuadro de Punnett de las actividades de Gitflow en cada ramificación y entorno.

Para obtener más información sobre los Cuentas de AWS entornos y las ramas en un enfoque de Gitflow, consulta Cómo elegir una estrategia de ramificación de Git para entornos de múltiples DevOps cuentas.

Automatización y escala

La integración y la entrega continuas (CI/CD) is the process of automating the software release lifecycle. It automates much or all of the manual processes traditionally required to get new code from an initial commit into production. A CI/CD pipeline encompasses the sandbox, development, testing, staging, and production environments. In each environment, the CI/CD pipeline provisions any infrastructure that is needed to deploy or test the code. By using CI/CD, development teams can make changes to code that are then automatically tested and deployed. CI/CDcanalizaciones) también proporcionan control y protección a los equipos de desarrollo, ya que refuerzan la coherencia, los estándares, las mejores prácticas y unos niveles mínimos de aceptación para la aceptación y el despliegue de las funciones. Para obtener más información, consulte Practicar la integración continua y la entrega continua en. AWS

AWS ofrece un conjunto de servicios para desarrolladores diseñados para ayudarle a crear CI/CD canalizaciones. Por ejemplo, AWS CodePipelinees un servicio de entrega continua totalmente gestionado que le ayuda a automatizar sus procesos de lanzamiento para obtener actualizaciones rápidas y fiables de las aplicaciones y la infraestructura. AWS CodeBuildcompila el código fuente, ejecuta pruebas y produce paquetes de ready-to-deploy software. Para obtener más información, consulte Herramientas para desarrolladores en AWS.

Tools (Herramientas)

AWS servicios y herramientas

AWS proporciona un conjunto de servicios para desarrolladores que puede utilizar para implementar este patrón:

AWS CodeArtifact es un servicio de repositorio de artefactos administrado y altamente escalable que lo ayuda a almacenar y compartir paquetes de software para el desarrollo de aplicaciones.
AWS CodeBuild es un servicio de compilación completamente administrado que le permite compilar código fuente, poner en marcha pruebas unitarias y producir artefactos listos para implementar.
AWS CodeDeployautomatiza las implementaciones en Amazon Elastic Compute Cloud EC2 (Amazon) o en instancias, AWS Lambda funciones locales o servicios de Amazon Elastic Container Service (Amazon ECS).
AWS CodePipeline permite diseñar y configurar rápidamente las diferentes etapas de un proceso de lanzamiento de software y automatizar los pasos necesarios para lanzar los cambios en el software de manera continua.

Otras herramientas

Draw.io Desktop es una aplicación para hacer diagramas y diagramas de flujo. El repositorio de código contiene plantillas en formato .drawio para Draw.io.
Figma es una herramienta de diseño en línea diseñada para la colaboración. El repositorio de código contiene plantillas en formato .fig para Figma.
(Opcional) El complemento de Gitflow es una colección de extensiones de Git que proporcionan operaciones de repositorio de alto nivel para el modelo de ramificación de Gitflow.

Repositorio de código

El archivo fuente del diagrama de este patrón está disponible en el GitFlow repositorio GitHub Git Branching Strategy for. Incluye archivos en los formatos PNG, draw.io y Figma. Puede modificar estos diagramas para respaldar los procesos de su organización.

Prácticas recomendadas

Siga las mejores prácticas y recomendaciones de AWS DevOps Well-Architected Guidance y Choosing a Git Branching Strategy for Multiaccount Environments. DevOps Estos recursos lo ayudan a implementar de manera efectiva el desarrollo basado en Gitflow, fomentar la colaboración, mejorar la calidad del código y agilizar el proceso de desarrollo.

Epics

Tarea	Descripción	Habilidades requeridas
Revisar el proceso estándar de Gitflow.	En el entorno de pruebas, el desarrollador crea una ramificación `feature` a partir de la ramificación `develop` y usa el patrón de nomenclatura `feature/<ticket>_<initials>_<short description>`. El desarrollador desarrolla el código y lo implementa en el entorno de pruebas de forma iterativa para completar el ticket. nota Si lo desea, el desarrollador puede crear una ramificación `sandbox` para ejecutar una canalización automatizada de compilación o implementación en el entorno de pruebas. El desarrollador crea una solicitud de fusión de la ramificación `feature` a la ramificación `develop` mediante una combinación de squash. Una canalización de integración y entrega continuas (CI/CD) crea e implementa automáticamente la ramificación `develop` en el entorno de desarrollo. (Opcional) Un desarrollador integra ramificaciones `feature` adicionales en la ramificación de desarrollo antes de continuar con las actividades de lanzamiento. Cuando tenga todo listo para lanzar las características de la ramificación `develop`, el desarrollador crea una ramificación `release` con el nombre `release/v<number>` a partir de la ramificación `develop`. El desarrollador crea la ramificación de lanzamiento, que publica los artefactos para reutilizarlos en otros entornos. Un aprobador aprueba manualmente la implementación de los artefactos de lanzamiento en el entorno de pruebas. Un aprobador aprueba manualmente la implementación de los artefactos de lanzamiento en el entorno de ensayo. Un aprobador aprueba manualmente la implementación de los artefactos de lanzamiento en el entorno de producción. El desarrollador combina la ramificación `release` en la ramificación `main`. Lo ideal es que el desarrollador utilice un script automatizado para llevar a cabo una combinación de avance rápido. No utilice una combinación de squash. El desarrollador combina la ramificación `release` en la ramificación `develop`. Lo ideal es que el desarrollador utilice un script automatizado para llevar a cabo una combinación de avance rápido. No utilice una combinación de squash.	DevOps ingeniero
Revisar el proceso de Gitflow de revisión.	El desarrollador crea una ramificación `hotfix` a partir de la ramificación `main` y usa el patrón de nomenclatura `hotfix/<ticket>_<initials>_<short description>`. El desarrollador crea una ramificación `release` a partir de la ramificación `main` y le asigna el nombre `release/v<number>`. El desarrollador corrige el problema, confirma la corrección y crea la ramificación `hotfix`. El desarrollador crea una solicitud de fusión de la ramificación `hotfix` a la ramificación `release/v<number>` mediante una combinación de squash. El desarrollador crea la ramificación `release`, que publica los artefactos para reutilizarlos en otros entornos. Un aprobador aprueba manualmente la implementación de los artefactos de lanzamiento en el entorno de pruebas. Un aprobador aprueba manualmente la implementación de los artefactos de lanzamiento en el entorno de ensayo. Un aprobador aprueba manualmente la implementación de los artefactos de lanzamiento en el entorno de producción. El desarrollador combina la ramificación `release` en la ramificación `main`. Lo ideal es que el desarrollador utilice un script automatizado para llevar a cabo una combinación de avance rápido. No utilice una combinación de squash. El desarrollador combina la ramificación `release` en la ramificación `develop`. Lo ideal es que el desarrollador utilice un script automatizado para llevar a cabo una combinación de avance rápido. No utilice una combinación de squash. Si se detecta un conflicto, los desarrolladores reciben una alerta y resuelven el conflicto con una solicitud de combinación.	DevOps ingeniero
Revisar el proceso de Gitflow de corrección.	El desarrollador crea una ramificación `bugfix` a partir de la ramificación `release/v<number>` actual y usa el patrón de nomenclatura `bugfix/<ticket number>_<developer initials>_<descriptor>`. El desarrollador corrige el problema, confirma la corrección y crea la ramificación `bugfix`. El desarrollador crea una solicitud de fusión de la ramificación `bugfix` a la ramificación `release/v<number>` mediante una combinación de squash. El desarrollador crea la ramificación `release`, que publica los artefactos para reutilizarlos en otros entornos. Un aprobador aprueba manualmente la implementación de los artefactos de lanzamiento en el entorno de pruebas. Un aprobador aprueba manualmente la implementación de los artefactos de lanzamiento en el entorno de ensayo. Un aprobador aprueba manualmente la implementación de los artefactos de lanzamiento en el entorno de producción. El desarrollador combina la ramificación `release` en la ramificación `main`. Lo ideal es que el desarrollador utilice un script automatizado para llevar a cabo una combinación de avance rápido. No utilice una combinación de squash. El desarrollador combina la ramificación `release` en la ramificación `develop`. Lo ideal es que el desarrollador utilice un script automatizado para llevar a cabo una combinación de avance rápido. No utilice una combinación de squash. Si se detecta un conflicto, los desarrolladores reciben una alerta y resuelven el conflicto con una solicitud de combinación.	DevOps ingeniero

Resolución de problemas

Problema	Solución
Conflictos de ramificaciones	Un problema común que puede producirse con el modelo de Gitflow es cuando es necesario llevar a cabo una revisión en producción, pero el cambio correspondiente debe producirse en un entorno inferior, en el que otra ramificación modifica los mismos recursos. Le recomendamos que solo tenga una ramificación de lanzamiento activa a la vez. Si tiene más de una ramificación activa a la vez, es posible que los cambios en los entornos colisionen y que no pueda pasar una ramificación a la fase de producción.
Fusión	Las versiones deben volver a combinarse con las principales y desarrollarse lo antes posible para volver a consolidar el trabajo en las ramificaciones principales.
Combinación de squash	Use una combinación de squash solo cuando vaya a combinar de una ramificación `feature` a una ramificación `develop`. El uso de combinaciones de squash en ramificaciones superiores causa dificultades al volver a combinar cambios en las ramificaciones inferiores.

Recursos relacionados

En esta guía no se incluye capacitación sobre Git; sin embargo, hay muchos recursos de alta calidad disponibles en Internet si necesita esta capacitación. Le recomendamos que comience con el sitio de documentación de Git.

Los siguientes recursos pueden ayudarlo con su proceso de ramificaciones de Gitflow en la Nube de AWS.

AWS DevOps orientación

Gitflow guidance