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?
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
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