Convencer a un desarrollador solitario para que use una herramienta de compilación separada en lugar de la compilación IDE con un solo clic

22

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.

Gigatron
fuente
3
Si bien debe pensar en la posibilidad de usar scripts Ant / Maven / Gradle para manejar el proceso de compilación. Ciertamente puede esperar hasta una fase posterior de su ciclo de desarrollo. No compliques las cosas. Cuando esté en camino de lanzar algo que pueda venderse, y tenga un inversionista, y cuando vaya más allá, solo considérelo. Porque ciertamente NO será una tarea de "hazlo una vez y olvídalo". Tendrá que mantener actualizado el script para que coincida con sus procedimientos de compilación. Preocúpate por los scripts cuando tengas ayuda.
Ramhound
55
Las herramientas de construcción se vuelven beneficiosas en el momento en que tiene que lidiar con algo más que "la última versión que consiste en todo el código más reciente". Todavía no estás allí: en el momento en que lo hagas, domestica tu construcción.
8
Si lo que está haciendo ahora funciona y no le causa problemas, simplemente continúe. La "fijación prematura" probablemente causa más problemas que la "optimización prematura". Además, su IDE probablemente esté usando Ant debajo de las sábanas.
James Anderson
1
Pregunta muy válida
Madhur Ahuja

Respuestas:

11

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.

Aroth
fuente
1
Continuaré con la compilación IDE de un clic hasta que salga la primera versión beta. Entonces planeo usar Maven. Ant parece crear más trabajo del que ahorraría para mi situación, pero Maven parece ser lo suficientemente directo y poderoso como para valer la pena. Para mí no es solo una cuestión de si es beneficioso tener la herramienta de compilación; También considero el costo de aprenderlo, configurarlo y mantenerlo.
Gigatron
7

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.

Nate
fuente
77
No estoy de acuerdo 1000 veces. Si estructura sus scripts de compilación correctamente, entonces realmente solo tiene que pagar el costo de escribirlos una vez, y luego puede reutilizarlos casi al pie de la letra en cualquier número de proyectos. Hay mucho que decir a favor de tener un comando de construcción de una línea que construya, configure, implemente y ejecute el sistema automáticamente. Y una vez que tenga eso, ahorrará un montón de tiempo en comparación con la implementación manual / gestión de la configuración, que luego se puede gastar en las nuevas características que menciona.
Aroth
Estoy de acuerdo en que una tienda de un solo hombre debe centrarse. Sin embargo, no estoy de acuerdo con su premisa, ya que las herramientas de construcción ahorrarían tiempo a largo plazo, tanto para prepararse para nuevos proyectos y mantener los existentes, o incluso para producir productos a pedido para los clientes.
haylem
Una ventaja sutil de Maven es que funciona mejor con un diseño estándar de archivos en lugar de la forma ad-hoc que se ve con frecuencia en los proyectos Ant. Cuando las personas ven la ventaja de usar los valores predeterminados de Maven, los usan, y sus proyectos son más fáciles de entender para los futuros mantenedores.
1
@aroth Pero OP no pasa nada de tiempo haciendo "implementación manual / gestión de configuración", simplemente presiona un botón en su IDE. Por lo tanto, no ahorraría tiempo en absoluto.
Atsby
1
El IDE es un sistema de compilación. O de lo contrario no lo estaría usando.
Arne Evertsson
5

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".

Críptico
fuente
En efecto. Lo real que este desarrollador debe considerar es una buena solución de CI, y un script de compilación puede ayudarlo a lograrlo.
Bill Michell
4

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.

haylem
fuente
3

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)

fuente
1
Especialmente manejo de dependencias. Soy demasiado vago para descargar y agregar bibliotecas externas. Mucho más simple solo agregarlos como una dependencia. "¿Versión incorrecta? ¡Cambie la versión en la configuración y reconstruya!"
Sí, pero el manejo de dependencias no es realmente un requisito previo de todas las herramientas de compilación. Maven, Gradle, Ivy lo apoyan. Ant, Make, etc ... no lo hagas.
haylem
2

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 .

Jayan
fuente
1

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.

Wyatt Barnett
fuente
¡Exactamente lo que estaba pensando! Actualmente estoy trabajando en un lugar donde cada desarrollador trabaja solo en su propio proyecto. Todavía no podía venderles la idea de un sistema de compilación, pero lo estoy usando yo mismo porque creo que realmente ayuda.
elias
0

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.

tripleee
fuente
1
Ya hago pruebas unitarias sin la necesidad de una herramienta de compilación separada. El IDE puede ejecutar las pruebas o yo puedo ejecutarlas desde la línea de comandos.
0

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.

Ricky Clarkson
fuente