Implemente una estrategia GitHub de ramificación de Flow para entornos de cuentas múltiples DevOps - Recomendaciones de AWS

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Implemente una estrategia GitHub de ramificación de Flow para entornos de cuentas múltiples DevOps

Mike Stephens y Abhilash Vinod, 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 comunes son Trunk, GitHub Flow y Gitflow. 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 esta imagen y describe el proceso de implementación de una estrategia de ramificación de GitHub Flow 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 mejores prácticas desde el principio, a fin de optimizar su experiencia en la nube. GitHub El flujo es solo una posible estrategia de ramificación que su organización puede utilizar. En esta serie de documentación también se cubren los modelos de ramificación de Trunk y Gitflow. 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.

Esta guía proporciona un diagrama que muestra cómo una organización podría implementar la estrategia GitHub Flow. 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.

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 feature a la implementación en producción.

Cuadro de Punnett de las actividades de GitHub Flow en cada sucursal y entorno.

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

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.

Repositorio de código

El archivo fuente del diagrama de este patrón está disponible en el repositorio GitHub Git Branching Strategy for GitHub Flow. 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 Eligiendo una estrategia de ramificación de Git para entornos de múltiples cuentas. DevOps Te ayudan a implementar de forma eficaz el desarrollo GitHub basado en Flow, a fomentar la colaboración, a mejorar la calidad del código y a agilizar el proceso de desarrollo.

Epics

TareaDescripciónHabilidades requeridas

Revise el proceso GitHub de flujo estándar.

  1. En el entorno de pruebas, el desarrollador crea una ramificación feature a partir de la ramificación main y usa el patrón de nomenclatura feature/<ticket>_<initials>_<short description>.

  2. El desarrollador agrega una o más confirmaciones a la ramificación feature, cada una de las cuales representa un cambio o mejora distintos.

  3. El desarrollador abre una solicitud de combinación (MR) para combinar los cambios en la ramificación main. Esto inicia un proceso de revisión.

  4. Durante el proceso de revisión, los desarrolladores analizan los cambios en el código y proporcionan comentarios. El objetivo es garantizar que los cambios sean de alta calidad y cumplan con los estándares del proyecto.

  5. Una vez que el desarrollador crea la solicitud de combinación, se inicia un proceso de compilación automatizado que implementa los cambios de la ramificación feature en el entorno de desarrollo.

  6. Las pruebas automatizadas verifican la integridad y la calidad de los cambios incluidos en la solicitud de combinación. Para completar la solicitud de combinación, es necesario que la compilación, la implementación y las pruebas se lleven a cabo correctamente.

  7. Cuando se completa el proceso de revisión, los cambios se combinan en la ramificación main.

  8. Un aprobador aprueba manualmente la implementación de los artefactos de lanzamiento en el entorno de pruebas.

  9. Un aprobador aprueba manualmente la implementación de los artefactos de lanzamiento en el entorno de ensayo.

  10. Un aprobador aprueba manualmente la implementación de los artefactos de lanzamiento en el entorno de producción.

DevOps ingeniero

Revise el proceso de corrección de errores GitHub Flow.

  1. El desarrollador crea una ramificación bugfix a partir de la ramificación main y usa el patrón de nomenclatura bugfix/<ticket number>_<developer initials>_<descriptor>.

  2. El desarrollador corrige el problema, confirma la corrección y crea la ramificación bugfix.

  3. El desarrollador abre una solicitud de combinación para combinar la ramificación bugfix en la ramificación main. Esto inicia un proceso de revisión.

  4. Durante el proceso de revisión, los desarrolladores analizan los cambios en el código y proporcionan comentarios.

  5. Tras la finalización y la aprobación de la revisión, el desarrollador completa la solicitud de combinación de la ramificación bugfix en la ramificación main.

  6. Un aprobador aprueba manualmente la implementación de los artefactos de lanzamiento en entornos superiores.

DevOps ingeniero

Revise el proceso de hotfix GitHub Flow.

GitHub Flow está diseñado para permitir una entrega continua, donde los cambios de código se implementan de manera frecuente y confiable en entornos superiores. La clave es que todas las ramificaciones feature se puedan implementar en cualquier momento.

Las ramificaciones Hotfix, que son similares a las ramificaciones feature o bugfix, pueden seguir el mismo proceso que cualquiera de estas otras ramificaciones. Sin embargo, dada su urgencia, las revisiones suelen tener una prioridad más alta. En función de las políticas del equipo y de la inmediatez de la situación, algunos pasos del proceso podrían acelerarse. Por ejemplo, es posible acelerar las revisiones del código de las revisiones. Por lo tanto, si bien el proceso de revisión es paralelo al proceso de corrección o características, la urgencia que rodea a las revisiones puede justificar modificaciones en el cumplimiento del procedimiento. Es fundamental establecer directrices sobre la administración de las revisiones para garantizar que se gestionen de forma eficiente y segura.

DevOps ingeniero

Resolución de problemas

ProblemaSolución

Conflictos de ramificaciones

Un problema común que puede producirse con el modelo GitHub Flow es cuando es necesario realizar una revisión en la producciónfeature, bugfix pero el cambio correspondiente debe producirse en una hotfix rama o sucursal en la que se modifican los mismos recursos. Le recomendamos que combine con frecuencia los cambios de main en las ramificaciones inferiores para evitar conflictos importantes al llevar a cabo la combinación con main.

Consolidación del equipo

GitHub Flow fomenta las implementaciones diarias en entornos más altos y adopta una verdadera integración y entrega continuas (CI/CD). Es imprescindible que el equipo cuente con la consolidación en materia de ingeniería que se necesita para desarrollar características y crear pruebas de automatización para ellas. El equipo debe llevar a cabo una revisión exhaustiva de las solicitudes de combinación antes de aprobar los cambios. Esto fomenta una cultura de ingeniería sólida que promueve la calidad, la responsabilidad y la eficiencia en el proceso de desarrollo.

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 en su proceso de expansión de GitHub Flow en el. Nube de AWS

AWS DevOps orientación

GitHub Guía de flujo

Otros recursos