[GUIA] Usando Jenkins con Delphi

[[AgustinOrtu]]

Veamos como integrar un SCM en Jenkins.

En este caso voy a utilizar Git como SCM; y GitLab como host del repositorio Git

Lo primero que debemos hacer es volver a la parte de Administrar Plugins en Jenkins:

http://localhost:8080/pluginManager/

E instalaremos

GIT Plugin
GitLab Plugin .

Luego reiniciamos Jenkins

Si queremos recibir notificaciones de GitLab cuando se pushea al repositorio, tendremos que tomar una medida adicional. Sino, podemos seguir con la estrategia de cada determinado lapso de tiempo, compilar; solo que en este caso, al estar el repositorio de por medio, Jenkins va a ejecutar un pull y bajar los ultimos cambios automaticamente.

Para recibir notificaciones de GitLab:

Necesitaremos nuestro ip externo, lo ideal es contar con un DNS.
Vamos a la configuracion del sistema Jenkins: http://localhost:8080/configure
Bajamos hasta "Jenkins Location". Veremos que hay un aviso en amarillo que nos indica que en lugar de localhost:8080 pongamos un nombre "correcto"

Aca introducimos nuestro ip externo o DNS, respetando la sintaxis (el puerto 8080)

Para verificar que todo esta bien, probamos ingresar a Jenkins usando nuestro ip o dns desde el navegador. Es necesario que el puerto este habilitado tanto en el router y firewall de Windows

Ahora lo que hacemos es volver al proyecto que creamos antes (o creamos uno nuevo, como quieran) y seleccionamso "Configurar" en el menu de la izuiqerda

Volvemos a la misma pagina donde configuramos el proyecto inicialmente. En este caso vamos a modificar en la seccion "Configurar el origen del código fuente"

Ahora que instalamos el GIT plugin, deberia aparecer la opcion "Git", la seleccionamos

Se nos solicitaran dos cosas: (la ayuda en este caso es realmente detallada, recomiendo revisarla)

- URL repositorio: es la misma que usamos para clonar
- Credenciales: de ser necesarios, obviamente

Antes estabamos compilando cada 15 minutos.. algo bastante inutil. Ahora vamos a configurar Jenkins para que reciba una notificacion cuando se pushea al repositorio; Jenkins la va a recibir, va a ejecutar un comando pull (va a bajar los ultimos cambios) y compilar

Vamos a la seccion de "Disparadores de ejecuciones"

Tildamos la opcion: Build when a change is pushed to GitLab. GitLab CI Service URL: http://<IP/DNS/localhost>:8080/project/XXX

Es importante la direccion que nos informa en "GitLab CI Service URL"; esta dependera de la configuracion de Jenkins. Queire decir que en esa direccion es en donde Jenkins estará escuchando las notificaciones de GitLab. Obviamente, que en localhost nunca va a poder recibir nada, de alli la importancia del paso anterior

Copiamos la direccion en cuestion al portapapeles

En este punto podemos guardar los cambios en Jenkins y nos vamos para GitLab.

Una ves en GitLab, buscamos el proyecto, y nos dirijimos a "Settings"

https://gitlab.com/<usuario o grupo>/<proyecto>/edit

Luego entramos en "Web Hooks"

https://gitlab.com/<usuario o grupo>/<proyecto>/hooks

Y ahora es cuestion de ingresar la direccion que teniamos en el portapapeles y marcar en que momento nos interesa que nos mande una notificacion.
Podemos probar facilmente que este todo bien, haciendo click en el boton "Test Hook" Al hacerlo, aparecera el mensaje "Hook successfully executed." arriba
Si volvemos a Jenkins deberiamos ver como se ejecuta nuestra tarea, Jenkins en ese momento va a comenzar a clonar el repositorio

Es interesante que cuando una tarea se ejecuta nos indica quien la disparo. Hasta ahora solo teniamos "annonymous", ya que eramos nosotros mismo dandole a Build desde el browser. En este caso por ejemplo yo obtuve:

"Started ​by ​GitLab ​push ​by ​Agustin ​Ortu"

Esto nos permite obtener un mayor control sobre quien y cuando hace las cosas

Jenkins utiliza los llamados "workspace" para almacenar todo lo que necesita para trabajar con nuestro proyecto. La carpeta principal que contiene todos los workspace esta en el directorio de instalacion de Jenkins\workspace; por ejemplo, al clonar el repositorio git, deberia habernos creado una carpeta

\workspace\<proyecto>\

Y ahi mismo deberia estar el contenido del repositorio.

El workspace esta disponible desde el browser, podemos ver el contenido haciendo click en la opcion "Espacio de trabajo" del menu lateral de la izquierda.

El workspace es un concepto bastante interesante ya que es el directorio activo al momento de ejecutarse la tarea; esto nos vale para una ultima modificacion: asi que volvemos a la parte de configuracion del proyecto

Anteriormente, habiamos configurado el RAD Studio Plugin para que compile en una determinada ruta cierto proyecto. Vamos a configurarlo ahora para que utilice siempre la copia del workspace, ya que es la que va a estar actualizando constantemente gracias a la integracion con GitLab.

Simplemente, hay que quitar la ruta y dejar solo el nombre del archivo, ya que como dije antes, el directorio activo es el workspace, y dentro del workspace deberia estar nuestro proyecto; mejor dicho, es la ruta relativa de nuestro proyecto Delphi dentro del repositorio Git, evidentemente si esta dentro de otra carpeta deberiamos incluirlo en la ruta. Pero por lo genral los .groupproj o los .dproj estan en la raiz

[Casimiro Notevi]

Gracias por compartirlo.
¿Qué tipo de licencia tiene?

[[AgustinOrtu]]

Empezado por Casimiro Notevi

Gracias por compartirlo.
¿Qué tipo de licencia tiene?

La licencia MIT

Jenkins is distributed under the MIT License.

https://wiki.jenkins-ci.org/display/...S/Meet+Jenkins

[Casimiro Notevi]

Estupendo

[[AgustinOrtu]]

Vaya, resulta que uno aprende hasta cuando enseña

Como comentaba, en mi pc de desarrollo voy con Windows 10, en este caso, los workspace de cada proyecto se almacenan en:

C:\Program Files (x86)\Jenkins\workspace\proyecto_1
C:\Program Files (x86)\Jenkins\workspace\proyecto_2
...

Luego esta este otro directorio:

C:\Program Files (x86)\Jenkins\jobs

Que tambien contiene una carpeta por proyecto, dentro de la cual esta la configuracion de la tarea Jenkins y toda la historia que se ve desde el browser.

Bueno, a medida que arme la guia fui instalando todo en el servidor de desarrollo, que corre en Windows Server 2003.

En este caso, hay algunas diferencias:

1. No existe el directorio "C:\Program Files (x86)\Jenkins\workspace"
2. Cada workspace esta dentro de la carpeta Jobs\Proyecto\workspace

Para tener en cuenta...

Saludos

[mamcx]

En las nuevas versiones viene incluido https://www.finalbuilder.com/finalbuilder. Esa fue la primera herramienta de automatizacion de builds que use, y es muy facil de manejar.

P.D: Para evitar los problemas que las rutas, en este tipo de herramienta se usan variables o llamadas a API para obtener lo necesario dinamicamente.

Ademas, es IDEAL si esto se ejecuta contra un control de codigo fuente como mercurial/git, como dice el tutorial. La idea general es:

1- Obtener una copia fresca de la rama de produccion del CVS
2- Hacer la compilacion/bundling de los archivos necesarios
3- Generar los archivos para las pruebas (ej: Generar una BD de forma automatica)
4- Ejecutar los tests
5- Correr el instalador (como Inno Setup)
6- Desplegar los archivos (ej: Subir instalador o subir sitio web)
6a- Si es un sitio web, hacer los test en produccion (o mejor, tener un servidor de stagging)
7- De ser el caso, notificar a los interesados

Si esto se hace bien, con un click se debe poder correr todo el proceso sin problemas (a menos que los test fallen )

[[AgustinOrtu]]

Otra posibilidad es ejecutar directamente comandos batch de Windows en lugar de usar el "RAD Studio Plugin". En algunos casos puede dar cierta flexibilidad, sobre todo si se maneja bien este aspecto

Jenkins permite ejecutar directamente archivos .bat; como siempre, lo mas indicado es que el susodicho este en nuestro workspace y asi es posible referenciarlo directamente.

En este ejemplo voy a crear dos archivos bat:

CLEAN.bat -- borra los .dcu, .exe, __history, y similares
BUILD.bat -- ejecuta CLEAN y luego compila

CLEAN.bat

@echo off
echo Cleaning...
del /f /q /s *.exe
del /f /q /s *.bak
del /f /q /s *.dcu
del /f /q /s *.ddp
del /f /q /s *.~*
del /f /q /s *.local
del /f /q /s *.identcache
del /f /q /s *.tvsconfig

del /f /q /s *.bpl
del /f /q /s *.cbk
del /f /q /s *.dcp
del /f /q /s *.dsk
del /f /q /s *.o
del /f /q /s *.rsm
del /f /q /s *.skincfg

for /f "tokens=* delims=" %%i in ('dir /s /b /a:d __history') do (
  rd /s /q "%%i"
)
if "%1"=="" goto :eof

En realidad este script es tomado prestado del framework Spring4D http://spring4d.org/. Dicho sea de paso aprovecho para decir que es genial y que pegen un vistazo, algun dia me armaré de valor y hare un post sobre esto

Y este es mi BUILD.bat:

call CLEAN.bat
echo Start Build...

call "C:\Program Files (x86)\Embarcadero\RAD Studio\7.0\bin\rsvars.bat"

msbuild /verbosity:detailed Proyecto.dproj

El truco esta en llamar al rsvars.bat correcto de acuerdo a nuestra instalacion de Delphi. Lo correcto seria usar alguna llamada API o variables de entorno para obtener la ruta tal y como menciona mamcx y no hacerlo de forma chapucera a como lo hice yo, pero lo dejo como ejercicio para el lector

La configuracion en Jenkins es simplemente, en la seccion de Ejecutar, seleccionar "Execute Windows batch command" y en los argumentos simplemente ingresamos la ruta a BUILD.bat

En mi caso como lo tengo en la raiz del workspace simplemente deje "BUILD.bat" y listo

Saludos