Git Release Flow: Microsoft, ni calvo ni con 3 pelucas 🕺 | Flujos de trabajo con Git 4/7

preview_player
Показать описание
🔥 ¡Aprovecha la oferta del Black Friday de CodelyTV Pro!
---
Analizamos #ReleaseFlow: Un flujo de trabajo en ramas para #Git propuesto por #Microsoft. Simplifica un poco #GitFlow ya que las "feature branches" saldrían directamente de master, pero… ¿Qué diferencias entienden entre feature branch y topic branch? ¿Cómo aplican hotfixes? ¿Cómo desplegan?

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
Рекомендации по теме
Комментарии
Автор

🔗 Enlaces relacionados:

{▶️} CodelyTV

CodelyTV
Автор

Si tengo cambios funcionales sin terminar, debería usar feature flag hasta terminar de hacer mis cambios si?

erickhilario
Автор

Yo creo que no es un flujo tan loco, cuando piensas en una empresa como Microsoft, tu imagínate que Windows se te actualice cada día?? o el office en la mañana. madre mía que vamos a decir todos lo usuarios.

danielgonzalez
Автор

Yo opino lo mismo del Release Flow que Javi, no entiendo porque esperar 3 semanas a publicar una/varias features. El riesgo de colisionar unos "topics" con otros y darte cuenta del error a las 3 semanas es altisimo. Supongo que hay cosas que hacen por medio/antes de la release que no cuentan, como quizas para cada topic crear un entonro de test o vete a saber el que. Tambien es cierto, que puede que el desarrollador ya ni este en la empresa y vete tu a buscarlo despues jaja.

davidtorrente
Автор

Bueno tratándose de Microsoft, que tiene muchos productos inmensos, pues creo que mientras esté todo bien testeado es aceptable.

aquirozca
Автор

Yo pienso que siempre hay que aportar valor lo antes posible.


Tener codigo no visible en master, es un trabajo no visible para el usuario final. Estás releases unicamente tienen sentido si el producto ya está maduro o vives un ambiente de desarrollo mas lento a nivel de deploys.

tomascayuelas
Автор

yo lo utilice a este tipo de estrategia y se volvio un caos el hecho de mantener tantos release branches

ThePomelo
Автор

buscar un error en el git log debe ser de locos jaja, vaya flujo más basura

Jeancahu