Implementación de Java con Ant: ayuda con el control de versiones, testings, etc. para una mejor construcción

Durante los últimos meses, he desarrollado un proyecto Java, una herramienta de análisis experimental de command-line. Como no tengo un CS-major en segundo plano (Matemáticas / Ingeniería en su lugar) he tenido el placer de luchar y aprender conceptos como gestión de proyectos y POM, control de versiones (SVN) y scripts de compilation (ANT). La razón por la que estoy describiendo esto es para retratar el hecho de que la mayoría de estos conceptos no me resultan naturales, a diferencia de los algorithms y fórmulas (supongo que se podría decir que aprendí a ser un " codificador " y no un " progtwigdor "). si tal distinción es válida / aceptada).

Dicho esto, he logrado hacer que las cosas funcionen en su mayor parte, aunque a veces son bastante incompletas / feas. Como me gustaría aprender y mejorar a lo largo del path, pensé en preguntar aquí en SO. El file ANT que utilizo hoy, creado con algo de ayuda a lo largo del time, se adjunta a continuación.

Dada la situación, me gustaría …

Pregunta 1: … agregue control de versiones hasta cierto punto, de modo que cuando suministre el software como un file jar a los usuarios de todo el mundo, tanto ellos como yo podremos encontrar una forma de rastrear posibles problemas y el desarrollo. El número de versión adjunto al nombre del file JAR (por ejemplo: prog-0.1.5.jar ), junto con algún tipo de salida para el usuario en time de ejecución sería ideal. Me dijeron que esto era posible a través de ANT pero hasta ahora no he tenido suerte. ¿Algún consejo o sugerencia?

También he recibido el siguiente fragment de código para este propósito, pero no estoy seguro de por qué / cómo funcionaría en mi proyecto, ya que no he declarado estos attributes / properties …

 <svn> <status path="." lastChangedRevisionProperty="someproject.build" /> </svn> 

EDITAR: solo para aclarar mi gran cantidad de preguntas, me gustaría estandarizar la versión de control en mi proyecto. Puede que esté usando el término de una manera incorrecta, pero la forma en que se realiza el control de versiones ahora mismo es:

  • Realizo confirmaciones regulares a un server SVN para realizar un seguimiento de los cambios (y también para tener copys de security)
  • Trato de forma manual de realizar un seguimiento de las diferentes versiones de software

Para dar un ejemplo de lo que quiero lograr en relación con el control de versiones:

  1. Me gustaría evitar la numeración manual de la versión; eso es tan propenso a errores …
  2. Me gustaría hacer un seguimiento de las diferentes comstackciones, al less localmente, utilizando sus numbers de versión, por lo que en todo momento tengo compilation más antigua si es necesario que investigue una versión anterior. (Ahora hago ant dist-clean; ant dist para nuevas comstackciones que sobrescriben las antiguas JAR)
  3. Sería preferible si el número de versión se pudiera incorporar a la construcción, por lo que una línea informativa (por ejemplo, "Ahora está ejecutando My_Awesome_software v: 0.1.3") cuando se ejecutan los JAR
  4. Para lograr lo anterior con SVN como seguimiento de versión, y ANT como herramienta de compilation. No estoy seguro si tengo la libertad de cambiar el seguimiento de la versión en nuestro server, y Maven no es una opción en este momento. Parece ser más un problema aprender a mitad de path que cualquier beneficio que pueda tener …

Pregunta 2: … examine las testings unitarias. He leído mucho sobre testings unitarias como el santo grial de la progtwigción moderna, y tengo algunos recuerdos lejanos de JUnit de la universidad hace unos años. Entiendo que en un entorno de desarrollo de software ideal, las testings unitarias son absolutamente críticas, sin embargo, no tengo idea de cómo las testings unitarias deberían / ​​podrían implementarse en mi caso; donde el software tiene una interfaz de usuario mínima (un file de parameters y un par de indicadores opcionales en time de ejecución) y un time de ejecución LARGO (leído: horas) en relación con el análisis.

Dada la situación, todavía se considera una mala práctica no tener testings unitarias, si ese fuera el caso, ¿cómo debería proceder con el razonamiento cuando estructurara mis testings?

Siento que las testings unitarias suelen ser un par de veces más grandes, y ejecutar incluso más time que el software real si trato de probar la mayoría de las funciones en el software.


Conclusiones: He estado investigando este concepto de numeración de versiones usando ANT, resumiré brevemente mis hallazgos para otros que podrían encontrarse con la misma pregunta:

  1. Cree un file de properties como @Kevin Stembridge mencionado a continuación, p. Ej. Build.properties. El mío se ve así:

    micro.version = 5
    build.number = 5
    major.version = 0
    minor.version = 0

  2. Importe las properties de este file con: <property file="project-version.properties"/>

  3. Concat el esquema de numeración deseado para el nombre jar en la label jar. Vea el código a continuación.

  4. Las testings unitarias son necesarias, aunque sean complicadas para un proyecto como el mío. Lo investigaré a medida que el proyecto se desarrolle.

Gracias a todos los que han contribuido de alguna manera, estoy eligiendo la respuesta de Kevin como aceptada, ya que es la única que tuvo influencia directa en mi solución aquí.


 <target name="dist" depends="compile,static" description="Compiles and builds jar files"> <mkdir dir="${dist}"/> <buildnumber file="project-version.properties"/> <property name="version.number" value="${major.version}.${minor.version}.${micro.version}"/> <svn> <status path="." lastChangedRevisionProperty="rev.number" /> <info target="." /> </svn> <jar basedir="${build}" destfile="${dist}/fever-${version.number}-rev${rev.number}.jar" includes="**/*" /> </target> 

Para responder la pregunta 1:

Para agregar un número de versión a su jar y otros artefactos, debe crear un file de properties con un nombre como "projectversion.properties". En él agrega la siguiente línea:

 project.version=<my_version_number> 

En su file build.xml, agregue el siguiente fragment de código:

 <property file="project-version.properties" /> 

Luego puede anexar la versión a su file jar así:

 <jar destfile="${dist}/prog-cli-${project.version}.jar"> 

Para responder la pregunta 2:

Es una gran discusión y no entraré en muchos detalles. Ciertamente es posible (más fácil en realidad) crear un buen set de testings unitarias para el código que no tiene interfaz de usuario. Si sabe qué producto espera recibir para una input determinada, puede escribir una testing que lo confirme.

Para responder la pregunta 3:

Tu file de compilation se ve bien. No veo ningún problema con eso.

En cuanto a la sugerencia de usar Maven. Resolverá el problema de su versión por usted mediante el uso de convenciones, pero tenga en count que la curva de aprendizaje no es el único inconveniente. Al cambiar a Maven sacrificará flexibilidad, simplicidad y confiabilidad.

Me doy count de que estás centrado en Ant como una herramienta de construcción. Sin embargo, te animo a que consideres a Maven.

Algunos de los problemas que describes son por qué existe Maven. La idea de probar las unidades antes de crear un file JAR, la idea de crear numbers de versión, la idea de ramificar y labelr una versión dentro de su repository de código fuente (incluso SVN) se integran en Maven.

La desventaja es que es otra herramienta más para aprender, y la curva de aprendizaje puede ser pronunciada.

1

¡En el momento en que tenga más de una versión, necesita el control de la versión!

Si no lo tiene, terminará en "ah, la fuente de la versión 4.5.1.2 está en ESE file comprimido" y rápidamente se vuelve muy tedioso.

Cuando elija entre sistemas de control de versiones, elija uno que le permita:

  • Incruste una ID de construcción con su aplicación.
  • Use dicha ID de construcción para get fácilmente el código fuente exacto correspondiente a la ID de construcción.
  • Corrige los errores de dicho código fuente.

Esto está comúnmente disponible hoy. Conformarse con nada less Personalmente, me gustan git y github, pero otros como mercurial y bzr.

2

No olvides el motivo de las testings. ¡Necesitará que le digan cuándo se rompen las cosas, y tan pronto como sea posible! Con frecuencia, esto significa que agrega un escenario que se rompió anteriormente y se arregló, y luego ve si se rompe esta vez. A menudo lo hace en un server de compilation que realiza las testings rápidas cada vez que ingresa en su sistema de versiones, y las testings largas fuera de las horas de trabajo.

3

No sé si deberías cambiar cosas en tu file ant, pero te recomendaría utilizar un enfoque donde el file de construcción ant y la configuration IDE se puedan mantener sincronizados. Usé ant4eclipse para escribir un sistema de compilation usando configuraciones de Eclipse. Esto se puso bastante complicado y sugiero usar un IDE que explícitamente conoce sobre ant en su lugar. No creo que esto funcione bien en Eclipse.