Por fin tengo acceso a las repos despues de una semana. Ahora a liarla haciendo un cambio y dandole a commit.
#24302 Todo lo que hagas pasa a DEV y tiene que ser aprobado en INT, PRE y PRO así que vas a liar poco xD.
#24305 Yo estuve en un sitio en el que todo lo hacian sobre la rama maestra, sin crear otras ramas y mergear, simplemente ahí, tal cual.
Yo me se de uno que se conecta a la máquina, copia y pega su código y luego se queja de que le borran los cambios tras cada push. Es jefe de proyecto xDDDDDDDD
#24306 No veo el problema la verdad. Asi mantienes todos cambios ordenados y no te vuelves loco con merges y mierdas de hipsters.
#24306 Es que todo se debe de hacer en la rama maestra, te quitas toda la mierda de merges y rebases y la puta madre, en tu local puedes trabajar como te de la gana pero yo solo quiero hacer review de cambios en master. Y todos los cambios tienen que ir con sus tests y la nueva version ha de funcionar con la vieja.
Como haceis deployment sin downtime si no? No me cuadra
A mi la opción de DEV, INT, PRE, PRO, no me mola, que llegue algo a PRO es lento de cojones.
Pero lo que si que veo bien es tener la maestra, desarrollo y los updates que le vas metiendo a la de desarrollo, cuando logras que la de desarrollo esté estable, la metes a la maestra. Así te aseguras siempre que la maestra funcione y no tienes caídas, vueltras atrás constantes, etcétera.
#24320 Solo necesitas tests. Si tienes caidas y rollbacks constantes es que no se estan probando las cosas como se deberian, no es cosa de que entornos tengas.
#24321 Si tienes un equipo de trescientas personas, por muchos tests que tengas se va a liar parda tarde o temprano.
Estoy de acuerdo contigo, a mi me va mucho TDD, pero la realidad es que luego la gente hace lo que le da la gana, y siendo precavido te ahorras disgustos.
#24322 La gente hace lo que le da la gana porque les dejais.
Ahora en serio. si haces TDD y tus herramientas de CI/CD estan como deben estar, nada que falle deberia llegar a PRO. Para todo lo demas, las bromas del hilo.
A ver, TDD tampoco es infalible y hay casos que se te cuelan incluso aplicándolo bien. La gracia es que una vez detectado el bug le plantas un test y a partir de la próxima release no te volverá a ocurrir.
Suerte para controlar en consultoras grandes este tipo de cosas, cuando la APP la están haciendo entre tres o cuatro empresas.
#24328 estoy de acuerdo contigo, solo comento que lo ideal no siempre se puede llevar a cabo.
#24328 ¿Que es un cambio retrocompatible? Gitflow te asegura que no llega a producción código mierder... permite hotfixes... y sobretodo.. trabajo en paralelo.
