none
Branches Plan y Espacio en disco en servidor de Team System / Source Control RRS feed

  • Debate general

  • Hola,

    Me ayudan con este tema?¿?

    Voy a implementar Branches en un proyecto y tengo dudas respecto a cual sería la implementación más recomendada y al espacio utilizado en el servidor.

    La situación es la siguiente:,

    un proyecto que cada:

    15 días: cerramos iteraciones, (1.0.1, 1.0.2, 1.0.3, 1.0.4, etc...)

    30/45 días: Una de esas iteraciones (no siempre es la última) se envía a algunos clientes cerrando una versión.

    Los clientes No siempre tienen todos las mismas versiones implementadas.

    Todos estos cambios actualmente se trabajan sin branches y sobre una ruta del source control del team.

    Solución pensada:

    2 Branches fijas +1 por cada iteración que se cierre.

    + Dev (a) (Contiene el código con el que se viene trabajando hasta el momento)

    --+ Main (b)

    ----+ v1.0.0 (c)

    ----+ v1.0.1 (c)

    ----+ v1.0.2 (c)

    ----+ v1.0.3 (c)

    ----+ v1.1.0 (c)

    Las branches (c) se generan desde Main ante cada Cierre de Iteración / Versión. y de la misma manera se eliminan cuando van quedado obsoletas (si no pasó las pruebas de QA y/o todos los clientes tienen versiones posteriores).

    Tener en cuenta que varias veces se encuentran bugs en versiones anteriores que hay que solucionar y recompilar la misma iteración

    Preguntas:

    A) es válido este plan?

    B) Me preocupa el espacio en disco de cada una de las branches eliminadas ya que aunque se eliminen se guarda un historial en el Team (ver estados anteriores de los archivos etc). además periodicamente se hacen backups completos de los servidores del Team.

    C) Al hacer una branch, en el servidor, realmente se duplican todos los archivos o solamente lo aparenta guardando solamente los archivos modificados? y de duplicarlo: ¿Hay forma de eliminar las branches completamente y liberar el espacio en disco del servidor (que no guarde un historial de esos cambios)

    Desde ya muchas gracias por las respuestas y opiniones.






    miércoles, 6 de junio de 2012 21:39

Todas las respuestas

  • Hola Gonzalo:

    A) El plan me parece válido, se ajusta a vuestra principal necesidad que es tener claramente identificado el código de cualquier versión en producción. Sólo aconsejarte que Dev sea hija de Main y no al revés. Es un cambio más de concepto que funcional, pero deja las cosas más ordenadas y facilita la visibilidad en los diagramas de jerarquías de ramas, además de hacer Main el padre de todo y el lugar donde se integra todo. Aparte de eso, podrías plantearos sub-ramificar Dev con algún modelo que os de más potencia como las ramas por característica, aunque esto depende bastante de vuestra forma de trabajar durante el desarrollo.

    B) Las ramas no suelen representar problemas de espacio; al hacer una rama en TFS, internamente simplemente se guarda un "puntero" al origen, y sólo se van almacenando las diferencias a medida que se hacen modificaciones. Además, estas diferencias por lo general son cambios sobre ficheros de código fuente, que son texto, y por lo tanto ocupan muy poco. Los problemas con muchas ramas suelen ser más que por espacio, por la sobrecarga "visual" de ver tantas ramas en el servidor, pero si las vas eliminando como indicas, no tendrías ese problema (a no ser que activéis la visualización de ficheros eliminados en Team Explorer). La cosa cambia si tus ramas contienen muchos ficheros binarios de gran tamaño (por ejemplo imágenes, o compilados, lo cual no es recomendable a no ser que se trate de dependencias), y hacéis muchos cambios sobre ellos. Pero si la actividad sobre los binarios es normal yo no me preocuparía demasiado, comenzaría a usar el modelo y vería cómo va evolucionando el tamaño de la base de datos de TFS.

    C) Como te he comentado en el punto anterior al ramificar no se duplica el contenido en la base de datos, y sólo se guardan las diferencias. No obstante si queréis eliminar una rama, o cualquier fichero o carpeta del servidor para siempre y con todo o parte del histórico, podéis usar "tf destroy" desde línea de comandos (http://msdn.microsoft.com/en-us/library/bb386005.aspx). Mucho cuidado que es irreversible, así que no os aficionéis a usarlo con frecuencia, sólo si hay una necesidad clara.

    Espero que sea de ayuda...

    Un saludo!!!

    miércoles, 6 de junio de 2012 22:49
  • Hola Gonzalo:

    A) El plan me parece válido, se ajusta a vuestra principal necesidad que es tener claramente identificado el código de cualquier versión en producción. Sólo aconsejarte que Dev sea hija de Main y no al revés. Es un cambio más de concepto que funcional, pero deja las cosas más ordenadas y facilita la visibilidad en los diagramas de jerarquías de ramas, además de hacer Main el padre de todo y el lugar donde se integra todo. Aparte de eso, podrías plantearos sub-ramificar Dev con algún modelo que os de más potencia como las ramas por característica, aunque esto depende bastante de vuestra forma de trabajar durante el desarrollo.

    B) Las ramas no suelen representar problemas de espacio; al hacer una rama en TFS, internamente simplemente se guarda un "puntero" al origen, y sólo se van almacenando las diferencias a medida que se hacen modificaciones. Además, estas diferencias por lo general son cambios sobre ficheros de código fuente, que son texto, y por lo tanto ocupan muy poco. Los problemas con muchas ramas suelen ser más que por espacio, por la sobrecarga "visual" de ver tantas ramas en el servidor, pero si las vas eliminando como indicas, no tendrías ese problema (a no ser que activéis la visualización de ficheros eliminados en Team Explorer). La cosa cambia si tus ramas contienen muchos ficheros binarios de gran tamaño (por ejemplo imágenes, o compilados, lo cual no es recomendable a no ser que se trate de dependencias), y hacéis muchos cambios sobre ellos. Pero si la actividad sobre los binarios es normal yo no me preocuparía demasiado, comenzaría a usar el modelo y vería cómo va evolucionando el tamaño de la base de datos de TFS.

    C) Como te he comentado en el punto anterior al ramificar no se duplica el contenido en la base de datos, y sólo se guardan las diferencias. No obstante si queréis eliminar una rama, o cualquier fichero o carpeta del servidor para siempre y con todo o parte del histórico, podéis usar "tf destroy" desde línea de comandos (http://msdn.microsoft.com/en-us/library/bb386005.aspx). Mucho cuidado que es irreversible, así que no os aficionéis a usarlo con frecuencia, sólo si hay una necesidad clara.

    Espero que sea de ayuda...

    Un saludo!!!

    Muchas gracias por tu respuesta y la dedicación para ayudarme en mi caso;

    Me quedó una duda respecto a la implementación de Main como branch principal ya que llevamos 3 años usando una carpeta "proyecto" y desarrollando sobre la misma con todo el historial de cambios que eso incluye. Ese seguimiento no se tiene que perder con esta implementación de branches.

    Por eso mi primera propuesta fué hacer Dev -> Main -> Rel En donde Dev sea el nuevo nombre de "proyecto" para no perder el seguimiento e historial sobre el código.

    Para implementar el plan que me recomendas, tendría que hacer lo siguiente:

    1) Renombrar: "proyecto" a Main

    2) Branch de Main llamada Dev

    3) Branch de Main llamada V1503

    Consulta:  Si hago esto esto, en Dev, ¿sigo teniendo el historial de cambios de los archivos anteriores a la implementación de Branches? y de la misma forma poder usar usar: GetSpecificVersion, Annotate, view History, ETC....

    Muchas Gracias

    jueves, 7 de junio de 2012 14:29
  • El proceso que indicas es justo el que te recomendaba, renombrando proyecto a Main y ramificando desde ahí. Yo además suelo tener una carpeta Release que contenga todas las V*, es decir, que el paso 3 yo lo suelo hacer ramificando a Release\V1503 en lugar de a V1503 directamente. De esa forma visualmente queda más organizado y funcionalmente es lo mismo.

    Si renombras proyecto a Main de esta forma, todo el histórico se quedará efectivamente en Main. Pero en TFS 2010 es fácil seguirlo (ojo que todo lo siguiente aplica sólo en 2010, si tienes TFS 2008 no funcionaría así):

    • GetSpecificVersion funcionará de la forma usual, excepto si para un fichero obtienes una versión que es anterior a la operación de branch. En ese caso el fichero "desaparecería" de Dev y tendrías la version bajada en la carpeta donde esté mapeada Main. Puede parecer extraño pero el comportamiento tiene sentido; en esa version aún no existía Dev y por eso al obtenerla el fichero "desaparece" de Dev.
    • Annotate funciona correctamente incluso mostrando los changesets que existían en Main antes de ramificar a Dev.
    • History también sigue las ramas y te muestra los changesets de forma jerárquica, agrupados por la rama en la que se hizo el checkin
    • También tienes las funcionalidades de trazar changesets y ver jerarquías de ramas que te facilitan bastante hacer seguimiento de los cambios

    En general vas a poder seguir el histórico sin problemas. Pero si te es más cómodo tenerlo directamente en Dev, como te decía en la respuesta anterior no hay problema en que Dev sea el padre. Aparte del tema conceptual de que Main ya no sería el padre de todo, en principio debería funcionar todo de la misma forma.

    Un saludo!!!

    jueves, 7 de junio de 2012 22:16