Seleccione sus preferencias de cookies

Usamos cookies esenciales y herramientas similares que son necesarias para proporcionar nuestro sitio y nuestros servicios. Usamos cookies de rendimiento para recopilar estadísticas anónimas para que podamos entender cómo los clientes usan nuestro sitio y hacer mejoras. Las cookies esenciales no se pueden desactivar, pero puede hacer clic en “Personalizar” o “Rechazar” para rechazar las cookies de rendimiento.

Si está de acuerdo, AWS y los terceros aprobados también utilizarán cookies para proporcionar características útiles del sitio, recordar sus preferencias y mostrar contenido relevante, incluida publicidad relevante. Para aceptar o rechazar todas las cookies no esenciales, haga clic en “Aceptar” o “Rechazar”. Para elegir opciones más detalladas, haga clic en “Personalizar”.

Preferencias
Contacte con nosotros
Comentarios
AWS Documentation
Cree una cuenta AWS
Implemente una estrategia GitHub de ramificación de Flow para entornos de cuentas múltiples DevOps - Recomendaciones de AWS
ResumenRequisitos previos y limitacionesArquitecturaHerramientasPrácticas recomendadasEpicsSolución de problemasRecursos relacionados

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.

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

PDF

Creado por Mike Stephens (AWS) y Abhilash Vinod (AWS)

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, GitHub Flow y Gitflow. Estas estrategias utilizan diferentes ramas y las actividades que se realizan 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. Esta serie de documentación también cubre 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. Usa la diligencia debida para elegir la estrategia de ramificación adecuada para tu 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 utilizar como un cuadrado 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 feature sucursal 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 .

Automatizar y escalar

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 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 canalizaciones de CI/CD. 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.

Herramientas

AWS servicios y herramientas

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

  • AWS CodeArtifactes un servicio de repositorio de artefactos gestionado y altamente escalable que le ayuda a almacenar y compartir paquetes de software para el desarrollo de aplicaciones.

  • AWS CodeBuildes un servicio de compilación totalmente gestionado que le ayuda a compilar código fuente, ejecutar pruebas unitarias y producir artefactos listos para su despliegue.

  • 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 CodePipelinele ayuda a modelar y configurar rápidamente las diferentes etapas de una versión de software y a automatizar los pasos necesarios para publicar los cambios de software de forma continua.

Otras herramientas

  • Draw.io Desktop es una aplicación para hacer diagramas de flujo y diagramas. El repositorio de código contiene plantillas en formato.drawio para Draw.io.

  • Figma es una herramienta de diseño online 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 sandbox, el desarrollador crea una feature rama a partir de la main rama y utiliza el patrón feature/<ticket>_<initials>_<short description> de nomenclatura.

  2. El desarrollador agrega una o más confirmaciones a la feature rama, cada una de las cuales representa un cambio o mejora discretos.

  3. El desarrollador abre una solicitud de fusión (MR) para combinar los cambios en la main rama. 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 fusión, se inicia un proceso de creación automatizado que implementa los cambios de la feature rama en el entorno de desarrollo.

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

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

  8. Un aprobador aprueba manualmente el despliegue de los artefactos de lanzamiento en el entorno de pruebas.

  9. Un aprobador aprueba manualmente el despliegue de los artefactos de lanzamiento en el entorno provisional.

  10. Un aprobador aprueba manualmente el despliegue 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 bugfix rama a partir de la main rama y usa el patrón bugfix/<ticket number>_<developer initials>_<descriptor> de nomenclatura.

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

  3. El desarrollador abre una solicitud de fusión para fusionar la bugfix rama en la main rama. 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. Una vez finalizada la revisión y aprobación, el desarrollador completa la solicitud de fusión de la bugfix sucursal con la main sucursal.

  6. Un aprobador aprueba manualmente el despliegue 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 feature sucursales se puedan implementar en cualquier momento.

Hotfixlas sucursales, que son similares a feature o bugfix sucursales, pueden seguir el mismo proceso que cualquiera de estas otras sucursales. 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 que se aceleren 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 de funciones o errores, la urgencia que rodea a las revisiones puede justificar modificaciones en el cumplimiento del procedimiento. Es fundamental establecer directrices sobre la gestión de las revisiones para garantizar que se gestionen de forma eficiente y segura.

DevOps ingeniero

Revisión de los GitHub flujos de trabajo de Flow

TareaDescripciónHabilidades requeridas

Revise el proceso GitHub de flujo estándar.

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

  2. El desarrollador agrega una o más confirmaciones a la feature rama, cada una de las cuales representa un cambio o mejora discretos.

  3. El desarrollador abre una solicitud de fusión (MR) para combinar los cambios en la main rama. 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 fusión, se inicia un proceso de creación automatizado que implementa los cambios de la feature rama en el entorno de desarrollo.

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

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

  8. Un aprobador aprueba manualmente el despliegue de los artefactos de lanzamiento en el entorno de pruebas.

  9. Un aprobador aprueba manualmente el despliegue de los artefactos de lanzamiento en el entorno provisional.

  10. Un aprobador aprueba manualmente el despliegue 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 bugfix rama a partir de la main rama y usa el patrón bugfix/<ticket number>_<developer initials>_<descriptor> de nomenclatura.

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

  3. El desarrollador abre una solicitud de fusión para fusionar la bugfix rama en la main rama. 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. Una vez finalizada la revisión y aprobación, el desarrollador completa la solicitud de fusión de la bugfix sucursal con la main sucursal.

  6. Un aprobador aprueba manualmente el despliegue 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 feature sucursales se puedan implementar en cualquier momento.

Hotfixlas sucursales, que son similares a feature o bugfix sucursales, pueden seguir el mismo proceso que cualquiera de estas otras sucursales. 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 que se aceleren 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 de funciones o errores, la urgencia que rodea a las revisiones puede justificar modificaciones en el cumplimiento del procedimiento. Es fundamental establecer directrices sobre la gestión de las revisiones para garantizar que se gestionen de forma eficiente y segura.

DevOps ingeniero

Solución de problemas

ProblemaSolución

Conflictos de sucursales

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. Se recomienda combinar con frecuencia los cambios de main las ramas inferiores para evitar conflictos importantes al realizar la fusión. main

Madurez del equipo

GitHub Flow fomenta las implementaciones diarias en entornos superiores y adopta una verdadera integración y entrega continuas (CI/CD). Es imprescindible que el equipo tenga la madurez en ingeniería necesaria para desarrollar funciones y crear pruebas de automatización para ellas. El equipo debe realizar una revisión exhaustiva de las solicitudes de fusión antes de que se aprueben 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

Esta guía no incluye formación sobre Git; sin embargo, hay muchos recursos de alta calidad disponibles en Internet si necesitas esta formación. Te recomendamos que comiences por el sitio de documentación de Git.

Los siguientes recursos pueden ayudarte en tu viaje hacia la ramificación de GitHub Flow en el Nube de AWS.

AWS DevOps orientación

GitHub Guía de flujo

Otros recursos

¿Necesita ayuda?

PrivacidadTérminos del sitioPreferencias de cookies
© 2025, Amazon Web Services, Inc o sus afiliados. Todos los derechos reservados.