maven-2 - proyecto - maven tutorial pdf
¿Las mejores prácticas de Maven para generar artefactos para múltiples entornos[prod, test, dev] con soporte de CI/Hudson? (6)
Tengo un proyecto que necesito desplegar en múltiples entornos ( prod, test, dev ). Las principales diferencias consisten principalmente en las propiedades de configuración / archivos.
Mi idea fue utilizar perfiles y superposiciones para copiar / configurar el resultado especializado. Pero estoy atrapado en si tengo que generar múltiples artefactos con clasificadores especializados (por ejemplo, "my-app-1.0-prod.zip/jar", "my-app-1.0-dev.zip/jar") o debería crear múltiples proyectos, un proyecto para cada entorno?
¿Debo usar maven-assembly-plugin para generar múltiples artefactos para cada entorno? De todos modos, tendré que generarlos todos a la vez para que los perfiles no encajen ... aún desconcertados :(
Cualquier consejo / ejemplo / enlace será más que bienvenido.
Como tema adicional, también me pregunto cómo lograr esto en un CI Hudson / Bamboo para generar e implementar estos artefactos generados para todos los entornos, en sus servidores adecuados (por ejemplo, utilizando el complemento SCP Hudson).
Implementamos un complemento de m2 para construir las propiedades finales utilizando el siguiente enfoque:
- Las configuraciones comunes que no reconocen el entorno se leen desde common.properties.
- Las configuraciones específicas que respetan el entorno se leen desde dev.properties, test.properties o production.properties, por lo que se anulan los valores predeterminados si es necesario.
- Los archivos .properties finales se escriben en el disco con la instancia de Propiedades después de leer los archivos en el orden dado.
- Dicho archivo .properties es lo que se agrupa según el entorno de destino.
Intente usar https://github.com/khmarbaise/multienv-maven-plugin para crear un WAR principal y un JAR de configuración para cada entorno.
Prefiero empaquetar los archivos de configuración por separado de la aplicación. Esto le permite ejecutar la misma aplicación EXACTA y suministrar la configuración en tiempo de ejecución. También le permite generar archivos de configuración después de un entorno que no sabía que necesitaría en el momento de la compilación. por ejemplo, CERT. Utilizo la herramienta "ensamblaje" para comprimir los archivos de configuración de cada dominio en archivos con nombre.
Tuve este escenario exacto el verano pasado.
Terminé usando perfiles para cada entorno superior con clasificadores. El perfil predeterminado fue "no hacer daño", la construcción de desarrollo. Tenía un perfil DEV, INT, UAT, QA y PROD.
Terminé definiendo varios trabajos dentro de Hudson para generar los artefactos específicos de la región.
Lo único que habría hecho de otra manera fue diseñar los proyectos de manera un poco diferente, de modo que la construcción específica de la región quedara fuera del proyecto principal modularizado. Eso era simplemente tirar en los últimos artefactos para cada compilación específica en lugar de reconstruir el proyecto completo para cada región.
De hecho, cuando configuré los trabajos, los trabajos de control de calidad y PROD siempre se configuraron para construir a partir de una etiqueta. Claramente, esto es algo que usted adaptaría a las reglas específicas de su lugar de trabajo sobre la implementación.
Usamos los perfiles para lograrlo, pero solo tenemos el perfil predeterminado, que llamamos perfil de "desarrollo", y tiene archivos de configuración, y tenemos un perfil de "versión", donde no incluimos los archivos de configuración (por lo tanto, se pueden configurar correctamente cuando se instala la aplicación).
Usaría los perfiles para hacerlo, y agregaría el perfil en el nombre del artefacto si necesita implementarlo. Creo que es algo similar a lo que Pascal había sugerido, solo que usarás perfiles y no versiones.
PD: Otra razón por la que solo tenemos perfiles de desarrollo / lanzamiento, es que cada vez que enviamos algo para UAT o PROD, se ha lanzado, por lo que si hay un error podemos rastrear cuál era el estado del código cuando se aplicó la aplicación. publicado: es más fácil etiquetarlo en SVN que intentar encontrar su estado en el historial de confirmación.
Utilizaría el elemento de version (como 1.0-SNAPSHOT, 1.0-UAT, 1.0-PROD) y, por lo tanto, etiquetas / sucursales en el nivel VCS en combinación con perfiles (para entornos específicos como nombres de máquinas, contraseñas de nombres de usuarios, etc.), construir los diversos artefactos.