GeneXus Server: Wish list.

GeneXus Server, es la herramienta desarrollada por Artech, para el trabajo en grupo con GeneXus.
Hoy es como un respositorio centralizado de una KB, donde los desarrolladores del grupo de trabajo suben  los cambios que han programado (operación commit) y actualizan lo que los demás han cambiado (operación update).

Desde que migramos a la versión X, estamos usando dicha herramienta y es un cambio grande en la forma de trabajo que teníamos con versiones anteriores de GeneXus, pues mejora muchísimo el ciclo de consolidación de los cambios.

Luego de usarlo por un tiempo, hemos ido acumulando algunos cambios que paso a listar aquí:

1) Traer objetos desde otra KB que esta en GeneXus Server.
Seria muy practico, poder seleccionar algunos objetos desde la interfaz WEB y poder generar un archivo de export.
Por ejemplo, veo una KB en GXServer en su interfaz WEB. que tiene algo que me interesa (por ejemplo una trasacción y algunos dominios)  y quiero incorporarla a mi KB local.  Para lograr extraerlos, debo bajarme toda la KB a mi máquina, y desde esa segunda KB local, realizar el export de los objetos que me interesan y consolidarla a mi nueva KB.

Otra opción, podría ser que desde mi GeneXus local, me pudiera conectar a cualquier GXServer (por ejemplo, open.genexusserver.com y buscar en las KB que tenga permiso, los objetos que me interesan y poder incorporarlos a la KB en la cual estoy trabajando.

2) Tags a los Commits. 
Me gustaría poder contar con tags asociados a los commits, de forma de poder buscarlos mas facil.
También podríamos usar, dichos Tags para poner cosas como numero de incidente, version en la que se genero eso, URL de documentación, etc.

Pienso que podrían ser útiles etiquetas de 100 caracteres donde podamos poner cosas como

  • DocUrl=http://servidor/docmentacion/it9000.html
  • IT=567890
  • FechaInstalacion=2013-04-09

Las etiquetas se podrían asociar en el momento de realizar el commit, y también seria bueno poder hacerlo en forma posterior, por ejemplo, para marcar que dicho commit ya se paso a la versión de producción.

3) Marcar eventos. 
Es bueno poder guardar eventos en el server, algunos eventos que suceden en el cliente.
Por ejemplo:

  • El build all termina sin errores
  • Las pruebas automáticas terminan sin errores
  • Se da por aprobada la versión por el testeo manual. 
  • Se cierra la versión y se le da un número 
El poder marcar dichos eventos nos daría información importante para todo el grupo de trabajo. Por ejemplo, poder bajarse una KB y volver hasta el ultimo build completo o ver si falta algún evento critico. 

4) Generación de las Documentación de los cambios de la versión (Release Notes). 
Si tenemos el evento de la ultima vez que se realizó el cierre de una versión, todos los cambios desde ese evento hasta el actual, permite generar la lista de cambios y si tuviéramos la URL de una pagina donde se almacena la documentación de la 
Si ademas se tiene una lista de donde sacar dicha documentación, se puede automatizar bastante el armado de la documentación de los cambios. 

5) Poder bajar un versión sobre una KB ya existente. 
Varias veces he tenido que hacer un check out de la KB para empezar a trabajar sobre una nueva KB, porque la KB sobre la que trabajaba, se estropeo. Como borrar KB es muy trabajoso, me van quedando muchas KBs en el notebook de desarrollo. Seria bueno poder dejar la KB en el mismo directorio, de forma que todos los scripts de backup, msbuilds, pruebas, etc, sigan funcionando sin problemas.

Sería necesario que todo esto pueda hacerse a traves de APIs. 

Comentarios

Entradas más populares de este blog

El Sordo

StackOverflow Documentation

Codigo simple