Hasta ahora estaba llevando el desarrollo de agroguía con subversion y haciendo builds a pelo desde el editor. Los binarios se los pasaba a mi tutor (ahora probador) por correo electrónico sin ningún tipo de control, ni changelog, ni nada.
Subversion es vital, pero llevar "la cuenta" de lo que haces, de lo que te queda por hacer y de lo que has hecho es algo más que fundamental. Para ello, siguiendo la política que seguimos en Unkasoft, he instalado trac y scons.
trac la voy a user como sistema de control de bugs y de caravterísticas a implementar. Por suerte hace tiempo que no salen bugs, pero me interesa mucho tener control sobre nuevas cosas a implementar, porque últimamente es un jaleo saber qué está probado y qué no. De esta forma sé en qué rama de subversion está cierta característica. Esta es otra, he empezado a usar ramas en subversion para poder siempre tener una rama estable que poder vender. De momento es un infierno hasta que subversión saque su versión 1.5 en la que lleva tracking de ramas.
scons lo voy a user para generar las diferentes releases. De esta forma, junto con trac podré saber qué va dentro de cada versión y podré llevar un conteo lógico de versiones para poder diferenciarlas. En el trabajo estoy usando ant una herramienta, me atrevo a decir con todas las de la ley, que es una bazofia. La única razón por la cual se usa es que tiene unas tareas muy buenas para compilar java y derivados, pero como lenguaje para algo más, es malo a rabiar, no puedes hacer un bucle for de forma lógica, tienes que programarte mil tareas para hacer algo potente, etc... y es que XML no vale para todo.
Aparte el formato wiki de trac me viene de perlas para incluir ficheros de test, pruebas de cada uno de los GPS que usamos, gráficas y un montón de cosas.
Me falta tiempo, arg!
3 comentarios:
Podemos probar SCons si realmente es tan potente y soporta bien Java, pero también tiene que estar soportado por las herramientas de integración continua que vamos a montar :). Ant se hizo para hacer los script de compilación y empquetado. Ha crecido con muchas tareas a su alrededor, pero nunca se penso como lenjugae de programación, sino como una descripción básica de tareas. Para lo que se diseño, sigue funcionando el que mejor, para otras cosas diferentes, no es lo suyo. Poco a poco vamos probando cosas y cogiendo lo que más nos gusta como Trac.
Hombre puedes usar el target [script] y usar javascript, python o ruby para hacer tareas más avanzadas.
Scons es extensible?. Es decir, ant te permite extenderlo y construirle los targets que quieras sin depender del SO ni de la shell (podrías hacerte un for sin problemas). Por ejemplo me hice un target para ant que me hacia operaciones en un par de tablas de DB2. Para ello programé el módulo java y luego con taskdef lo metí en ant.
¿Con scons lo haría tan fácilmente? y lo que es más importnate ¿lo haría sin depender del SO o de la shell que hospeda el script? (admito que para que funcione lo anterior debo llevarme el xml y los jar de dependencias para construir en cualquier máquina)
Considero tambien de importancia el hecho de que con ant no tengo que aprenderme ningún lenguaje de script en cuestión. Al usar XML, cualquiera puede editarlo y comprenderlo sin probelmas.
De todas formas el mensaje anterior lleva completamente la razón. Anto no fue pensado como lenguaje.
El target [script] quizá te resulte interesante
Saludosssssssss.
@alex: es que scons es un módulo más de python, al contrario que ant que es un lenguaje hecho a medida (sobre xml, eso sí) con lo cual puedes extenderlo tanto como permita python, o sea mucho.
Aparte XML es muy muy peligroso. Se cree que usando XML la cosas mejoran una barbaridad. Para un caso como ant, hacer un if se comviernte el lo siguiente:
- importar la tarea adecuada con taskdef
- poner el if
- buscate la vida para poner la condición... si no tienes la condición te toca currartela
Aparte, con ant, cómo haces debug? como modificas una variable de forma simple? eso por no hablar de las típicas carpetas ${mi_variable} que te crea cuando la has mangado con el script. Ah!! y no se me olvide comentar el infierno que es cuando compartes un .xml con otros scrtips de ant.
Ant está muy bien para compilar cosas de java, trabajar j2me, pero vale, no sirve como script, sirve como mucho como front-end del compilador de java.
Publicar un comentario