Hace un par de días una amigo preguntó por esta práctica en twitter por lo que decidí dar una brevísima explicación en este video.
NOTA: a sugerencia de Rodrigo Corral he cambiado el título para que quede claro de entrada que en la inmensa mayoría de los casos esta es una mala práctica, cosa que entiendo he dejado bien claro en el video; aunque nunca se sabe. Creo además que la malas prácticas también necesitan ser explicadas ya que forman parte del vocabulario común y uno debe conocerlas.
Gracias por la explicación 😉
Me siento incómodo respondiéndote porque nunca he trabajado en equipos grandes, así que tú hablas desde la práctica y yo desde la teoría. Aún así, mi opinión es que es lógico un periodo de estabilización en Main, pero que no tiene por qué impedir que se siga desarrollando en Dev. Está claro que esto va a provocar conflictos, pero que deben minimizarse fusionando Main hacia Dev lo más continuamente posible, por ejemplo a diario durante esos 4 días.
Evidentemente depende del caso, si *todos* los desarrolladores están resolviendo bugs en Main, nadie va a estar añadiendo funcionalidad nueva a Dev; pero como entiendo que en muchos casos no será así, que sólo unos cuantos devs estarán trabajando en Main, y sí podría haber avances en Dev, Code Freeze es una técnica muy bloqueante para evitar un merge complejo (que, estoy de acuerdo, puede suponer un auténtico infierno).
@pablonete
Lucs, creo que el título del artículo debería ser Code Freeze–Explicando esta MALA práctica.
Nunca es sano establecer póliticas en tu gestión código fuente que tengan como proposito o como resultado el alejarte de la integración continua. Integración continua es mucho más que simplemente lanzar construcciones de manera automatizada. Es establecer las políticas que te permitan integrar de manera sumamente frecuetne.
El Code freeze, las golden line y demás trabas a que un desarrollador pueda integrar generalmente ocultan problemas en el diseño de la solución y de la pólitica de gestión de la configuración.
Un saludo.
Por cierto, un artículo interesante donde se cita como antipatrón:
Branching and Merging Primer
http://msdn.microsoft.com/en-us/library/aa730834(VS.80).aspx
Un saludo.
@Pablo @Rodrigo comparto el punto de vista. Esto no representa una recomendación sino que busca simplemente explicar la práctica (que existe y debemos conocerla para al menos entender de qué se trata cuando alguien nos habla de ella)