¿Cómo deberíamos abordar un gran cambio en nuestra aplicación?

Tenemos esta gran aplicación que tiene 18 proyectos en nuestro control de fuente ( VSS ).

Cada vez que trabajamos en pequeños cambios, todo está bien porque cada desarrollador tiene un set de pocos files prestados a sí mismo, y es de esperar que nadie los vaya a necesitar hasta que se registren (en aproximadamente 4 a 8 horas).

Pero cuando queremos trabajar en grandes cambios, un desarrollador mantiene tantos files desprotegidos durante algunos días y dificulta que otros hagan las tareas asignadas.

Aquí hay un escenario, por ejemplo: la semana pasada quisimos implementar una característica que searchá cada list en nuestra aplicación usando un mecanismo de búsqueda. Por lo tanto, deberíamos cambiar las capas de IU, negocios y acceso a datos. Hay un desarrollador asignado a esta tarea, ha comprobado una gran cantidad de files y está bloqueando otras tareas.

¿Cómo debemos planear desarrollar este tipo de características?

Si actualizar a un VCS real no es una opción ahora, haga que la persona que realiza la function principal descargue una copy local de todo y luego haga sus cambios fuera del control de la versión. Combínalo todo de una vez (durante un fin de semana o algo por si se complica).

Esto no ayuda al desarrollador que necesitará el control de versiones mientras realiza los "grandes cambios"

Bueno, haces lo que tienes que hacer con las herramientas que tienes. Siempre podría instalar un VCS moderno como git que funciona localmente. Simplemente revisa toda la línea de base en git (less historial) y ve.

Cambia a un mejor sistema de control de versiones. VSS adolece de problemas de layout y sus principios de locking rígido. Subversion está disponible de forma gratuita y puede utilizarse para el desarrollo de aplicaciones a gran escala. La ramificación y el labeldo son operaciones baratas y no hay un locking rígido.

Su empresa definitivamente vivirá mejor con Subversion. ¡Pruébalo!

Servidor Fácil de configurar en qué sistema (Windows / Linux)

TortoiseSVN Client para Windows que se integra dentro del Explorador de Windows

Manual de SVN Lea al less los primeros capítulos

Hay muchas otras alternativas, pero VSS es un dolor en el desarrollo a gran escala. Como hay una mejor solución gratuita disponible, ¿por qué apegarse a un proveedor?

VSS apesta , migra a un SCM real, Microsoft probablemente lo ayude a actualizar sin problemas a TFS que no tiene este problema. O migre a cualquiera de los SCM de FOSS, como la subversión, pero la transición probablemente sea más difícil (pero puede ser más económica).

¿Has considerado compartir y ramificar? Además, puede permitir múltiples paros con usuarios que tengan experiencia. En el caso de realizar un cambio de aplicación grande, sugiero labelr y luego crear una twig. Si algo le sucede a "grandes cambios", no lo hará a la versión de producción. Puede hacer correcciones rápidas en el código publicado y luego fusionarlas en "grandes cambios" una vez que esté listo. Consulte el tema de ayuda "Compartir y ramificar".

Use un sistema de control de versiones que funcione en modo fusión (optimista), no en modo de locking.

El modo de fusión es optimista porque supone que los cambios generalmente no se realizarán en el mismo lugar. Si sucede en el mismo lugar, es usualmente fácil de resolver.

Un ejemplo de un sistema de control de versiones que puede funcionar en modo fusión es CVS. Está desactualizado ahora, pero existen otros.

SVN es la respuesta a tus problemas. Lo he usado y es muy fácil aprender / trabajar con él. Pero hay algunos niños nuevos en la cuadra. Prueba GIT . He estado oyendo mucho al respecto aunque no he tenido la oportunidad de probarlo

VSS es solo una vieja historia, usamos Subversion (server) y TortoiseSVN (cliente) ahora. (Eso solo se basa en nuestras preferences) Por cierto, migrar a otro control de versión / control de fuente – solo – no resolverá el problema de su equipo. El problema es acerca de la comunicación. Si no puede comunicarse con los demás y mantenerse con su hábito (trabajando con muchos files sin registrarlos), va a derrotar a su equipo, debe dejarle saber cómo trabajar con el equipo usando el control de versiones. Si no, ella te pondrá en problemas de "combinación" cuando usas Subversion. ^^

Ya recibiste el consejo de cambiar a un VCS utilizable.

Por encima de eso, usted y los desarrolladores deberían capacitarse para dividir los grandes cambios en pequeños. Consideraría aproximadamente 10 commits por día y desarrollador de time completo una tarifa normal. Hace que los lockings sean mucho less dolorosos.

El principio debería ser: haga el cambio más pequeño posible que lo lleve hacia su estado deseado y funcione (como en el software comstack y pasa todas las testings).

En el caso que dibujaste. Agregar un parámetro a una capa y cambiar todas las llamadas a esa capa (posiblemente con un valor ficticio) sería un cambio. En realidad, usar ese valor sería otro cambio.

Esto debería generar less files bloqueados durante un período mucho más corto.

A largo ploop, querrá migrar a otro VCS. Como han mencionado otros, considere el código abierto o TFS si desea seguir con MS. (Usamos TFS, pero no voy a cantar sus alabanzas, está bien.) Como mencionó AMISICO, la bifurcación ayudará con cualquier VCS que lo soporte. Aprender a utilizar la bifurcación de manera efectiva no es trivial y requerirá estudio y / o capacitación.

La continuous integration también ayudará. TeamCity es lo que usamos, y es relativamente simple de configurar. Ver FeatureBranch .