La mejor solución de proceso de compilación para gestionar versiones de compilación

Question

Ejecuto un proyecto bastante complejo con varias aplicaciones independientes.Sin embargo, estos utilizan un par de componentes compartidos.Entonces tengo un árbol de origen que se parece al siguiente.

• Mi proyecto
  • Aplicación A
  • Compartido1
  • Compartido2
  • Aplicación B
  • Aplicación C

Todas las aplicaciones tienen su propio script MSBuild que crea el proyecto y todos los recursos compartidos que necesita.También ejecuto estas compilaciones en un servidor de compilación de integración continua controlado por CruiseControl.

Cuando se implementan las aplicaciones, se implementan en varios servidores para distribuir la carga.Esto significa que es extremadamente Es importante realizar un seguimiento de qué compilación/revisión se implementa en cada uno de los diferentes servidores (necesitamos tener la versión actual en la versión DLL, por ejemplo “1.0.0.68”).

Es igualmente importante poder recrear una revisión/compilación que se haya creado para poder revertirla si algo no funcionó como se esperaba (o sí, eso sucede...).Hoy usamos SourceSafe para el control de fuente, pero eso es posible cambiar si pudiéramos presentar buenas razones para ello (SS, en realidad está funcionando bien para nosotros). entonces lejos).

Otro principio que intentamos seguir es que solo implementamos el código que ha sido creado y probado por el servidor de integración.

Solución "Etiquetas de compilación CrusieControl"

Teníamos varias ideas para resolver lo anterior.La primera fue hacer que el servidor de integración continua construyera, implementara localmente el proyecto y lo probara (lo hace ahora).Como probablemente sepa, una compilación exitosa en CruiseControl genera una etiqueta de compilación y supongo que de alguna manera podríamos usarla para configurar la versión DLL de nuestros ejecutables (por lo que la etiqueta de compilación 35 crearía una DLL como “1.0.0.35”).La idea también era utilizar esta etiqueta de compilación para etiquetar el completo árbol fuente.Entonces probablemente podríamos verificar esa etiqueta y recrear la compilación más adelante.

La razón para etiquetar el árbol completo es incluir no solo el código de la aplicación real (que está en un lugar del árbol fuente) sino también todos los elementos compartidos (que están en diferentes lugares del árbol).Entonces, una compilación exitosa de la "Aplicación A" etiquetaría todo el árbol con la etiqueta "AplicaciónA35", por ejemplo.

Sin embargo, puede haber un problema al intentar recrear esta compilación y configurar la versión de DLL antes de implementarla, ya que entonces ya no tendremos acceso a la etiqueta de compilación generada por CruiseControl.Si todas las etiquetas de compilación de CrusieControl fueran únicas para todos los proyectos, podríamos usar solo el número para etiquetar, pero ese no es el caso (tanto la aplicación A como la B podrían estar al mismo tiempo en la compilación 35), por lo que tenemos que incluir el nombre de la aplicación en el etiqueta.De ahí la etiqueta de SourceSafe "Application35". ¿Cómo puedo entonces recrear la compilación 34 y configurar 1.0.0.34 con los números de versión de DLL una vez que hayamos creado la compilación 35?

Solución de "número de revisión"

Alguien me dijo que Subversion, por ejemplo, crea un número de revisión para todo el árbol fuente en cada registro. ¿Es este el caso?¿SourceSafe tiene algo similar? Si esto es correcto, la idea es obtener ese número de revisión cuando obtenga la última versión y compilarlo en el servidor CruiseControl.El número de revisión podría usarse para configurar el número de versión de la DLL (por ejemplo, “1.0.0.5678”).Supongo que entonces podríamos obtener esta revisión específica para Subversion si fuera necesario y eso incluiría esa aplicación y todos los elementos compartidos para poder recrear una versión específica del pasado. ¿Funcionaría? ¿Podría lograrse también utilizando SourceSafe?

Resumir

Entonces los dos requisitos principales son:

1. Ser capaz de rastrear el número de compilación/revisión de la compilación y la DLL implementada.
2. Ser capaz de reconstruir una revisión/compilación anterior, establezca el número de compilación/revisión anterior en los ejecutables de esa compilación (para cumplir con el requisito 1).

Entonces, ¿cómo resolverías esto? ¿Cuál sería su enfoque preferido y cómo ¿Lo resolverías (o tienes una idea totalmente diferente?)?** Por favor, dé respuestas detalladas.**

Pregunta extra ¿Cuál es la diferencia entre un número de revisión y un número de compilación y cuándo se necesitarían realmente ambos?

Answer 1

Su plan es sólido y factible en VSS (aunque le sugiero que considere una alternativa, VSS es realmente un producto obsoleto).

Para su compilación "CI", debería echar un vistazo al control de versiones Proyecto de tareas comunitarias de MSBuild que tiene una "Versión" de tareas.Por lo general, tendrá un "Version.txt" en su árbol de fuentes y la tarea de MSBuild incrementará el número de "Versión" mientras los desarrolladores controlan los números de Major.Minor.Release.Revision (así es como lo quería un cliente mío).Puede utilizar la revisión si lo prefiere.

Luego tendrá tareas de "FileUpdate" para editar el archivo AssemblyInfo.cs con esa versión, y sus EXE y "DLL" tendrán la versión deseada.

Finalmente, la tarea VSSLabel etiquetará todos sus archivos de forma adecuada.

Para su compilación "Reconstruir", modificaría su "Obtener" para obtener archivos de esa etiqueta, obviamente no ejecutaría la tarea "Versión" (ya que está SELECCIONANDO una versión para compilar) y luego las tareas FileUpdate usarían ese número de versión.

Pregunta extra:

Todos estos son "cómo quieres usarlos". Yo usaría el número de compilación, bueno, el número de compilación, eso es lo que incrementaría.Si está utilizando CI, tendrá muchas compilaciones, la gran mayoría sin intención de implementarlas en ningún lugar.

El mayor y el menor son evidentes, pero la revisión siempre la he usado para un indicador de "Revisión".Tengo la intención de tener una versión "1.3", que en realidad sería un producto con, digamos, la versión 1.3.1234.0.Mientras trabajo en 1.4, encuentro un error y necesito una solución urgente como 1.3.2400.1.Luego, cuando 1.4 esté listo, diría 1.4.3500.0

Answer 2

Necesito más espacio del que responden ya que los comentarios directamente me lo permiten...

¡Gracias!¡Buena respuesta!¿Cuál sería la diferencia, qué sería mejor resolver esto usando la subversión, por ejemplo? Richard Hallgren (hace 15 horas)

Los problemas con VSS no tienen nada que ver con este ejemplo (aunque creo que la función "Etiquetado" está implementada de manera ineficiente...)

Éstos son algunos de los problemas con VSS

1) La ramificación es básicamente imposible 2) el pago compartido generalmente no se usa (sé de algunas personas que han tenido éxito con ella) 3) El rendimiento es muy pobre: ​​es externo "charla" 4) a menos que tenga un repositorio muy pequeño - Es completamente poco confiable, hasta el punto de la mayoría de las tiendas es una bomba de tiempo.

Para 4, el problema es que VSS se implementa mediante la representación de todo el repositorio como "archivos planos" en el sistema de archivos.Cuando el repositorio supera un cierto tamaño (creo que 4 GB, pero no estoy seguro de esa cifra), existe la posibilidad de que se produzca "corrupción".A medida que aumenta el tamaño, las posibilidades de corrupción crecen hasta convertirse en casi una certeza.

Así que eche un vistazo al tamaño de su repositorio, y si está ingresando a los Gigabytes, le recomiendo encarecidamente que comience a planificar el reemplazo de VSS.

Independientemente, un google de "VSS Sucks" da 30.000 visitas...Creo que si comienzas a usar una alternativa, te darás cuenta de que vale la pena el esfuerzo.

Answer 3

1. Haga que CC.net etiquete las compilaciones exitosas
2. Haga que cada proyecto en la solución se vincule a un archivo Solutioninfo.cs común que contenga atributos de versión de archivo y ensamblaje (elimine de cada proyecto Assemblyinfo.cs).
3. Antes de la compilación, haga que el control de crucero ejecute un reemplazo de expresiones regulares de msbuild (de las tareas de la comunidad de msbuild) para actualizar la información de la versión utilizando la etiqueta de compilación de cc.net (pasada como parámetro a la tarea de msbuild)
4. construir la solución, ejecutar pruebas, hacer cambios, etc.
5. Opcionalmente, revierta el archivo de información de la solución.

El resultado es que todos los ensamblados en la compilación publicada en cc.net tienen los mismos números de versión que se ajustan a una etiqueta en el repositorio de código fuente.

Answer 4

UppercuT puede hacer todo esto con una tarea de empaquetado personalizada para dividir las aplicaciones.Y para obtener el número de versión de la fuente, podrías pensar en Subversion.

También es increíblemente fácil comenzar.

http://code.google.com/p/uppercut/

Algunas buenas explicaciones aquí: Uppercut