Me surgen dudas. ¿Como se gestionan aquí los cambios en esquemas y modelos de persistencia en general?¿y entidades? También podríais comentar en otro correo como gestionáis migraciones y que estrategias utilizáis para el despliegue.
Para mí es el antiflow. Venía de usar SVN y como usar branches es bastante infernal, todos acabábamos subiendo a "trunk". Ahora hemos migrado a Git y usamos una especie de Git-flow pero sin usar la rama "release" para detectar bugs, si no, que esa fase de detección de bugs, la vamos haciendo directamente en "develop". He de reconocer, tras el primer periodo de adaptación, estamos muy a gusto trabajando así.
Su contenido es EXCELENTE, de verdad lo digo... pero por la forma en que hablan (tanto en expresiones como en velocidad) a veces de verdad que me cuesta entenderles... seria algo bueno para trabajar en el 2020!!!
Este es el que me pareció peor de todo por lejos. Solamente se me ocurrira usarlo en proyectos muy chicos con equipos muy chicos(2 devs o 3 estirando). Lo más lindo de Git es lo barato que es crear una branch nueva y esto propone ir para atras. Tampoco me parece bien abusar de Features Flags para todo lo que estamos haciendo la administracion de esto asume más y más complejidad y en definitiva criticaron git flow porque tiene mucha burocracia y es propenso a errores y esto me parece que es todo lo opuesto un caos absoluto y mas propenso a errores ya que ponemos la complejidad del versionado en el codigo como FF. Solo me imagino que puede "servir" en caso de un producto que este pronto, estemos en mantenimiento, el equipo se achico demasiado y no se planea nuevas features, solo correccion de errores.
🔗 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
├ 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
Me surgen dudas. ¿Como se gestionan aquí los cambios en esquemas y modelos de persistencia en general?¿y entidades?
También podríais comentar en otro correo como gestionáis migraciones y que estrategias utilizáis para el despliegue.
Para mí es el antiflow. Venía de usar SVN y como usar branches es bastante infernal, todos acabábamos subiendo a "trunk". Ahora hemos migrado a Git y usamos una especie de Git-flow pero sin usar la rama "release" para detectar bugs, si no, que esa fase de detección de bugs, la vamos haciendo directamente en "develop". He de reconocer, tras el primer periodo de adaptación, estamos muy a gusto trabajando así.
Este no me aplica, se suele tener doferencias en distintos ambientes al mismo tiempo alli como ?
Para mi es este Master-only flow, si el equipo de trabajo es chico creo que seria el mas sencillo
Para mí que su favorito es el Trunk-based flow y el que detestan al 1000 es el GitFlow
Su contenido es EXCELENTE, de verdad lo digo... pero por la forma en que hablan (tanto en expresiones como en velocidad) a veces de verdad que me cuesta entenderles... seria algo bueno para trabajar en el 2020!!!
No puedo estar más de acuerdo.
Este es el que me pareció peor de todo por lejos. Solamente se me ocurrira usarlo en proyectos muy chicos con equipos muy chicos(2 devs o 3 estirando). Lo más lindo de Git es lo barato que es crear una branch nueva y esto propone ir para atras. Tampoco me parece bien abusar de Features Flags para todo lo que estamos haciendo la administracion de esto asume más y más complejidad y en definitiva criticaron git flow porque tiene mucha burocracia y es propenso a errores y esto me parece que es todo lo opuesto un caos absoluto y mas propenso a errores ya que ponemos la complejidad del versionado en el codigo como FF.
Solo me imagino que puede "servir" en caso de un producto que este pronto, estemos en mantenimiento, el equipo se achico demasiado y no se planea nuevas features, solo correccion de errores.