En mis años de programación Java y más recientemente Scala, nunca he usado Ant, Maven, Gradle ni ninguna de esas herramientas de compilación para Java. En todas partes donde trabajé había un administrador de compilación que se encargaba de todo eso: compilaba localmente con el IDE para el desarrollo y las pruebas unitarias, luego verificaba el código fuente y notificaba al administrador de compilación quién hizo lo necesario para compila los archivos de todos para el entorno compartido.

Ahora que estoy entre contratos, he estado trabajando en mi propio proyecto autofinanciado y está llegando al punto en que podría ser lo suficientemente bueno como para ganar dinero. Incluso tengo un inversor potencial en línea y planeo mostrarles una versión beta en las próximas semanas.

Pero todo el tiempo solo hago clic en el botón de compilación en el IDE, y crea el archivo Jar y funciona bien. Por supuesto, la sabiduría convencional sugiere que "debería" escribir mis propios scripts Ant / Maven / Gradle y usarlos en lugar del IDE, pero ¿cuáles son las ventajas concretas de eso en mi situación (trabajar solo)?

He leído un poco sobre cómo usar esas herramientas de compilación, y parece que estaría escribiendo cientos de líneas de XML (o Groovy o lo que sea) para hacer lo que hace el IDE con un solo clic (generado por el IDE Ant XML para el proyecto tiene más de 700 líneas). Simplemente parece propenso a errores y requiere mucho tiempo e innecesario para mi situación. Sin mencionar la curva de aprendizaje, que le quitaría tiempo al resto del trabajo que estoy haciendo para preparar el producto para mostrar a la gente.

Te sugiero que consideres usar Maven en lugar de Ant. Si su IDE puede construir su proyecto con un solo clic, entonces es probable que Maven también pueda construir su proyecto prácticamente sin una configuración personalizada.

Y para responder a la pregunta, simplificar el proceso de implementación es un ejemplo concreto. Si está construyendo un distribuible localmente, eso significa que tiene que implementar manualmente ese distribuible en su sistema de producción, e implica que probablemente tuvo que hacer un poco de configuración manual en el sistema de producción para prepararlo para la implementación (instalación de Tomcat , tal vez, o copiando dependencias y recursos requeridos por su aplicación). Esto puede llevar mucho tiempo y puede hacer que la implementación de actualizaciones se convierta en un proceso tedioso y manual. También permite la posibilidad de que cualquier diferencia de configuración menor entre su plataforma de producción y su entorno de desarrollo cause errores oscuros y difíciles de rastrear.

De todos modos, lo que hago para deshacerme de este trabajo pesado manual es que configuro mi proyecto para compilar con Maven, y configuro mi pom.xmlarchivo con toda la información necesaria para (en el caso de una aplicación web Java) encontrar y descargar el versión correcta de Tomcat, instálelo localmente, configure los archivos de configuración de Tomcat correctos, implemente las dependencias del proyecto y el archivo WAR del proyecto, y luego inicie Tomcat. Luego creo un script de shell simple (y también una .batversión para Windows) que usa Maven para compilar e iniciar el servidor:

mvn clean install cargo:start -Dcargo.maven.wait=true

Entonces, en lugar de empaquetar un despliegue en mi entorno de desarrollo y luego empujarlo manualmente a la producción, todo lo que tengo que hacer es sincronizar desde el sistema de control de versiones en el servidor de producción, y luego el sistema de producción mismo construye, instala y ejecuta el desplegable (y lo hace de una manera que es idéntica a cómo se hace en cualquier sistema de desarrollo, minimizando la posibilidad de errores específicos de plataforma o configuraciones incorrectas). Y ya sea en el entorno de desarrollo o producción, todo lo que hago para construir e iniciar el servidor es:

./startServer.sh #or startServer.bat for Windows

Y para implementar una actualización en el entorno de producción, el proceso es simplemente:

1. Detenga la instancia del servidor en ejecución, si la hay.
2. Ejecutar svn update -r<target_release_revision>.
3. Ejecutar ./startServer.sh.

Es simple, fácil de recordar y no es posible hacerlo si tuviera que confiar en usar mi IDE para construir el desplegable para mí. También hace que volver al último buen despliegue conocido sea muy fácil, en caso de que alguna vez sea necesaria una reversión.

Ni siquiera puedo contar la cantidad de tiempo que este enfoque me ha ahorrado al intentar administrar manualmente el proceso de implementación y configuración.

Y, por supuesto, otra respuesta a su pregunta es la gestión automática de dependencias, pero creo que eso ya ha sido cubierto por otras respuestas.

Siempre y cuando su código esté en control de fuente, está bien usar el IDE para hacer sus distribuibles.

Como tienda individual, ¿se dedica mejor su tiempo a agregar nuevas funciones a su producto o escribir scripts de compilación? Algo me dice que no está escribiendo scripts de compilación.

Claro, es más difícil ver los beneficios cuando trabajas solo. Personalmente, he trabajado en muchos proyectos en solitario y no solo escribiría un script de compilación, sino que también tendré problemas para configurar un servidor CI (como Jenkins).

Hay gastos generales, por supuesto, ¿por qué valdría la pena?

• Una compilación reproducible, no vinculada al IDE (o su máquina, si la ejecuta externamente). Si un servidor de compilación lo ejecuta, otras máquinas pueden ejecutarlo.
• La diversión comienza después de las pruebas de construcción y unidad (por cierto: ¿estás seguro de que pruebas antes de cada confirmación? A veces lo olvido). Genere documentación, cree instaladores, ejecute sus herramientas de análisis de código favoritas.
• Su servidor de CI favorito le permite ver gráficos de cobertura de código, fallas de prueba de unidad, etc. a lo largo del tiempo. ¿Tu IDE hace eso?

Para mi proyecto actual, el script crea, ejecuta herramientas de análisis estático, comprime js / css, pruebas unitarias y paquetes en un archivo web. Jenkins lo ejecuta después de cada confirmación e implementa el proyecto en un servidor de prueba.

Me tomé el tiempo para configurar esto (el script de compilación es quizás de 300 líneas por cierto, no lo he tocado en meses) y puedo decir que vale la pena, incluso para una persona. Para más de una persona, es necesario. Mi participación en el proceso de compilación / implementación consiste en los comandos "hg commit" y "hg push".

Beneficios de las herramientas de construcción

Es un breve resumen que muestra la punta del iceberg, y no necesariamente notará la importancia de todo esto a menos que necesite hacer una combinación de muchos proyectos, proyectos grandes y equipo de mediano a gran. Pero si tiene fe y lo intenta, obtendrá los beneficios .

Facilitan su ciclo de vida de desarrollo y le permiten:

• Organiza y estructura tus proyectos de manera consistente y sin esfuerzo
• reutilizar las buenas prácticas en todos los proyectos y ponerlas en marcha fácil y rápidamente ,
• integrar múltiples proyectos en una sola construcción,
• automatice su proceso de integración continua ,
• comparte tu proyecto con otros
  • sin obligarlos a usar un kit de herramientas específico o IDE (aparte del sistema de compilación),
  • y sin sorprenderlos ya que esperarán una construcción estándar
• automatizar y facilitar el mantenimiento de su producto
• automatizar el proceso de lanzamiento de su producto

Si aplicamos esto a Maven ...

Para aquellos de ustedes en el mundo de Java y que usan Maven , al leer esto, naturalmente asociaron cada punto con:

• Convención de proyecto estructurado de Maven
• Arquetipos de Maven
• Materializando un proyecto de SCM y construcciones de reactores
• Jenkins / Hudson / Bamboo / otro soporte + soporte de Maven para prácticas de pruebas de integración
• m2eclipse, soporte nativo de IntelliJ o NetBeans, o mvnsh para la línea de comando
• versiones-maven-plugin
• plugin maven-release, plugin buildnumber-maven-plugin y versiones-maven-plugin

Y, por supuesto, Maven (pero también otras herramientas) le brinda gestión de dependencia , y eso es un gran ahorro de tiempo y espacio para usted (en función de la cantidad de personas en su equipo) y su SCM.

Todo es relativo:

Estoy usando Maven como ejemplo porque creo que es el sistema de construcción más completo y con "baterías incluidas", pero no significa que sea necesariamente el "mejor". Sin embargo, se ajusta a todas las casillas de verificación enumeradas anteriormente, y cuando busco un buen sistema de compilación, lo comparo con esta lista y Maven. Sin embargo, Maven no siempre es muy flexible, pero es muy extensible, si se desvía de su proceso estandarizado. Aumenta tu productividad en el caso general (una vez por delante de la curva de aprendizaje), no si luchas contra ella.

Aquí están mis 4 razones principales para usar herramientas de compilación:

• manejo de dependencias (evitar errores)
• prueba (su cambio no rompió otros módulos, mucho más fácil de probar)
• compromisos seguros
• más fácil de implementar localmente distribuible (nadie tiene tiempo en QA env para esperar a que el constructor construya su proyecto y sus dependencias)

En el libro Pragmatic Programmer , Andrew Hunt y David Thomas dicen que 'checkout-build-test-deploy' debería ser un solo comando (Capítulo: Proyectos pragmáticos). Tu escribiste..

Incluso tengo un inversor potencial en línea y planeo mostrarles una versión beta en las próximas semanas

Entonces, estoy seguro de que su equipo crecerá ... Es aún más importante contar con habilidades de implementación de prueba automáticas.

El XML grande (secuencia de comandos) que viste suele ser un trabajo de una sola vez. La mayoría de las veces, se pueden usar los mismos scripts en muchos proyectos.

No está claro qué tan grande es el proyecto. Si sus pruebas integradas / pruebas de aceptación requieren una gran CPU / memoria, puede considerar usar otra máquina como su servidor de prueba. También puede implementar una gran cantidad de herramientas para analizar el código fuente / código de bytes .

Yo diría que, para un desarrollador solitario, tener un buen proceso y estructura como compilaciones con script es mucho más importante que cuando estás en un equipo. La razón es que no tienes compañeros de equipo para llamarte cuando cortas las esquinas. Un servidor CI que ejecute su script de compilación lo convierte en un excelente compañero de equipo intransigente para mantenerlo honesto.

A medida que crezca su base de código, querrá agregar un conjunto de pruebas. Mi experiencia es que esto debe hacerse más temprano que tarde, y que su compilación nocturna (o lo que sea) debe ejecutar todas las pruebas cada vez. Comience con algo pequeño, el XML generado automáticamente probablemente esté bien. Cuando tienes miedo de cambiar algo por miedo a romper algo más, es un buen incentivo para escribir algunos casos de prueba.

Una compilación que no es IDE facilita la reconstrucción de versiones antiguas sin preocuparse por reconfigurar su IDE de la forma en que estaba en ese momento, le permite realizar la compilación de manera no interactiva para que pueda mantener una compilación nocturna para que las personas la prueben o descubran rápidamente si rompió las pruebas sin tener que acordarse de ejecutarlas y esperar a que se completen.

También le permite realizar compilaciones en entornos que no son de GUI, por ejemplo, enviar a un servidor, y le permite cambiar IDEs sin preocuparse por perder la capacidad de construir su software.

Algunas herramientas de compilación lo ayudan a automatizar el etiquetado y la implementación de versiones, vienen con valores predeterminados decentes para generar informes de cobertura de código, etc.

Cuando agrega más personas, una herramienta de compilación se asegurará de que no sea vulnerable a la mala configuración de IDE de otra persona. Regularmente comparto pantallas para arreglar las instalaciones de Eclipse de mis colegas porque no usan herramientas de compilación (trabajando en eso).

Sin embargo, la razón principal es que es algo que no necesita hacerse manualmente, así que no lo haga manualmente. Todo lo demás se cae de eso.