Casiva Agustin

Engineering, Development and IT Management

Hi there! 馃憢

I’m Agustin Casiva, I’m a Software Engineer from Argentina.

I have been working on IT for many years now, I worked in many fields of the industry, such as hardware support, networking, sysadmin but what I do love most is development.

I have worked for many organizations, public and private, local and remote, filling many roles.

My expertise is on Web Development, Linux, Open Source, CMSs, HTML, CSS, PHP, JavaScript, Backend Development, Product Development, Project Management, Team Leading, among others.

In 2013 I have founded 42mate, a Web Development Agency focused on the design, development, maintenance of Web Apps. I still work on 42mate where I work leading development teams and scoping new projects.

Besides 42mate I also work as an independent consultant where I provide services such as

  • Development Training, for individuals or teams.
  • Architecture Design and Review.
  • Tech Advisor for non tech startup founders.
  • Tech Advisor for Digital Design Agencies.

If you are interested on my services let’s talk!

More about me

Gitlab, Web Hooks y Jenkins

Desde hace un largo tiempo venimos usando en 42mate Gitlab como nuestra herramienta de control de versiones y Jenkins como servidor de integraci贸n continua. La selecci贸n de las mismas fue principalmente por que son Open Source y por que est谩n mas que aceptadas por la comunidad, nunca nos arrepentimos de la elecci贸n que tomamos.

Hoy me puse a ver alternativas para disparar un deploy en jenkins desde Gitlab despu茅s de cada commit y me encontr茅 con que Gitlab implementa web hooks.

La idea es que Gitlab, despu茅s de cada push al repositorio, env铆e una petici贸n POST a un server remoto, en este caso Jenkins, con la informaci贸n del push que dispar贸 el evento, el servidor remoto recibe dicha informaci贸n y toma alguna acci贸n al respecto, en este caso dispara un deploy.

Para que jenkins sea capaz de manejar la request enviada por Gitlab debemos tener instalados el Plugin de Git y el Plugin para Gitlab Hooks, el segundo es el encargado de hacer la magia y manejar la request.

Manos a la Obra

Para poner en marcha esto necesitamos obviamente un server Gitlab con nuestro repositorio y un Job un Jenkis ya totalmente armado para deployear desde el repositorio en Gitlab. Tambien vamos a tener que instalar y configurar el plugin para los hooks聽“Gitlab Hook Plugin”

Cabe aclarar que el Job en Jenkins debe estar conectado directamente al repositorio en gitlab dado que la informaci贸n de conexi贸n es utilizada por el plugin de jenkins para gitlab. Para esto deber谩n tener instalado el plugin de Git, as铆 tienen disponibles las opciones para conectar el Job con Gitlab. Del lado de gitlab van a necesitar un usuario Jenkins configurado para que el usuario con el que se corren los Jobs en Jenkins pueda clonar y pullear cambios del repo.

Para instalar los plugins en jenkins deben ir a Manage Jenkins, Plugins, Buscar el plugin en Available, seleccionarlos, instalar y reiniciar jenkins.

install

Despu茅s de instalarlos

installed

Una vez reiniciado jenkins deber铆an listarse en installed.

Screen Shot 2013-09-08 at 8.48.08 PM

Una vez que tengan el Job listo y los plugins instalados el siguiente paso ser谩 ir a Gitlab, entrar a su repositorio > settings > web hooks.

webhook1

Aqu铆 deber谩n ingresar la url de su jenkins para que se ejecute el plugin de web hooks, por ejemplo :

http://[dominio]/gitlab/build_now

Poner en dominio la direcci贸n a su Jenkins.

Una vez que esta guardado pueden proceder a testear el web hook con el boton que se provee en dicha pantalla o probar pushear algo al repositorio y ver como en pocos segundos se dispar谩 el proceso de build en Jenkins.

Cerrando

Como ven es muy muy sencillo, mucho mas que enganchar un hook post commit en SVN, y muy eficiente, mucho mas eficiente que verificar si hay cambios cada x segundos.

Tengan en cuenta que esto va a buildear siempre siempre despu茅s de cada push al branch que usen para que sea deployeado, consideren los riesgos que pude traer esto.

Para entornos de integraci贸n del trabajo de los developers usenlo sin miedos.

Para entornos de QA, recomendar铆a que usen un branch aparte en el cual se pushen los cambios listos para ser promovidos a QA, previa verificaci贸n del equipo.

Para producci贸n no lo recomiendo por mas que tengan una mega bater铆a de tests, usen un branch separado para producci贸n o cualquier otra cosa que les haga pensar que lo pueden hacer, si lo hacen felicito por los cojones bien grande que deben tener :).

Leave a Reply

Your email address will not be published. Required fields are marked *

*