Вставка
- Опубліковано 9 січ 2025
- 🔥 ¡Aprovecha la oferta del Black Friday de CodelyTV Pro!
⮕ codely.tv/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:
├ 👩💻 Curso "Git: Introducción y trabajo en equipo": bit.ly/git-cod...
├ ⚡ Oferta lanzamiento curso Git: bit.ly/git-oferta
├ 🤷♂️Por qué no nos gusta Git Flow: • Por qué no nos gusta ...
├ 🤯 GitHub Flow: El secreto está en el deploy: • GitHub Flow: El secret...
├ 💃 GitLab Flow: Los entornos IMPORTAN: • GitLab Flow: Los entor...
├ 🕺 Git Release Flow: Microsoft, ni calvo ni con 3 pelucas: • Git Release Flow: Micr...
├ 📍 Trunk-Based Development: Simplificando Git: • Trunk-Based Developmen...
├ 🌳 A podar ramas: Master-only Git Workflow: • A podar ramas: Master-...
├ 1️⃣ Aprende Git en menos de 10 minutos: • Aprende Git en 10 Minutos
└ 2️⃣ Tu primera Pull Request en #GitHub: • Tu primera Pull Reques...
{▶️} CodelyTV
├ 🎥 Suscríbete: ua-cam.com/users/c...
├ 📸 Instagram: / codelytv
├ ℹ️ LinkedIn: / codelytv
├ 𝐟 Facebook: / codelytv
├ 🐦 Twitter CodelyTV: / codelytv
├ 👨🏻 Twitter Javi: / javiercane
├ 💂♂️ Twitter Rafa: / rafaoe
└ 📕 Catálogo cursos: bit.ly/cursos-...
🔗 Enlaces relacionados:
├ 👩💻 Curso "Git: Introducción y trabajo en equipo": bit.ly/git-codelytv
├ ⚡ Oferta lanzamiento curso Git: bit.ly/git-oferta
├ 🤷♂️Por qué no nos gusta Git Flow: ua-cam.com/video/HhI77BXRjuo/v-deo.html
├ 🤯 GitHub Flow: El secreto está en el deploy: ua-cam.com/video/2Xagp86uOuI/v-deo.html
├ 💃 GitLab Flow: Los entornos IMPORTAN: ua-cam.com/video/AuDZvbHSW1c/v-deo.html
├ 🕺 Git Release Flow: Microsoft, ni calvo ni con 3 pelucas: ua-cam.com/video/eOXZzfNn4N0/v-deo.html
├ 📍 Trunk-Based Development: Simplificando Git: ua-cam.com/video/-73RVTQxUhs/v-deo.html
├ 🌳 A podar ramas: Master-only Git Workflow: ua-cam.com/video/MWz-9uyHP4s/v-deo.html
├ 1️⃣ Aprende Git en menos de 10 minutos: ua-cam.com/video/DuYjcOZw11s/v-deo.html
└ 2️⃣ Tu primera Pull Request en #GitHub: ua-cam.com/video/_M8oalUyz10/v-deo.html
{▶️} CodelyTV
├ 🎥 Suscríbete: ua-cam.com/users/CodelyTV
├ 📸 Instagram: instagram.com/CodelyTV/
├ ℹ️ LinkedIn: linkedin.com/company/codelytv/
├ 𝐟 Facebook: facebook.com/CodelyTV/
├ 🐦 Twitter CodelyTV: twitter.com/CodelyTV
├ 👨🏻 Twitter Javi: twitter.com/JavierCane
├ 💂♂️ Twitter Rafa: twitter.com/rafaoe
└ 📕 Catálogo cursos: bit.ly/cursos-codely
Seria bueno que dedicaran un tiempo a responder las preguntas de sus seguidores ¿Cierto?, después de todo no son tantas. Lo digo en general para todos sus vídeos que tienen contenido muy interesante, y que muchas veces da origen a cuestionamientos o dudas de quienes los vemos, saludos.
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
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.
Jaja. Son videos de muestra, los cursos son de pago.
Genial resumen, seguid así cracks!
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?
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.
Kubernetes, esa es la respuesta
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
Que tool utilizan para diagramar?
Como podrías solucionar problemas del tipo varias personas trabajando sobre la misma feature? con #GitHub Flow, Master-only flow
varias personas sobre el mismo feature... ese problema lo tenes sobre cualquier flujo... es como trabajar todos sobre master sin pull request. Yo propongo separar en mas sub/features o a lo sumo que los desarrolladores que trabajen en el mismo feature esten sincronizados entre ellos.
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
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.
Hola Felix, te corrijo sobre lo de "Bills". En realidad habla de "Builds", o artefactos que se generan durante el stage de compilacion/construccion (o build en ingles). Armas tu paquete y lo mueves entre entornos (dev/test/prod), entonces te aseguras que lo que vas a deployar en producción sea lo mismo lo que se probó en entornos bajos.
Le atiné, se fueron por el Trunk-based
XD que simplificación....
El viejo JENKINS
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
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.
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