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.
Beneficios de un enfoque basado en enlaces troncales para la integridad del entorno
Como muchos desarrolladores saben, un cambio en el código a veces puede provocar un efecto mariposa
Cuando los científicos llevan a cabo un experimento, separan a los sujetos de prueba en dos grupos: el grupo experimental y el grupo de control. La intención es hacer que el grupo experimental y el grupo de control sean completamente idénticos, excepto en lo que respecta a lo que se prueba en el experimento. Cuando ocurre algo en el grupo experimental que no ocurre en el grupo de control, la única causa puede ser lo que se está probando.
Piense en los cambios de una implementación como el grupo experimental y piense en cada entorno como grupos de control independientes. Los resultados de las pruebas en un entorno inferior solo son fiables cuando los controles son los mismos que en un entorno superior. Cuanto más se desvíen los entornos, mayor será la probabilidad de descubrir defectos en los entornos superiores. En otras palabras, si los cambios en el código van a fallar en producción, preferimos que fallen antes en la versión beta para que nunca lleguen a la fase de producción. Por este motivo, se debe hacer todo lo posible para mantener sincronizados todos los entornos, desde el entorno de prueba más bajo hasta el propio entorno de producción. Esto se denomina integridad del entorno.
El objetivo de cualquier proceso de CI/CD completo es detectar los problemas lo antes posible. Preservar la integridad del entorno mediante un enfoque basado en enlaces troncales puede eliminar prácticamente la necesidad de revisiones. En un flujo de trabajo basado en enlaces troncales, es poco frecuente que un problema aparezca por primera vez en el entorno de producción.
En un enfoque de Gitflow, una vez que una revisión se implementa directamente en los entornos superiores, se agrega a la rama de desarrollo. Esto preserva la solución para futuras versiones. Sin embargo, la revisión se desarrolló y probó directamente a partir del estado actual de la aplicación. Incluso si la revisión funciona perfectamente en producción, existe la posibilidad de que surjan problemas cuando interactúe con las características más nuevas de la rama de desarrollo. Como no suele ser deseable implementar una revisión para una revisión, esto hace que los desarrolladores dediquen más tiempo a intentar adaptar la revisión al entorno de desarrollo. En muchos casos, esto puede generar una importante deuda técnica y reducir la estabilidad general del entorno de desarrollo.
Cuando se produce un error en un entorno, se revierten todos los cambios para que el entorno vuelva a su estado anterior. Cualquier cambio en el código base debería volver a iniciar la canalización desde la primera etapa. Cuando surge un problema en el entorno de producción, la solución también debería pasar por todo el proceso. El tiempo adicional que se tarda en pasar por los entornos más bajos suele ser insignificante en comparación con los problemas que se evitan con este enfoque. Como el único propósito de los entornos inferiores es detectar los errores antes de que lleguen a producción, eludir estos entornos mediante un enfoque de Gitflow es un riesgo ineficiente e innecesario.
