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. # Estrategia de ramificación de Gitflow Gitflow es un modelo de ramificación que implica el uso de múltiples ramas para mover el código del desarrollo a la producción. Gitflow funciona bien para los equipos que tienen ciclos de lanzamiento programados y que necesitan definir un conjunto de funciones como versión. El desarrollo se completa en ramas de funciones individuales que se fusionan, previa aprobación, en una rama de desarrollo, que se utiliza para la integración. Las funciones de esta rama se consideran listas para su producción. Cuando todas las funciones planificadas se han acumulado en la rama de desarrollo, se crea una rama de lanzamiento para las implementaciones en los entornos superiores. Esta separación mejora el control sobre qué cambios se trasladan a cada entorno determinado según un cronograma definido. Si es necesario, puede acelerar este proceso y convertirlo en un modelo de implementación más rápido. Para obtener más información sobre la estrategia de ramificación de Gitflow, consulta los siguientes recursos: + [Implementa una estrategia de ramificación de Gitflow para entornos con varias cuentas DevOps ](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/implement-a-gitflow-branching-strategy-for-multi-account-devops-environments.html) (guía prescriptiva)AWS + [The original Gitflow blog](https://nvie.com/posts/a-successful-git-branching-model/) (entrada en el blog de Vincent Driessen) + [Gitflow workflow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) (Atlassian) **Topics** + [Descripción visual de la estrategia de Gitflow](visual-overview-of-the-gitflow-strategy.md) + [Las ramificaciones en una estrategia de Gitflow](branches-in-a-gitflow-strategy.md) + [Ventajas y desventajas de la estrategia de Gitflow](advantages-and-disadvantages-of-the-gitflow-strategy.md) # Descripción visual de la estrategia de Gitflow El siguiente diagrama puede usarse como un cuadro de [Punnett](https://en.wikipedia.org/wiki/Punnett_square) para entender la estrategia de ramificación de Gitflow. Alinee las ramas del eje vertical con los AWS entornos del eje horizontal para determinar qué acciones realizar en cada escenario. Los números encerrados en un círculo te guían por la secuencia de acciones representada en el diagrama. Para obtener más información sobre las actividades que se llevan a cabo en cada entorno, consulte [DevOps los entornos](understanding-the-devops-environments.md) en esta guía. ![\[Cuadro de Punnett con las actividades de Gitflow en cada sucursal y entorno\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/choosing-git-branch-approach/images/gitflow-diagram.png) # Las ramificaciones en una estrategia de Gitflow Una estrategia de ramificación de Gitflow suele tener las siguientes ramas. ![\[Las ramas y los entornos de una estrategia de ramificación de Gitflow.\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/choosing-git-branch-approach/images/gitflow-branching-strategy.png) ## rama de característica `Feature`las sucursales son ramas a corto plazo en las que se desarrollan funciones. La `feature` rama se crea al ramificarse a partir de la `develop` rama. Los desarrolladores iteran, confirman y prueban el código de la `feature` rama. Cuando la función está completa, el desarrollador la promociona. Solo hay dos caminos hacia adelante desde una rama de funciones: + Incorpórese a la `sandbox` rama + Crea una solicitud de fusión en la `develop` sucursal | | | | --- |--- | | Convención de nomenclatura: | `feature/__` | | Ejemplo de convención de nomenclatura: | `feature/123456_MS_Implement_Feature_A` | ## rama sandbox La `sandbox` rama es una rama no estándar y de corto plazo para Gitflow. Sin embargo, es útil para el desarrollo de CI/CD canalizaciones. La `sandbox` rama se utiliza principalmente para los siguientes fines: + Realice una implementación completa en el entorno sandbox mediante las CI/CD canalizaciones en lugar de una implementación manual. + Desarrolle y pruebe una canalización antes de enviar solicitudes de fusión para realizar pruebas completas en un entorno inferior, como el de desarrollo o las pruebas. `Sandbox`las sucursales son de naturaleza temporal y no están destinadas a ser duraderas. Deben borrarse una vez finalizadas las pruebas específicas. | | | | --- |--- | | Convención de nomenclatura: | `sandbox/__` | | Ejemplo de convención de nomenclatura: | `sandbox/123456_MS_Test_Pipeline_Deploy` | ## desarrollar una rama La `develop` sucursal es una rama de larga duración en la que las funciones se integran, crean, validan e implementan en el entorno de desarrollo. Todas las `feature` sucursales se fusionan en la `develop` sucursal. Las fusiones en la `develop` sucursal se realizan mediante una solicitud de fusión que requiere una compilación correcta y la aprobación de dos desarrolladores. Para evitar que se eliminen, habilita la protección de sucursales en la `develop` rama. | | | | --- |--- | | Convención de nomenclatura: | `develop` | ## rama de lanzamiento En Gitflow, las `release` ramas son ramas a corto plazo. Estas ramas son especiales porque puedes desplegarlas en múltiples entornos, adoptando la metodología de construir una vez y desplegar muchas veces. `Release`las sucursales pueden centrarse en los entornos de prueba, puesta en escena o producción. Una vez que un equipo de desarrollo ha decidido promover funciones en entornos superiores, crea una nueva `release` rama y utiliza un aumento del número de versión con respecto a la versión anterior. En las puertas de cada entorno, las implementaciones requieren aprobaciones manuales para poder llevarse a cabo. `Release`las sucursales deberían requerir que se modifique una solicitud de fusión. Una vez que la `release` rama se haya implementado en producción, se debe volver a fusionar con las `main` ramas `develop` y para garantizar que las correcciones de errores o revisiones se fusionen de nuevo en futuras iniciativas de desarrollo. | | | | --- |--- | | Convención de nomenclatura: | `release/v{major}.{minor}` | | Ejemplo de convención de nomenclatura: | `release/v1.0` | ## rama principal La `main` rama es una rama de larga duración que siempre representa el código que se está ejecutando en producción. El código se fusiona automáticamente en la `main` rama desde una rama de lanzamiento tras una implementación correcta desde el proceso de publicación. Para evitar la eliminación, habilita la protección de la rama en la `main` rama. | | | | --- |--- | | Convención de nomenclatura: | `main` | ## rama de corrección de errores La `bugfix` rama es una rama a corto plazo que se utiliza para solucionar problemas en las ramas de lanzamiento que no se han lanzado al mercado de producción. Una `bugfix` rama solo debe usarse para promover correcciones en las `release` sucursales para los entornos de prueba, preparación o producción. Una `bugfix` sucursal siempre se ramifica a partir de una `release` sucursal. Una vez que se haya probado la corrección del error, se puede ascender a la `release` rama mediante una solicitud de fusión. A continuación, puedes impulsar la `release` rama siguiendo el proceso de publicación estándar. | | | | --- |--- | | Convención de nomenclatura: | `bugfix/__` | | Ejemplo de convención de nomenclatura: | `bugfix/123456_MS_Fix_Problem_A` | ## rama de hotfix La `hotfix` sucursal es una rama a corto plazo que se utiliza para solucionar problemas en la producción. Solo se utilizará para promover soluciones que deben acelerarse para que lleguen al entorno de producción. Siempre se `hotfix` ramifica una sucursal desde. `main` Una vez que se haya probado la revisión, puedes pasarla a producción mediante una solicitud de fusión en la `release` rama desde la que se creó. `main` Para realizar las pruebas, puedes impulsar la `release` rama siguiendo el proceso de publicación estándar. | | | | --- |--- | | Convención de nomenclatura: | `hotfix/__` | | Ejemplo de convención de nomenclatura: | `hotfix/123456_MS_Fix_Problem_A` | # Ventajas y desventajas de la estrategia de Gitflow La estrategia de ramificación de Gitflow se adapta bien a equipos más grandes y distribuidos que tienen requisitos estrictos de publicación y cumplimiento. Gitflow contribuye a un ciclo de lanzamiento predecible para la organización, algo que suelen preferir las organizaciones más grandes. Gitflow también es ideal para equipos que necesitan barreras para completar su ciclo de vida de desarrollo de software de forma adecuada. Esto se debe a que la estrategia incorpora múltiples oportunidades de revisión y control de calidad. Gitflow también es ideal para equipos que deben mantener varias versiones de versiones de producción simultáneamente. Algunas desventajas GItflow son que es más complejo que otros modelos de ramificación y requiere un estricto cumplimiento del patrón para completarlos con éxito. Gitflow no funciona bien para las organizaciones que buscan una entrega continua debido a la naturaleza rígida de la gestión de las ramas de lanzamiento. Las ramas de publicación de Gitflow pueden ser ramas duraderas que pueden acumular deudas técnicas si no se gestionan adecuadamente y de manera oportuna. ## Ventajas El desarrollo basado en Gitflow ofrece varias ventajas que pueden mejorar el proceso de desarrollo, agilizar la colaboración y mejorar la calidad general del software. Los siguientes son algunos de los beneficios clave: + **Proceso de publicación predecible**: Gitflow sigue un proceso de publicación regular y predecible. Es ideal para equipos con cadencias de desarrollo y lanzamiento regulares. + **Colaboración mejorada**: Gitflow fomenta el uso de sucursales `feature` y `release` sucursales. Estas dos ramas ayudan a los equipos a trabajar en paralelo con una dependencia mínima entre sí. + **Muy adecuado para múltiples entornos**: Gitflow usa `release` ramas, que pueden ser ramas de mayor duración. Estas sucursales permiten a los equipos centrarse en los lanzamientos individuales durante un período de tiempo más largo. + **Varias versiones en producción**: si tu equipo admite varias versiones del software en producción, las `release` sucursales de Gitflow admiten este requisito. + **Revisiones de calidad del código integradas**: Gitflow exige y fomenta el uso de revisiones y aprobaciones del código antes de promocionarlo a otro entorno. Este proceso elimina las fricciones entre los desarrolladores al requerir este paso para todas las promociones de código. + **Beneficios organizativos**: Gitflow también tiene ventajas a nivel organizativo. Gitflow fomenta el uso de un ciclo de lanzamiento estándar, lo que ayuda a la organización a entender y anticipar el calendario de lanzamientos. Como la empresa ahora sabe cuándo se pueden ofrecer nuevas funciones, se reducen las fricciones con respecto a los plazos, ya que hay fechas de entrega establecidas. ## Desventajas El desarrollo basado en Gitflow tiene algunas desventajas que pueden afectar al proceso de desarrollo y a la dinámica del equipo. Los siguientes son algunos inconvenientes notables: + **Complejidad**: Gitflow es un patrón complejo que deben aprender los nuevos equipos, y debes seguir las reglas de Gitflow para usarlo con éxito. + **Despliegue continuo**: Gitflow no se ajusta a un modelo en el que muchas implementaciones se lanzan a producción de forma rápida. Esto se debe a que Gitflow requiere el uso de varias sucursales y un flujo de trabajo estricto que regule la sucursal. `release` + **Administración de sucursales**: Gitflow utiliza muchas sucursales, lo que puede resultar engorroso de mantener. Puede resultar difícil rastrear las distintas ramas y fusionar el código publicado para mantener las ramas correctamente alineadas entre sí. + **Deuda técnica**: dado que las versiones de Gitflow suelen ser más lentas que los otros modelos de ramificación, es posible que se acumulen más funciones antes de publicarlas, lo que puede provocar que se acumule deuda técnica. Los equipos deberían considerar detenidamente estos inconvenientes a la hora de decidir si el desarrollo basado en Gitflow es el enfoque adecuado para su proyecto.