Estructura del proyecto TFS 2010 y get lo mejor de él

Recientemente decidimos pasar a TFS 2010. También nos gustaría mejorar nuestra estructura de control de fuente y proyectos.

aquí está la estructura que el equipo acordó:

|OurCompanyName (or common root name) | +--Windows +----Applications +------App1 +------App2 +----Services +------WindowsService1 +------WindowsService2 | +--Web +----Applications +------WebApp1 +------WebApp2 +----Services +------WebService1 +------WebService2 | +--Common +----ThirdParty +----Libs +------DataAccessLib +------BusinessLogicLib | +--Tests +----TestProject1 +----TestProject1 

La carpeta común contiene files de terceros y nuestras bibliotecas internas, que se utilizan en todas las aplicaciones (App1, App2, WebApp1 … etc.)

Necesitamos lograr lo siguiente:

  • Las versiones de lanzamiento deben depender de la última versión de producción de Libs.
  • si las testings fallaron, los proyectos dependientes no deberían comstackrse y el equipo debería ser notificado.
  • ramificación simple: desarrollo, producción, versiones versionadas y cómo podemos estructurarlas en consecuencia.

Ya leí la siguiente guía de Visual Studio TFS Branching Guide 2010, pero solo aborda el bit de ramificación.

Realmente no estás haciendo una pregunta por lo que puedo decir. Pero puedo dar algunos comentarios / discusiones sobre tus objectives.

  • Las versiones de lanzamiento deben depender de la última versión de producción de Libs.

Una versión de lanzamiento debería depender de lo que sea que se usó mientras se desarrollaba. No es lo que sea la versión actual. Es posible que desee profundizar sobre cuál es este requisito y por qué cree que lo necesita.

  • si las testings fallaron, los proyectos dependientes no deberían comstackrse y el equipo debería ser notificado.

TFS no admite el encadenamiento de comstackciones de fábrica, puede modificar la plantilla de compilation para agregar soporte, pero no es una solución particularmente limpia (imo).

Puede auto-suscribirse a construcciones anómalas utilizando las suscripciones de alertas tfs incorporadas, sin embargo, depende de cada desarrollador hacerlo. (A less que se suscriba a un grupo de correo o cree un envío de events personalizado).

Nuevamente, ¿por qué está actualizando automáticamente las dependencies en otros proyectos? seguramente sería mejor usar un tirón para actualizaciones que un empujón y usar una tecnología como NuGet para manejar sus references.

  • ramificación simple: desarrollo, producción, versiones versionadas y cómo podemos estructurarlas en consecuencia.

Eso suena como una simple ramificación cada vez que haces un lanzamiento, que es muy simple.

Sin embargo, si supiera qué set de cambios libera, no tendría que bifurcarse y podría bifurcarse solo si lo necesitara (por ejemplo, para corregir un error de producción). Se necesita mucho más trabajo ya que es necesario labelr manualmente el código en el momento del lanzamiento (momento en el que no obtienes nada por sobre la bifurcación) o tener un process de lanzamiento automático que lo hace por ti.

Otras notas

No desea utilizar múltiples Colecciones de proyectos de equipo; esto agrega una pesadilla cuando se trata de administrar serveres de compilation.

Es posible que desee actualizar su diagtwig para mostrar qué es Team Project, Branch y qué es una carpeta estándar.

Habiendo usado TFS por un time, me gustaría dar una advertencia: miras las cosas desde el lado del desarrollador, como lo hicimos cuando comenzamos a pensar cómo implementar mejor los proyectos. Sin embargo, también debe tener en count los requisitos de gestión del proyecto.

Tener diferentes proyectos TFS, significa diferentes datos de informes para el administrador.

Por lo tanto, si App1 y WebApp1 son para la persona que ejecuta sus proyectos como parte del mismo proyecto general, entonces si los tiene en diferentes proyectos TFS, las preguntas del formulario: "¿Cuántas horas pasó mi equipo en este proyecto? Serán difíciles contestar. En serio, analizaré este tema antes de decidir sobre la estructura del proyecto.

Ahora con respecto a sus preguntas:

  • Las versiones de lanzamiento deben depender de la última versión de producción de Libs

Como Betty (arriba) menciona, esto no es bueno para la práctica. ¿Qué sucederá si el desarrollo tuvo lugar con la versión de producción de Lib v1.0 y en algún momento durante la estabilización Lib cambió a v2.0?

  • si las testings fallaron, los proyectos dependientes no deberían comstackrse y el equipo debería ser notificado.

Creo que esto es una cuestión de su script de compilation, no de su layout

-simple ramificación

Intentamos implementar un enfoque simple basado en línea principal, donde tenemos una o más twigs de desarrollo (depende realmente de sus requisitos específicos). De vez en cuando, cuando el código dev se considera "estable", es decir, pasa las testings de unidad básica, se fusiona en la línea MAIN. Los desarrolladores continúan, en sus twigs de desarrollo, mientras que el código en la línea MAIN va más allá de las testings. Los errores encontrados se informan y se solucionan inicialmente en las sucursales de DEV y se fusionan de nuevo en la línea principal. Una vez que el código en la línea MAIN sea suficiente, la estabilización comienza en una twig RELEASE. Después de ese punto, las correcciones de errores tienen lugar en la twig RELEASE y vuelven a fusionarse en la línea MAIN. Tenga en count que "estable", "lo suficientemente bueno" son valores que significan cosas diferentes para las organizaciones.