¿Sugerencias para administrar dependencias para una versión?

Question

Nuestro sistema comprende muchos sitios web .NET, bibliotecas de clases y una base de datos MSSQL. Usamos SVN para control de fuente y TeamCity para compilar automáticamente a un servidor de prueba.

Nuestro equipo normalmente trabaja en 4 o 5 proyectos a la vez. Tratamos de agrupar muchos cambios en un lanzamiento largish cada 2-4 semanas.

Mi problema es hacer un seguimiento de todas las dependencias para un despliegue. Ejemplo:

El sitio web A no se puede ejecutar hasta que hayamos desplegado la biblioteca B de Branch X of Class, construida a su vez contra la biblioteca C de Trunk of Class, que necesita Actualizaciones de configuración Y y Z y Database Update D, necesita script de migración e ...

se hace aún más compleja - como asegurarse de que el proyecto de cada desarrollador es en realidad compatible con los otros y están construyendo en contra de las mismas versiones. Sí, este es un problema de gestión tanto como un problema técnico.

Actualmente nuestra solución no óptima es:

• una pizarra lista de características que no han entrado en producción todavía
• confiar en nuestra memoria e intuición en la planificación de la implantación, hasta estamos bastante seguros hemos pensado en todo ...
• un funcionamiento en seco en nuestro entorno de ensayo. Es una buena indicación, pero a menudo no estamos seguros de si la puesta en escena está 100% sincronizada con Live, parte del problema que espero resolver.
• cierta cantidad de alas en el día de lanzamiento.

Hasta ahora todo bien, menos algunas llamadas cercanas. Pero a medida que nuestro sistema crece, me gustaría un sistema de administración de versiones más científico que permita más flexibilidad, como poder implementar un solo cambio o una corrección de errores por sí mismo, seguro sabiendo que no romperá ninguna otra cosa.

Supongo que la mejor solución implica algún tipo de sistema de numeración de versiones, y tal vez el uso de una herramienta de gestión de proyectos. Somos una empresa nueva, por lo que no estamos demasiado entusiasmados con la adhesión religiosa a procesos rígidos, pero estamos felices de comenzar, siempre que no agregue más gastos generales de los que vale.

Me encantaría escuchar los consejos de otros equipos que han resuelto este problema.

Answer 1

Parece que ya tiene instalado un Servidor de integración continua, pero no lo usa correctamente. Parte del problema es que no sabes qué cambios terminarán en un lanzamiento y cuáles no.

Supongo que todos sus proyectos son parte de un proyecto abarcador, para el cual existe un repositorio de control de origen. Como primera medida, debe intentar separar su código en código de desarrollo frente a código estable/para ser publicado en las sucursales. Configure Teamcity para hacer una compilación completa de la rama estable regularmente. Si un conjunto de cambios está listo para su publicación, el creador del cambio debe ser responsable de fusionarlos, junto con todas las dependencias, en la rama estable. CI le dirá si todo fue bien o no. La idea de CI es que estés "siempre listo para el lanzamiento".

Mencionó que hay varios proyectos en los que su equipo está trabajando constantemente y que tienen ciertas interdependencias.Esto me hace un poco sospechoso:

• Si los proyectos son interdependientes, ¿por qué están separados? Incluso si evolucionan a diferentes velocidades, ¿realmente necesitan estar separados?
• ¿En consecuencia tiene repositorios diferentes para cada proyecto? Esto hará que la liberación sea realmente difícil.
• ¿Se pueden gestionar las dependencias en un nivel binario? ¿O hay dependencias de tiempo de compilación?

En mi experiencia, siempre es más fácil administrar dependencias a nivel binario (simplemente actualice una biblioteca en su proyecto). Por otro lado, nunca he tenido la situación en que los proyectos no relacionados dependan del mismo dll (que es una aplicación en sí misma y no solo una biblioteca de utilidad o algo así). En este caso, es más fácil administrar dependencias en el nivel de origen.

Al final, una idea aleatoria: si utiliza un sistema de control de versiones distribuidas (como git o mercurial), tener todos los códigos en el mismo repositorio sería muy fácil. Cada proyecto puede tener su propia sucursal, que se actualiza periódicamente con los últimos cambios de la rama principal (integración directa). Cuando se completa un cambio, la rama del proyecto se fusiona de nuevo en la rama principal (integración inversa). El equipo de Windows en Microsoft creó este flujo de trabajo.