Implementación de Java Web: código de compilación, o despliegue .war?

Question

Dos formas principales de implementar una aplicación web J2EE / Java (en un sentido muy simple):

Implementar artefactos ensamblados en el cuadro de producción

Aquí, creamos .war (o lo que sea) en otra parte, lo configuramos para la producción (posiblemente creando numerosos artefactos para numerosos cuadros) y colocamos los artefactos resultantes en los servidores de producción.

• Pros : no hay herramientas de desarrollo en las cajas de producción, puede reutilizar los artefactos de las pruebas directamente, el personal que realiza la implementación no necesita tener conocimiento del proceso de construcción
• Contras : dos procesos para crear y desplegar artefactos; la configuración potencialmente compleja de artefactos predefinidos podría dificultar el proceso de escritura / automatización; tener que versionar artefactos binarios

Construye los artefactos en la caja de producción

Aquí, el mismo proceso que se usa día a día para crear e implementar localmente en cuadros de desarrollador se usa para implementar en producción.

• Pros : un proceso a mantener; y está fuertemente probado / validado por el uso frecuente. Potencialmente, es más fácil personalizar la configuración en el momento de la creación de artefactos en lugar de personalizar las contraseñas de artefactos predefinidos; no se necesitan versiones de artefactos binarios.
• Contras : herramientas de desarrollo potencialmente complejas necesarias en todas las cajas de producción; el personal de implementación necesita comprender el proceso de construcción; usted no está implementando lo que probó

La mayoría de las veces he usado el segundo proceso, sin duda por necesidad (no hay tiempo / prioridad para otro proceso de implementación). Personalmente, no compro argumentos como "la caja de producción tiene que estar limpia de todos los compiladores, etc.", pero puedo ver la lógica en la implementación de lo que ha probado (a diferencia de construyendo otro artefacto).

Sin embargo, las aplicaciones Java Enterprise son tan sensibles a la configuración, que parece tener problemas para tener dos procesos para configurar artefactos.

¿Pensamientos?

Actualizar

Aquí hay un ejemplo concreto:

Usamos OSCache, y habilitamos el caché de disco. El archivo de configuración debe estar dentro del archivo .war y hace referencia a una ruta de archivo. Este camino es diferente en cada entorno. El proceso de compilación detecta la ubicación configurada del usuario y asegura que el archivo de propiedades colocado en la guerra sea correcto para su entorno.

Si tuviéramos que utilizar el proceso de compilación para la implementación, sería cuestión de crear la configuración correcta para el entorno de producción (por ejemplo, production.build.properties ).

Si tuviéramos que seguir los "desplegar artefactos ensamblados en el cuadro de producción", necesitaríamos un proceso adicional para extraer las propiedades (incorrectas) de OSCache y reemplazarlo por uno apropiado para el entorno de producción.

Esto crea dos procesos para lograr lo mismo.

Entonces, las preguntas son:

• ¿Se puede evitar esto sin compilar en producción " ;?
• Si no, ¿vale la pena? Es el valor de " no compilar en producción " mayor que " No repetirte '" ;?

Answer 1

Estoy firmemente en contra de construir en la caja de producción, porque significa que estás usando una compilación diferente de la que probaste. También significa que cada máquina de implementación tiene un archivo JAR / WAR diferente. Si no es nada más, haga una compilación unificada solo para que cuando realice el seguimiento de errores no tenga que preocuparse por las inconsistencias entre los servidores.

Además, no es necesario poner las compilaciones en el control de versiones si puede asignar fácilmente entre una compilación y la fuente que la creó.

Donde trabajo, nuestro proceso de implementación es el siguiente. (Esto es en Linux, con Tomcat).

1. Pruebe los cambios y regístrese en Subversion. (No necesariamente en ese orden; no requerimos que se pruebe el código comprometido. Soy el único desarrollador a tiempo completo, por lo que el árbol SVN es esencialmente mi rama de desarrollo. Su millaje puede variar).

2. Copie los archivos JAR / WAR en un servidor de producción en un directorio compartido que lleva el nombre del número de revisión de Subversion. Los servidores web solo tienen acceso de lectura.

3. El directorio de implementación contiene enlaces simbólicos relativos a los archivos en los directorios con nombre de revisión. De esa manera, una lista de directorios siempre le mostrará qué versión del código fuente produjo la versión en ejecución. Al implementar, actualizamos un archivo de registro que es poco más que un listado de directorios. Eso hace que los roll-backs sean fáciles. (Sin embargo, hay que tener en cuenta que Tomcat comprueba si hay nuevos archivos WAR antes de la fecha de modificación del archivo real, no el enlace simbólico, por lo que tenemos que tocar el archivo antiguo cuando retrocedemos).

Nuestros servidores web descomprimen los archivos WAR en un directorio local. El enfoque es escalable, ya que los archivos WAR están en un solo servidor de archivos; podríamos tener un número ilimitado de servidores web y solo realizar una implementación.

Answer 2

La mayoría de los lugares en los que he trabajado han usado el primer método con información de configuración específica del entorno implementada por separado (y actualizada mucho más raramente) fuera de war / ear.

Answer 3

Recomiendo altamente " Implementar artefactos ensamblados en la caja de producción " como un archivo de guerra. Esta es la razón por la que nuestros desarrolladores utilizan el mismo script de compilación (Ant en nuestro caso) para construir la guerra en su caja de arena de desarrollo, como se usa para crear el artefacto finalmente. De esta manera, se depura así como el código en sí, sin mencionar que es completamente repetible.

Answer 4

Existen servicios de configuración, como el gran peso ZooKeeper , y la mayoría de los contenedores habilitan Usted debe usar JNDI para hacer alguna configuración. Estos separarán la configuración de la compilación, pero pueden ser excesivos. Sin embargo, existen. Depende mucho de tus necesidades.

También he usado un proceso mediante el cual los artefactos se construyen con marcadores de posición para los valores de configuración. Cuando se despliega el WAR, se explota y los marcadores de posición se reemplazan con los valores apropiados.

Answer 5

Defendería el uso de una solución de integración continua que admita compilaciones distribuidas. El código registrado en su SCM puede desencadenar compilaciones (para pruebas inmediatas) y puede programar compilaciones para crear artefactos para el control de calidad. Luego, puede promocionar estos artefactos a producción y desplegarlos.

Esto es en lo que estoy trabajando actualmente en la configuración, utilizando AnthillPro .

EDITAR: Ahora estamos usando Hudson . Muy recomendable!

Answer 6

Si realiza esta pregunta en relación con la administración de la configuración, entonces su respuesta debe basarse en lo que considera un artefacto administrado. Desde la perspectiva de CM, es una situación inaceptable tener una colección de archivos de origen que funcione en un entorno y no en otro. CM es sensible a las variables de entorno, a la configuración de optimización, a las versiones de compilador y de tiempo de ejecución, etc., y tiene que tener en cuenta estas cosas.

Si está haciendo esta pregunta en relación con la creación de procesos repetibles, entonces la respuesta debe basarse en la ubicación y la cantidad de dolor que está dispuesto a tolerar. El uso de un archivo .war puede implicar más dolor inicial para ahorrar esfuerzo en los ciclos de prueba y despliegue. El uso de archivos de origen y herramientas de construcción puede ahorrarle un costo inicial, pero tendrá que soportar un dolor adicional al tratar los problemas al final del proceso de implementación.

Actualización para ejemplo concreto

Dos cosas a considerar en relación con tu ejemplo.

1. Un archivo .war es solo un archivo .zip con una extensión alternativa. Puede reemplazar el archivo de configuración en su lugar utilizando las utilidades zip estándar.

2. Reconsiderar potencialmente la necesidad de colocar el archivo de configuración dentro del archivo .war. ¿Sería suficiente tenerlo en la ruta de clase o tener propiedades especificadas en la línea de comandos de ejecución al inicio del servidor?

En general, intento mantener los requisitos de configuración de la implementación específicos de la ubicación de la implementación.

Answer 7

Utilizar 1 archivos de guerra empaquetados para implementaciones es una buena práctica.
usamos ant para reemplazar los valores que son diferentes entre los entornos. Verificamos el archivo con una variable @@@ que será reemplazada por nuestro script ant. La secuencia de comandos ant reemplaza el elemento correcto en el archivo y luego actualiza el archivo war antes de implementarlo en cada uno

<replace file="${BUILDS.ROOT}/DefaultWebApp/WEB-INF/classes/log4j.xml" token="@@@" value="${LOG4J.WEBSPHERE.LOGS}"/>


<!-- update the war file We don't want the source files in the war file.-->
<war basedir="${BUILDS.ROOT}/DefaultWebApp" destfile="${BUILDS.ROOT}/myThomson.war" excludes="WEB-INF/src/**" update="true"/>

Para resumir, ant lo hace todo y usamos anthill para gestionar ant. ant construye el archivo war, reemplaza las rutas del archivo, actualiza el archivo war y luego se despliega en el entorno de destino. Un proceso, de hecho, un clic de un botón en el hormiguero.