Servidores de aplicaciones incrustadas en Sonatype Nexus, Jenkins y Collabnet Subversion Edge

Necesito configurar un entorno de desarrollo de construcción que incluya lo siguiente

  • Sonatype Nexus
  • Jenkins
  • Subversion Collabnet

Mi aplicación se ejecuta en un server de aplicaciones GlassFish. Noté que las tres herramientas anteriores vienen con serveres de aplicaciones integrados. He descargado cada uno y los he probado, pero desconfío un poco del hecho de que ahora tengo 4 serveres de aplicaciones en ejecución.

Me di count de que cada uno de ellos también proporciona una variante de file de guerra que se puede colocar en un server de aplicaciones existente. Creo que con "Edge Subversion Collabnet" probablemente no tenga otra opción, ya que no viene con una opción de installation de guerra. Los otros dos se pueden download como files war.

¿Cuáles son las desventajas de ejecutar Nexus y Jenkins en el mismo server de aplicaciones? ¿Hay algún inconveniente? Lo que estoy investigando en este momento es cómo configurarlo. Parece que solo se puede configurar una vez que los files de guerra hayan sido explotados / desarchivados por el server de aplicaciones.

También soy reacio a colocar estos files war en la instancia existente de Glassfish, ya que se usa para testings formales. Creo que debería instalar Tomcat y usarlo para estas herramientas. ¿Me recomendaría que me quede con los serveres integrados o simplemente use un server de aplicaciones y asigne más memory cuando sea necesario? ¿Alguna de estas herramientas funciona mejor con sus serveres integrados o no hace ninguna diferencia?

Gracias

Hudson / Jenkins y Nexus pueden ejecutarse como files de guerra en Tomcat o Glassfish. Sin embargo, para ambos la opción preferida y mejor respaldada es usar el server de aplicaciones incluido.

Nexus usa Jetty internamente. Hudson 3 (beta de Eclipse) también lo hace. Old Hudson y Jenkins usan Winstone internamente. Ambos son contenedores MUY livianos y la sobrecarga de su funcionamiento uno al lado del otro debe ser insignificante.

Obtendrá mucho más impacto de lo que estos serveres realmente hacen (ejecutando comstackciones, sirviendo artefactos, etc.).

Para facilitarle la vida en la installation, las actualizaciones y el soporte de time de ejecución, le sugiero que se quede con los serveres de aplicaciones pnetworkingeterminados.

Las 3 herramientas pueden compartir una única instancia de Glassfish (o server de aplicaciones similar). El problema es que te vuelves responsable de configurar los parameters de event handling memory sensible. Si una aplicación causa una exception de Java OutOfMemory, todas las aplicaciones se verán potencialmente afectadas 🙁

Si comtesting las secuencias de commands del iniciador para las distintas aplicaciones, descubrirá que cada set establece valores pnetworkingeterminados diferentes para las configuraciones de montón y permgen de Java.

Mi recomendación es mantener aisladas cada aplicación y usar los serveres de aplicaciones integrados. Jenkins y Nexus son bastante livianos (no uso Collabnet).

No he usado a Jenkins, pero he visto a nexus y hudson ejecutados en una única instancia de tomcat ejecutando guerras separadas. Para Nexus, la única diferencia entre la versión de guerra y la versión independiente es que la versión independiente incluye embarcadero para que pueda ejecutarlo de manera independiente … pero eso es solo el envoltorio. El nexo actual es el mismo.

Asumo que lo mismo es cierto para Jenkins también. Entonces no hay razón para ejecutar 4 serveres cuando podría ejecutar 4 instancias en un server. Debería funcionar bien ya que todos tendrán diferentes contexts web.