La forma correcta de implementar un proyecto web Java

Desarrollé un proyecto de servicio web Java en mi caja local. Ha funcionado bien con mis pruebas. Ahora necesito implementar este proyecto en un servidor remoto, al que se le asignará un nombre de dominio estático para nuestro departamento. Busqué en todas partes y finalmente encontré las siguientes formas de implementar un proyecto web.

1. Implementar artefactos ensamblados en la caja de producción

Aquí, creamos el archivo .war, lo configuramos para producción (posiblemente creando numerosos artefactos para numerosas cajas) 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 conocimientos del proceso de compilación
Contras: dos procesos para crear y desplegar artefactos; la configuración potencialmente compleja de artefactos prediseñados podría dificultar la secuenciación / automatización del proceso; tener que versionar artefactos binarios

2. Construye los artefactos en la caja de producción.

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

Pros: Un proceso para mantener; y está fuertemente probado / validado por uso frecuente. Potencialmente más fácil de personalizar la configuración en el momento de la creación del artefacto en lugar de personalizar el epílogo del artefacto preconstruido; no se necesita control de versiones de artefactos binarios.
Contras: Se necesitan herramientas de desarrollo potencialmente complejas en todas las cajas de producción; el personal de implementación debe comprender el proceso de construcción; no estás implementando lo que probaste
He utilizado principalmente el segundo proceso, ciertamente por necesidad (sin 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 implementar lo que has probado (en lugar de construir otro artefacto).

Sin embargo, las aplicaciones Java Enterprise son tan sensibles a la configuración que se siente como si tuviera problemas con dos procesos para configurar artefactos.

Eso es lo que obtuve de mi compañero de trabajo.

Esta es la forma correcta:

Construir sobre la caja de producción es incorrecto, porque significa que está usando una construcción diferente a la que probó. También significa que cada máquina de implementación tiene un archivo JAR / WAR diferente. Por lo menos, 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 necesita poner las compilaciones en el control de versiones si puede mapear 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 verifique 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 kilometraje puede variar).

2. Copie los archivos JAR / WAR a un servidor de producción en un directorio compartido con 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 una lista de directorios. Eso facilita los retrocesos. (Sin embargo, un problema; Tomcat busca 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 anterior al retroceder).

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 hacer una sola implementación.