Introducción

Hasta ahora hemos visto características sobre el control de versiones de Team Foundation Server que en la mayoría de los casos no poseían otras soluciones que se utilizan para manejar el versionado del código fuente, pero no hemos hablado mucho de las características que si poseen los demás. La característica principal de un software utilizado para la gestión del código fuente, como no, es el modelo de trabajo que plantea. Al tener un repositorio de código fuente centralizado surge el problema de que dos usuarios distintos quieran modificar un mismo fichero al mismo tiempo. Ante una situación así se plantea un problema para el que de forma generalizada existen dos soluciones. Estas soluciones van a definir el modelo de trabajo que seguirá el equipo de desarrollo y a continuación vamos a ver una breve descripción de cada uno de estos dos modelos, el modelo "Lock-Modify-Unlock" y el "Copy-Modify-Merge". Ninguno es mejor que el otro, cada uno de ellos tiene sus ventajas y desventajas y dependerá del contexto para aplicar uno u otro.

Lock-Modify-Unlock

Analizando un poco el flujo de trabajo de un desarrollador que trabaja contra un repositorio de código fuente podríamos obtener tres estados en los que se puede encontrar. En el primero de ellos al desarrollador se le asigna una tarea y decide hacer check-out del fichero que tiene que modificar para realizar la tarea. Mas adelante modifica y el fichero con el código necesario y finalmente deposita el fichero en el repositorio. Es aquí donde entran en juego estos dos modelos que comentaba. El modelo Lock-Modify-Unlock, también conocido como el modelo pesimista, hace que cuando el desarrollador desprotege el fichero se haga una desprotección exclusiva (Lock), el fichero se bloquea en el servidor y nadie puede modificarlo mientras él este realizando cambios sobre el fichero (Modify). Una vez que el desarrollador ha terminado la edición del fichero los deposita en el servidor y lo desbloquea para que cualquier otra persona pueda realizar cambios sobre el fichero (Unlock).

La principal ventaja de este modelo es que nunca se producirán conflictos entre versiones debido a que nadie puede realizar modificaciones mientras el fichero esta bloqueado. Por otro lado la principal desventaja de este modelo es que el hecho de tener el fichero bloqueado en exclusiva no permite a dos personas trabajar el mismo fichero, situación que muchas veces es necesaria. Por otro lado, utilizar el bloqueo exclusivo puede causarnos problemas si un desarrollador se va de vacaciones o simplemente ya no esta en la compañía y deja ficheros bloqueados.

Copy-Modify-Merge

Por otro lado, existe un modelo diferente de trabajo diferente para el mismo flujo que describíamos antes, llamado Copy-Modify-Merge y que es conocido también como el modelo optimista. En este modelo cuando el usuario hace check-out de un fichero (Copy) esto queda registrado en el servidor, pero el bloqueo que se hace no es exclusivo, por lo que otros usuarios pueden realizar modificaciones sobre el fichero. Este modelo es mas flexible desde el punto de vista en el que mas de una persona necesite modificar un mismo fichero pero esta flexibilidad implica que mientras un desarrollador esta haciendo modificaciones sobre un fichero (Modify) otro haya podido modificar y subir una nueva versión del fichero, con lo cual la versión que estamos modificando ya no es la última y necesitaríamos combinar nuestros cambios con los cambios realizados por la otra persona (Merge).

La principal ventaja de este modelo es la flexibilidad que da el que más de una persona pueda trabajar sobre el mismo fichero ya que muchas veces se requiere la desprotección de muchos ficheros a la vez para poder cubrir una funcionalidad. Y como no, la desventaja es que si otra persona ha modificado algún fichero mientras otro desarrollador lo tenia desprotegido, dependiendo de la envergadura de los cambios, el proceso de combinación se puede hacer muy tedioso.

¿Y qué modelo usa Team Foundation Server?

Ya que el producto que se utilizaba para la gestión del código fuente antes que Team Foundation Server era Visual Source Safe (hablando de entornos Microsoft) y este utilizaba el modelo Lock-Modify-Unlock, mucha gente piensa que el modelo de TFS es este mismo, pero se equivocan. Team Foundation Server se ha definido como un producto extensible y personalizable desde su base y el modelo de trabajo contra el repositorio de código fuente no es una excepción. En Team Foundation Server se puede usar el modelo que más nos convenga según el contexto en que nos encontremos, y este modelo lo podremos definir a nivel de Team Project.

Para definir el modelo de trabajo bastará con hacer click con el boton derecho sobre el Team Project que queramos configurar en el árbol que se muestra en el Team Explorer y seleccionar la opción "Source Control" que se encuentra bajo el menú "Team Project Settings".

También podemos realizar esta misma tarea desde el menú "Team" que aparece en la barra de menús, aunque el resultado es el mismo, una ventana de configuración en la que podemos definir si queremos permitir multiples ediciones sobre un mismo fichero o no, es decir, modelo Copy-Modify-Merge o Lock-Modify-Unlock.

Simplemente marcando la opción que se ve en la imagen de arriba estaríamos definiendo un modo de trabajo Copy-Modify-Merge. Si lo demarcásemos, no permitiríamos que un mismo fichero fuese editado por mas de una persona, convirtiendo nuestro modelo de trabajo en Lock-Modify-Unlock automáticamente. Como decía al principio de este post, uno no es mejor que el otro, todo depende de nuestro contexto.

Este es un tema del que se podría escribir mucho más, pero dada la extensión del post creo que por ahora es suficiente, quizás en futuro retomemos el tema si es necesario, que lo será cuando veamos temas de compilaciones programadas y el valor de que el código que se encuentre en el repositorio siempre debe compilar.