El MEJOR #GIT FLOW. Pros y contras de cada uno 🔥 | Flujos de trabajo con Git 7/7

🔥 ¡Aprovecha la oferta del Black Friday de CodelyTV Pro!
---
GitLab Flow, Release Flow, Git Flow, Trunk-Based Development, #GitHub Flow, Master-only flow… ¡¡¡¡Aaaaah!!! ¿Con cuál nos quedamos?
Repaso rápido de 6 Git Flows analizando pros y contras de cada uno dependiendo del contexto 🤟

Importante: Cabe destacar que estamos totalmente sesgados por los entornos donde hemos trabajado (letgo, Akamon, Uvinum, etc) y damos una versión totalmente opinionada en base a esto. El contexto marcará si realmente es útil en cada caso y, al igual que con todo, los workflows de Git serán buenos o no según dónde se apliquen 👼

🔗 Enlaces relacionados:

{▶️} CodelyTV

[CodelyTV]

🔗 Enlaces relacionados:


{▶️} CodelyTV

[juanzafra]

Los análisis que se hacen deberían estar bajo diferentes contextos, y se debe tener en cuenta la cantidad de personas que pueden trabajar sobre una aplicación, entre otras variables que se deben tener en cuenta y no solo la opinión personal si no un análisis más crítico.

[juanitoMint]

Build once deploy many (buildea una vez despliega muchas) una estrategia que viene de la mano de Shift Right en los ambientes.
A mi particularmente no me molesta el gitflow y que los brnaches queden como una formalidad del paso de ambientes
Es más fácil leer el código desplegado desde un branch que desde un tag, aumentando la visibilidad (en mi opinión)
En ese caso el pipeline solo buildea en ambientes bajos luego solo despliegue

[ChristianLopezSantos]

Respeto su opinión pero la verdad no estoy de acuerdo. No tuvieron en cuenta los tamaños de los equipos ni que tan expertos son los desarrolladores. No me imagino manteniendo un only master con un equipo de ni de 8 integrantes entre los cuales habría hasta juniors y con un proyecto basado en varios servicios. Quizás para proyectos pequeños y monolíticos pero no para proyectos grandes y que requieran integrar al menos un pequeño equipo de pruebas.

[CritickalTvRandom]

llego a la Master-Only flow y me quedo como: tengo que hacerme un cursito de git, porque esto no me tiene sentido.

¿Pero el chiste no es que la gente trabaje en una rama distinta para no alterar lo que hacen los demás?

[jhoningsoft]

Como podrías solucionar problemas del tipo varias personas trabajando sobre la misma feature? con #GitHub Flow, Master-only flow

[AlanLineroDevOps]

Todo depende:
Cantidad de ambientes (homologados) Mindset de equipos (cultura DevOps)
Seniority del equipo
Automatización de test
Tipo de Agilidad
CI CD 100%
Necesidad del negocio
Monorepo o multirepo
Equipo interno o externos
Medición de bugs feature
Monitoreo continuo

Tienes que usar la que se adapta pero sobretodo aplicando la balanza de Agilidad es decir que siempre tu código sea LIMPIO

[imsergiohere]

Comencé ilusionado con git flow
Pasé a asquearlo
Y ahora lo entiendo y me asombra lo íntegro que es

Creo que forma parte de la madurez

[Jeancahu]

Use Arch y usé Ubuntu, Arch nunca me ha fallado, Ubuntu se rompía con solo mirarlo, eso de decir que Arch no "es tan estable" como Ubuntu no tiene absolutamente nada que ver, Arch puede darse el lujo de ser rolling-release únicamente por la alta calidad del código y lo bien estandarizado que está todo, no tiene esas mezclas sucias de SysV legacy + SysD y paquetes con versiones en el nombre como python3, si no que siempre prioriza mantener la coherencia del sistema, además de poseer probablemente el mejor manejador de paquetes, Ubuntu solo es "más estable" si lo dejas queditito y no tocas nada o instalas todo por Snaps, pero que sentido tiene eso? para mí ninguno

[felixinit]

3:35 gitlab flow, no les convence la complejidad. El entorno puede variar de una rama a otra y eso no pasa con "Bills inmutables" (investigar)
11:00 Github flow. La panacea. Entornos de desarrollo dinámico o distribuidos. En las Features brands se despliega el entorno de producción.

[Albarranator]

Le atiné, se fueron por el Trunk-based

[SimaDamian]

Me causa un poco de gracia que en uno modelo hablan de complicado de tener tantos ambientes para prueba y en otro no tiene absolutamente nada pero no hacen ni un solo comentario al respecto. Y tampoco de la posibilidad de tener más de una versión en productivo... Etc. Falta mucho contexto. Saludos

[injiniero]

Me ha laiqueado mach esta serie de vídeos sobre los git flous. Domináis los conceptos y el idioma: "deployear", "commitear", "jardcodear"... por no forgetizarnos de las fiturs. Fologüear así... tronquis.