r/programacion • u/Ecstatic_Ad2253 • 3d ago
Pregunta sobre trabajo en equipo en proyecto .NET
Buenos días.
Soy desarrollador con año y medio de experiencia pero la mayoría de los proyectos los he desarrollado solo y o alguna feature de la que hago una rama y mergean. Ahora me han puesto a mí a "dirigir" más o menos un proyecto.
Cómo no tengo mucha experiencia aquí lo que he pensado es lo siguiente:
Cada desarrollador al desarrollar trabaja en una rama por feature, por ejemplo: feature/login... Luego siempre debe estar apuntando a local y las migraciones hacerlas a local y al mergear a Develop se hacen las migraciones y se actualiza la base de datos de Develop una vez se hayan resuelto conflictos y pasen test, esto porque es muy probable que haya conflictos que resolver y las migraciones fallen. Entonces no todos mergean a Develop sino solo un desarrollador tiene la potestad de hacerlo.
Si alguno con más experiencia me puede indicar la forma correcta lo agradecería. Muchas gracias
•
u/KaiserKrieg81 3d ago
Hay muchas formas de hacerlo, al final siempre hay que llegar a un acuerdo de como hacerlo.
En general, como ya has adivinado, conviene tener como minimo 2 entornos, pre-produccion y producción. 3 entornos si cuentas tu propio local que NO es pre-producción, que este es un punto que algunos juniors confunden.
En el repositorio tienes 2 ramas que reflejan el estado en cada uno de los 2 entornos, dev representa pre-producción, y main representa producción.
Cuando tu quieres desarrollar una nueva feature abres una rama desde dev y trabajas en local en la nueva feature, pasando todos los test (cuando se pueda en local) y haciendo todos los commits en esa rama. Como digo, idealmente todo en local, aunque no siempre es posible. Cuando has terminado la feature abres un pull request de tu rama sobre dev y esperas que el reviewer o responsable del proyecto (que puedes ser tú mismo) lo apruebe y lo mergee a dev.
En ese punto deberias tener un automatismos o pipeline que detecte commits en dev y automáticamente despliegue los cambios en pre-producción.
Si tienes colaboradores para tu tarea todos trabajarían sobre tu rama de trabajo, creando si es necesario aún mas subramas dentro de tu rama. Pero no suele ser necesario.
En este punto tienes una divergencia de codigo en dev sobre main con esa nueva feature que negocio o quien sea decide que fecha se hace la release a producción. Cuando llega dicha fecha de release se puede hacer una pull request de dev sobre main. Y el automátismo o pipeline de la rama main se encarga automáticamente de desplegar los cambios en producción.
Se puede complicar bastante pero a grandes rasgos funciona asi.
Puede ocurrir que salga un bug en producción que urja corregir. En ese caso se saca una rama de main con el nombre hotfix-loquesea, se hace el fix en esa rama, se prueba y luego haces el merge tanto sobre main como sobre dev (las 2) para incorporar el fix a ambas lineas de trabajo.
•
u/DarkSpy1976 3d ago
Claro, es algo así, normalmente en algunos trabajos tienen a un devops que se encarga de todo el manejo de las ramas y los merges, si no es el caso alguien más debe hacerse cargo de esa tarea y lógicamente se debe hacer con mucho cuidado.
•
•
•
u/bmsv4100 2d ago
Un apunte, la nueva rama la debes crear a partir de main. Si lo hace de dev se va a llevar cambios que no tienen nada que ver con lo suyo y que podrían estar incompletos o con bugs
•
u/Khavel_Es 3d ago
Lo del flujo de ramas por feature esta bien, es lo estandar. El tema es que si solo una persona puede mergear a develop generas un cuello de botella. Esa persona pasa a ser el bloqueante de todo el equipo, y si se va de vacaciones se para todo.
Lo que yo haria: cada dev hace PR a develop, otro del equipo la revisa (no tiene que ser perfecta la review, con que no rompa nada alcanza), y el mismo autor la mergea. Para las migraciones de EF Core, que cada uno corra dotnet ef database update en su local antes de pushear. Si hay conflicto en el snapshot del modelo, lo regeneran. El conflicto de verdad pasa cuando dos features tocan la misma tabla, y eso se detecta en el code review, no centralizando el merge.
Si pueden meter la DB de develop en un contenedor que se recrea con un script, se ahorran el clasico "quien rompio la base".
•
u/Hw-LaoTzu 3d ago
https://launchdarkly.com/blog/git-branching-strategies-vs-trunk-based-development/
Lee este articulo, tienes la explicacion completa
•
u/yeusk 3d ago
Como veo que solo te estan explicando como usar git... la gente es que ya ni lee la pregunta... Microsoft tiene una pagina indicando como trabajar con migraciones con equipos.