Revisión automatizada de código con KBDoctor y Jenkins

Dentro de las funcionalidades nuevas de KBDoctor esta la de poder hacer revisión de código automatizado, y poder ejecutar dicha tarea como una tarea MSBUILD.

Nosotros lo usamos para poder revisar los cambios subidos al GXServer, en la KB que arma los build, para revisar los objetos subidos.

Todas las noches se pueden revisar todos los objetos  que tenga un timestamp (modificados o subidos) del dia anterior o el actual.

set KBPath=C:\Models\GX16\KBPrueba
MSBuild.exe KBDoctorCmd.msbuild   /t:ReviewObjects 

Si se quiere revisar desde una fecha determinada, se puede agregar el parametro

/p:DateFrom=01-01-2018 

En el proyecto KBDoctorCmd.msbuild (que se instala con KBdoctor) se tiene
  <Target  Name="ReviewObjects">
    <Message Text="Using GeneXus DIR = $(GX_PROGRAM_DIR)" /> 
    <Message Text="KB DIR = $(KBPath)" /> 
    <OpenKnowledgeBase Directory="$(KBPath)" />
    <ReviewObjectsCmd  DateFrom="$(DateFrom)" />
    <CloseKnowledgeBase />
  </Target>

Con esta revisión, se podrán detectar objeto que tenga variables no basadas en atributos o dominios, código comentado, atributos que no están en ninguna tabla, control estricto de pasaje de parámetros, asignaciones de atributos o variables que puedan ocasionar perdida de datos y un conjunto grande de otros controles.
Si quieren ver esto en funcionamiento, no se pierdan la charla de Nicolás en el GX28, sobre KBDoctor + Jenkins "Herramientas de Revisión de Código con Integración Continua (KBDoctor + Jenkins)"


PD:  Otras tareas que pueden ejecutarse como tareas MSBUILD

  • CleanKB
  • ObjectsWOInOut
  • CompareWSDL
  • RemoveAttributesWithoutTable
  • RemoveObjectsNotReferenced
  • SaveObjectsWSDL
  • UpdateSourceWSDL
  • CleanAllObjectsVariables
  • SaveAndCompareWSDL




Comentarios

  1. Que bueno esto Enrique! En un tiempo a nadie se le va ocurrir estar en un proyecto de desarrollo genexus sin análisis estático de código automatizado y sin dudas que ustedes es un tema que vienen trabajando hace rato. Ojala mucha gente se entusiasme con esto! Éxitos!

    ResponderBorrar
    Respuestas
    1. Matias, comparto contigo que una vez que se hace, es dificil volver a lo anterior.

      Hay dos buenas practicas que se potencian.

      La integración continua, automatizando en build de la KB, es una de las mejores inversiones que se pueden hacer para mejorar la productividad del grupo.

      El analisis de codigo (automatizado o no) tiene la ventaja que deja el codigo mejor preparado para los cambios futuros.

      La integración continua + análisis automático de código, potencia ambas ventajas, logrando mejor código, a un costo mas bajo, con aumento de productividad al achicar la deuda técnica.

      Aun faltan herramientas para hacer esto un poco mas fácil, del lado de GXServer, pero supongo que van a llegar con las próximas versiones.


      Borrar
  2. Buenas tardes. ¿Se puede utilizar Jenkins si no poseo GxServer? ¿Siendo un sólo developer? Me gustaría tener automatizado el proceso de build + deploy en el servidor de aplicaciones Tomcat.
    Si se pudiera.. ¿cómo sería el proceso?

    Gracias, muy interesante
    saludos

    ResponderBorrar
  3. Si, se puede.
    Jenkins es un orquestador de procesos.
    Podrías poner uno que haga un import, build all y el deploy en tomcat.

    ResponderBorrar

Publicar un comentario

1) Lee el post
2) Poné tu opinión sobre el mismo.
Todos los comentarios serán leidos y la mayoría son publicados.

Entradas más populares de este blog

Aplicación monolítica o distribuida?

La nefasta influencia del golero de Cacho Bochinche en el fútbol uruguayo

Funcionalidades de GeneXus que vale la pena conocer: DATE Constants.