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.

Diferencias de los procesos de CI/CD completos

Las canalizaciones de CI/CD utilizan un flujo de trabajo moderno basado en enlaces troncales, en el que los desarrolladores fusionan las actualizaciones pequeñas y frecuentes en una rama principal (o enlace troncal) que se crea y prueba a través de la parte de CD de la canalización de CI/CD. Este flujo de trabajo ha sustituido al flujo de trabajo de Gitflow, en el que las ramas de desarrollo y lanzamiento están separadas por una programación de lanzamiento. En muchas organizaciones, Gitflow sigue siendo un método popular de control de versiones e implementación. Sin embargo, ahora se considera heredado y su integración en una canalización de CI/CD puede resultar difícil.

Para muchas organizaciones, la transición de un flujo de trabajo de Gitflow a un flujo de trabajo basado en enlaces troncales no se ha completado, y el resultado es que se quedan estancadas en algún momento y nunca migran completamente a la CI/CD. De alguna manera, las canalizaciones acaban aferrándose a algunos remanentes del flujo de trabajo heredado, atrapados en un estado de transición entre el pasado y el presente. Revise las diferencias en los flujos de trabajo de Git y obtenga información sobre cómo el uso de un flujo de trabajo heredado puede afectar a lo siguiente:

Para facilitar la identificación de los remanentes de un flujo de trabajo de Git heredado en una configuración moderna, comparemos Gitflow con el enfoque moderno basado en enlaces troncales.

Enfoque de Gitflow

En la siguiente imagen se muestra un flujo de trabajo de Gitflow. El enfoque de Gitflow usa múltiples ramas para hacer un seguimiento de varias versiones diferentes del código al mismo tiempo. Se programan los lanzamientos de actualizaciones de una aplicación para algún momento en el futuro mientras los desarrolladores siguen trabajando en la versión actual del código. Los repositorios basados en enlaces troncales pueden usar marcadores de características para lograrlo, pero está integrado en Gitflow de forma predeterminada.

Uno de los resultados del enfoque de Gitflow es que los entornos de las aplicaciones no suelen estar sincronizados. En una implementación estándar de Gitflow, los entornos de desarrollo reflejan el estado actual del código, mientras que los entornos de preproducción y producción permanecen inmóviles en función del estado del código base desde la versión más reciente.

Esto complica las cosas cuando aparece un defecto en el entorno de producción, ya que el código base con el que trabajan los desarrolladores no se puede fusionar con el entorno de producción sin exponer características que no se hayan lanzado. La forma en que Gitflow maneja esta situación es mediante una revisión. Se crea una rama de revisiones a partir de la rama de lanzamiento y, a continuación, se implementa directamente en los entornos posteriores. Luego, la rama de revisiones se fusiona con la rama de desarrollo para mantener el código actualizado.

Enfoque basado en enlaces troncales

En la siguiente imagen se muestra un flujo de trabajo basado en enlaces troncales. En un flujo de trabajo basado en enlaces troncales, los desarrolladores crean y prueban características de forma local en una rama de características y, a continuación, combinan esos cambios en la rama principal. Luego, la rama principal se adapta a los entornos de desarrollo, preproducción y producción, de forma secuencial. Las pruebas unitarias y de integración se llevan a cabo entre cada entorno.

Con este flujo de trabajo, todos los entornos funcionan con el mismo código base. No es necesaria ninguna rama de revisiones para los entornos superiores, ya que se pueden implementar cambios en la rama principal sin exponer características que no se hayan lanzado. Siempre se supone que la rama principal es estable, no tiene defectos y está lista para su lanzamiento. Esto lo ayuda a integrarla como origen para una canalización de CI/CD, que puede probar e implementar automáticamente el código base en todos los entornos de la canalización.