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.
# Cuán completamente diferentes son los CI/CD procesos
Las canalizaciones de CI/CD utilizan un *flujo de trabajo moderno basado en enlaces troncales*, en el que los desarrolladores combinan las actualizaciones pequeñas y frecuentes en una rama principal (o *troncal*) que se crea y prueba a través de la parte de CD de la canalización. 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 puede resultar difícil. CI/CD
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:
+ [Integridad del entorno](environment-integrity.md)
+ [Versiones](releases.md)
+ [Seguridad](security.md)
Para facilitar la identificación de los remanentes de un flujo de trabajo de Git heredado en una configuración moderna, comparemos [Gitflow](#gitflow-approach) con el enfoque moderno basado en [enlaces troncales](#trunk-based-approach).
## 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.
![\[Flujo de trabajo de Gitflow con ramas de características, desarrollo, lanzamiento y revisiones\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/strategy-cicd-litmus/images/gitflow-workflow.png)
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.
![\[Flujo de trabajo basado en enlaces troncales con ramas de características y una rama principal.\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/strategy-cicd-litmus/images/trunk-based-workflow.png)
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 le ayuda a integrarlo como fuente de una CI/CD canalización, que puede probar e implementar automáticamente su base de código en todos los entornos de la canalización.
# 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](https://www.americanscientist.org/article/understanding-the-butterfly-effect) (artículo de American Scientist), en el que una pequeña desviación aparentemente no relacionada desencadena una reacción en cadena que provoca resultados inesperados. A continuación, los desarrolladores deben investigar a fondo para descubrir la causa raíz.
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 todo CI/CD proceso completo es descubrir 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.
# Beneficios de lanzamiento de un enfoque basado en enlaces troncales
Una de las cosas que suele hacer necesaria una revisión es que, en un flujo de trabajo heredado, el estado de la aplicación en la que están trabajando los desarrolladores puede contener varias características inéditas que aún no están en producción. El entorno de producción y el entorno de desarrollo solo se sincronizan cuando se produce un lanzamiento programado y, de inmediato, comienzan a diferir de nuevo hasta la siguiente versión programada.
Es posible programar los lanzamientos dentro de un proceso completo CI/CD . Puede retrasar el lanzamiento del código a producción mediante el uso de marcadores de características. Sin embargo, un CI/CD proceso completo permite una mayor flexibilidad al hacer innecesarias las publicaciones programadas. Después de todo, *continua* es una palabra clave en la CI/CD, y eso sugiere que los cambios se publican a medida que están listos. Evite mantener un entorno de lanzamiento independiente que casi nunca esté sincronizado con los entornos de prueba inferiores.
Si una canalización no es de CI/CD completa, la divergencia entre los entornos superior e inferior suele producirse por rama. Los desarrolladores trabajan en una rama de desarrollo y mantienen una rama de publicación independiente que solo se actualiza cuando llega el momento de una publicación programada. A medida que la rama de lanzamiento y de desarrollo divergen, pueden surgir otras complicaciones.
Además de que los entornos no están sincronizados, a medida que los desarrolladores trabajan en la rama de desarrollo y se van acostumbrando a un estado de las aplicaciones muy superior al de producción, deben reajustarse al estado de producción cada vez que surge un problema. El estado de la rama de desarrollo podría consistir en muchas características antes de la producción. Cuando los desarrolladores trabajan en esa rama todos los días, es difícil recordar qué se ha lanzado y qué no se ha lanzado a producción. Esto agrega el riesgo de que se ingresen nuevos errores mientras se corrigen otros. El resultado es un ciclo aparentemente interminable de correcciones que prolonga los plazos y retrasa el lanzamiento de las características durante semanas, meses o incluso años.
# Beneficios de seguridad de un enfoque basado en enlaces troncales
Un CI/CD proceso completo proporciona un enfoque de implementación totalmente automatizado y con una única fuente de información. La canalización tiene un único punto de entrada. Las actualizaciones de software entran en la canalización desde el principio y se transmiten tal cual de un entorno a otro. Si se detecta un problema en cualquier fase del proceso, los cambios en el código que lo solucionen deben pasar por el mismo proceso y comenzar en la primera fase. Al reducir los puntos de entrada en una canalización, también se reducen las posibles formas de ingresar vulnerabilidades en la canalización.
Además, como el punto de entrada es el punto más alejado posible del entorno de producción, se reduce drásticamente la probabilidad de que las vulnerabilidades lleguen a la producción. Si se implementa un proceso de aprobación manual en un proceso íntegramente relacionado con la CI/CD, aún puede dejar de tomar decisiones sobre si los cambios se deben pasar o no al siguiente entorno. La persona responsable de la toma las decisiones no es necesariamente la misma que implementa los cambios. Esto separa las responsabilidades de quien implementa los cambios de código y de quien los aprueba. También hace que sea más factible que un líder de la organización menos técnico tenga el rol de aprobador.
Por último, el punto de entrada único permite limitar el acceso de escritura a la consola de la interfaz de usuario del entorno de producción a pocos usuarios o incluso a ninguno. Al reducir el número de usuarios que pueden hacer cambios manuales en la consola, se reduce el riesgo de que se produzcan problemas de seguridad. La capacidad de gestionar manualmente la consola en el entorno de producción es mucho más necesaria en los flujos de trabajo tradicionales que en un enfoque CI/CD automatizado. Estos cambios manuales son más difíciles de rastrear, revisar y probar. Por lo general, se hacen para ahorrar tiempo, pero, a la larga, agregan una importante deuda técnica al proyecto.
Los problemas de seguridad de la consola no se deben necesariamente a personas malintencionadas. Muchos de los problemas que se producen en la consola son accidentales. Las exposiciones de la seguridad accidentales son muy comunes y han hecho que surja el modelo de seguridad de confianza cero. Este modelo postula, en parte, que los accidentes de seguridad son menos probables cuando incluso el personal interno tiene el menor acceso posible, lo que también se conoce como *permisos con privilegios mínimos*. Preservar la integridad del entorno de producción mediante la restricción de todos los procesos a una canalización automatizada prácticamente elimina el riesgo de problemas de seguridad relacionados con la consola.