ANALIZAMOS BRANCHING MODELS

[@leonardoboschiazzo1384]

gitflow si devs >2 el resto si devs

[@xaviercp2200]

La cuestión es un asunto de permisos y privilegios, yo no puedo permitir que un desarrollador de un feature específico pueda alterar una rama principal sea master o developer la cual es de todo un proyecto que él desarrollador podría no conocer. De la misma manera yo no debo permitir que un desarrollador o administrador de la rama developer pueda hacer merge a la rama que va a producción. Por prácticas de seguridad eso no puede ser permitido. El que sugiere tbd debe ser que trabaja en una empresa que no es muy madura o no tiene exigencias de calidad

[@orlandoubilla7055]

Veo a lo lejos que el TBD debe traer un quebradero de cabeza en forma de merge conflicts, si tienes un equipo grande dando soporte a un sistema que levanta varios tickets en paralelo y que se van pasando a producción de forma no ordenada/no-lineal.

[@jaimerafaeldecubabautista2945]

Exactamente, todo depende del cliente. En mi caso nos toca hasta dejar implementaciones fuera, ya que a último momento se decide no aplicarlo a la versión en producción.

[@MarcoRomeroYT]

Datazos, para alguien acostumbrado al gitflow

[@angeltigua4014]

No se porque se estresan con las ramas, una vez que sepas y aceptes el cambio git flow es bastante estructurado y permite tener un historico de cambios más organico, mientras que con otras formas de branching es más flexible facilitando el caos, lo he usado tanto para pequeños o grandes proyectos....

[@juanmarquezr]

no se cual polemica anterior sobre DevOps, pero es correcto referirse a DevOps como el conjunto de practicas relacionadas al factory de codigo o software, y un agente realiza la actividad de Development sea cual sea su participacion, no es correcto decir nosotros como DevOps.

[@alejandrocepeda4767]

Poco a poco mas equipos high performance estan enviando commit directamente a producción, usando técnicas como TDD, feature flag etc, tener varios envs de pre-production como development o staging cada ves es mas difícil mantenerlos a la par de producción y costosos , poco a poco van ha desaparecer, en ese sentido si gitflow esta muriendo, lo mismo pasara con Trunk-Based Development.

[@BhEaN]

Buenas! Me temo que estas equivocado con respecto a las estrategias de branching, pero es normal si no has trabajado con otro modelo aparte de Gitflow. Estoy de acuerdo con el comentario que te dijeron en el anterior video: Gitflow es (y por mucho) el PEOR sistema de branching que puedes usar. Tal y como promueve la fisolofia Devops y las buenas prácticas, los ciclos de desarrollo deberían ser lo más cortos posible. Es decir, el tiempo de vida de una feature branch debería ser lo más corto posible (idealmente menos de 1 dia) de forma que se hagan merges a la rama principal (main/master) con la mayor frecuencia posible. Para esto, Trunk Base Development (TDB) es sin duda la mejor opción. No se trata de hacer "commits a master directamente", TDB no prohibe que hagas un branch para desarrollar una nueva feature, sino que lo que pretende es que esa branch tenga un ciclo de vida muy corto y se haga "merge" a la rama principal lo antes posible, y sobre todo sin "ramas intermedias" (tipo "develop" y demás) que no solo no aportan nada sino que introducen complejidad y potenciales problemas. No hace falta que un desarrollo esté 100% terminado en la feature branch en la que estas trabajando antes de hacer el "merge" a la rama principal. En estos casos, si la feature en la que estas trabajando no está aún terminada o necesitas testearla en otro entorno antes, se utilizan los mecanismos de "feature flag" con los que se pueden activar/desactivar estas funcionalidades sin necesidad de hacer cambios en el repositorio. Y con respecto a lo que comentas de la "aprobación manual" para desplegar el cambio en los diferentes entornos, idealmente tampoco debería ser así. Cuando se trabaja en una feature branch y se crea una "merge-request" para hacer el merge a la rama principal, parte de la pipeline de CI debería ser la ejecución de las suites de tests para asegurarse de que no se está rompiendo nada, y solo después de que todos los tests se hayan ejecutado correctamente, un compañero haría el "code review" y es en ese punto donde se haría el "merge" a la rama principal y su inmediato "deploy" a los entornos (SIN ninguna aprobación manual ni nada similar). El hecho de que alguien tenga que "pulsar OK" manualmente para que se haga un despliegue a un entorno solo significa que NO confiais en vuestros propios tests, ya que si lo hiciérais, no sería necesario aprobar el despliegue "manualmente". Hay un monton de literatura al respecto, te sugiero que sigas investigando acerca del role de DevOps, CI/CD, etc. y sobre todo que pruebes otras formas de hacer las cosas para que puedas formarte una opinión propia según tu experiencia. Saludos!!

[@caosbinario]

Muchas gracias por tu respuesta 😁, realmente me quedo más claro, aunque sigo teniendo algunas dudas con respecto al control de cambios a la hora de controlar las versiones, pero es cosa mía, voy a seguir investigando. El video no es ninguna verdad absoluta sobre este tema, ya que justamente no soy experto en esto, y creo que estos comentarios ayudan a toda la comunidad a seguir creciendo!

[@BhEaN]

@@caosbinario El control de las versiones idealmente se realizaría a través de tags en el repositorio. Lo cierto es que depende mucho de si es para un proyecto web, una app movil, etc. ya que las versiones se usan de forma diferente, pero por lo general cuando se quiere hacer una "release" de la aplicación, se hace un tag utilizando el standard "Semantic Versioning" (por ejemplo, la version 1.3.2) que apunta a un momento específico de la rama main. Hay que evitar pensar en que la rama main tal cual es "produccion", ya que no hay un único "produccion". Por ejemplo, en una app movil, puede que haya gente usando una version, y otra gente usando otra versión diferente porque aún no han actualizado. Y en ambos casos sería "produccion", sin embargo la rama main actual no tendría porqué tener el código exacto de ninguna de ellas. Por eso se usan los tags de git. Por cierto, gracias por subir contenido de este tipo, creo que es muy util para todos y no hay demasiados canales sobre esto en habla hispana! Un saludo!

[@soniainternet1796]

@@BhEaN Una duda, ¿esos tags sobre main podrian ser del tipo x.y.z-beta (para environment DEV), x.y.z-release_n (para environment PRE) y x.y.z (para envieronment PRO). Si fuese asi, si me encajaria TDB....

[@BhEaN]

@@soniainternet1796 Efectivamente, el que yo comentaba es el formato habitual, pero "semantic versioning" permite algunas otras variaciones como la que comentas tu. Aunque lo cierto es que no se suele usar para indicar el entorno (pre, prod, etc). En mi opinión, no tiene mucho sentidotener una versión marcada para un entorno específico. Tu podrás utilizar en el entorno que quieras la versión que quieras, no tiene sentido que una versión esté "anclada" a un entorno... pero te recomeniendo que le eches un vistazo a la web de "semantic versioning" ya que ahí está la especificación completa y se explica mejor todo esto (no puedo poner el enlace porque sino me bloquean el mensaje). Saludos!

[@jhonnatanchaves]

@BheEaN no pense encontrarte por aca!! A big pleasure!! Desde mi perspectiva y en las oportunidades donde podemos discutir acerca de las mejores estrategias para la gestion de los flujos para los equipos de desarrollo, siempre viene un gran depende!! Y por que lo menciono asi, por que realmente no esta en piedra la forma en la que los equipos trabajan y como las organizaciones tienen sus modelos o como etan dispuestas a trabajar, siempre van a existir variantes y desde mi perspectiva siempre he trabajado con modelos hibirdos obteniendo lo mejor de cada estrategia segun las necesidades de los equipos y como se va a presentar un mejor servicio para todos mas alla del Dev!! Excelente vid y es un gran punto de discusion en todas las organizaciones poder establecer la estrategia de branching que mas se acomoda!!

[@xaviercp2200]

Es correcto, no tiene ningún sentido llamarse ingeniero devops

[@Khris14]

Se le dice devops que deje de llorar ese que se pone a discutir eso

[@cefas89]

giflow esta tan muerto como php