2010-08-04 8 views
6

Estamos en el proceso de adaptar nuestro procedimiento de publicación de compilación & de uno de nuestros productos basados ​​en Java para admitir parches/versiones de revisiones.Enfoque de compilación y entrega de revisiones/parches

Hoy en día, entregamos un paquete de instalación completo (que es un conjunto de paquetes RPM envueltos en un ISO) fuera de nuestra línea de compilación. Sin embargo, nuestro objetivo es también apoyar los envíos incrementales/más finos de actualizaciones/parches también.

Para mantener las cosas simples como un paso inicial, planeamos tener paquetes de RPM más finos y empacar un subconjunto (solo los modificados en el alcance de una versión) de estos RPM en un hotfix ISO dedicado junto con el instalación completa ISO. (También hemos considerado otras opciones como los RPM binarios diff - delta - creando un RPM de revisión por separado, etc.)

Me gustaría saber cómo gestiona su canalización de construcción - empaquetado y control de versiones (ya que está en el núcleo ¿un problema de administración de versiones también para apoyar este tipo de implementaciones de revisiones?

Respuesta

1

quisiera oír acerca de cómo se administrar su construcción de tuberías - envases y control de versiones

presenté un concepto (de trabajo):

Un informe de error como una identificación como bug711 todas las fuentes tocadas para corregir este error serán etiquetadas (Control de versiones) con el informe de errores no.

Esta etiqueta se puede utilizar para verificar todas las fuentes necesarias para crear un parche (en casos de archivos estáticos como html, js, css, etc.) y para fusionar las ramas en la revisión del encabezado.

En el caso del código java, el mínimo para implementar sería un artefacto (jar, ear, war-file). que requiere un reinicio de la aplicación. En el caso de JBoss Application Server, descubrimos que el despliegue 'explotado' nos permite parchar sin tiempos de inactividad.

Realmente depende del entorno del servidor y del tipo de aplicaciones que enfoque sería el mejor para usted. Me temo que no hay una mejor práctica individual.

+0

Por lo que tengo entendido, usted recopila todos los artefactos binarios modificados en una unidad de despliegue Java. ¿Este Java Jar/War es la misma unidad que tendrías en una compilación normal, o es realmente un parche específico? Si es parche específico, entonces, ¿cómo se asegura de que los artefactos en ese contenedor vayan al lugar correcto en su directorio explotado JBoss? Otra cosa difícil es, entonces, ¿cómo rastrear qué parche está instalado en un sistema de cliente? (Usamos versiones de RPM y un archivo dedicado para rastrear esto) – Erdem

+0

Los parches contienen solo unos pocos archivos para corregir un error. Jar/war se compila de la misma manera que la versión completa (más de 70 artefactos) y se coloca en un repositorio de versiones. Para solucionar un error solo se instalarán los archivos relevantes, menos trabajo para QA. Los parches se construyen automáticamente al finalizar la compra con bugreport # y se rastrean en un db. (prueba, lanzamiento, instalación ...) – stacker

Cuestiones relacionadas