Madrid DevOps es un grupo de profesionales interesados en … DevOps, como se puede imaginar. Hay un ‘Meetup Group’ donde encontrar noticias, principalmente de nuevas reuniones cada mes.

El 10 de abril, la charla trataba de ‘Integración Continua’, con Manuel Recena Soto y Antonio Manuel Muñiz de ClinkerHQ. Les hice algunas preguntas acerca de su presentación, que se puede ver en https://speakerdeck.com/clinkerhq/integracion-continua.

Hola Antonio, hola Manuel, ¿os dejo presentaros?

Somos los principales desarrolladores de ClinkerHQ, un ecosistema de desarrollo de software basado en soluciones Open Source (Jenkins, SonarQube, Redmine, SVN, Git, Nexus), listo para usar como servicio o instalarlo sobre una plataforma de virtualización.

Muchos de los clientes de ClinkerHQ se apoyan en nosotros para implantar o mejorar sus prácticas de Integración Continua (IC) usando nuestro producto. Nuestro conocimiento sobre IC viene de la experiencia adquirida durante más de 7 años aplicando, y ayudando a aplicar, esta práctica en empresas.

¿Qué es Integración Continua en vuestra actividad cotidiana?

Se podría decir que es el corazón de todo nuestro ciclo de desarrollo, si deja de latir no podemos seguir trabajando.

A diario, en Klicap se realizan builds, se ejecutan tests, se genera documentación, se despliegan snapshots, etc. y todo de forma automática y desatendida. Trabajamos sobre un producto complejo, donde intervienen muchos componentes software separados. Si no hubiera un sistema de Integración Continua haciendo que todo esté disponible al instante, sería imposible avanzar, y el día a día se convertiría en un laberinto de componentes y dependencias.

La Integración Continua nos notifica casi en tiempo real cuando una de las piezas no encaja, y nos da la clave para encontrar la causa de la anomalía al instante.

Veo muchas personas que piensan que basta con usar Jenkins para ser DevOps, o que Integración Continua es DevOps. ¿Cuál es vuestra definición de DevOps?

Son conceptos distintos. Digamos que la IC aporta a DevOps lo mismo aporta al desarrollo de software, ni más ni menos.
Para nosotros DevOps es un perfil en el equipo, con un pie en el desarrollo y otro en la infraestructura, de forma que tiene el conocimiento necesario para romper esa barrera que históricamente ha habido siempre entre el ‘departamento de desarrollo’ y el de ‘sistemas’.

¿DevOps es Continuous Integration + Continuous Deployment o es más que eso?

Son conceptos distintos. La Integración Continua o el Despliegue Continuo son prácticas que se basan en la automatización de tareas para ganar en productividad. ¿Pueden aplicarse a DevOps? Por supuesto.

Veo a gente  a favor de gestionar un dashboard con datos de calidad de la infraestructura (disponibilidad, saturación, etc.) para los equipos de desarrollo. Estoy de acuerdo con unos SLAs sencillos pero no sé si hay valor más allá (excepto para investigar un incidente).

La monitorización de la infraestructura es fundamental, especialmente cuando se ofrece un producto como servicio. De hecho, uno de los componentes de ClinkerHQ ofrece una serie de gráficas de evolución temporal de consumo de recursos de la plataforma sobre la que corre el producto, esto permite al usuario tomar decisiones a la hora de escalar.

Hay una frase famosa de Tom DeMarco que se usa mucho en Calidad de Aplicación «You can not control what you cannot measure”. Manuel, dices algo parecido en la presentación: «Para dar valor, hay que medir.» ¿Puedes comentarnos?

Totalmente cierto. En este caso la frase hace referencia al desarrollo de software y a las herramientas de medición de la calidad que se pueden utilizar hoy en día, por ejemplo SonarQube. Es fundamental poder medir como de bien (o de mal) lo estamos haciendo, y donde están los puntos débiles para mejorar. Si a la medición sumamos la continuidad en la medición y la resolución de incidencias mediante inspección de código, entonces estamos ante la práctica conocida como Inspección Continua.

¿Qué es el futuro de DevOps? ¿En qué dirección pensáis o queréis que vaya?

¿El futuro de DevOps? Pues ni idea, pero parece que es un perfil que ha venido a quedarse, que siempre ha sido necesario. Quizás las herramientas de automatización y modelado de insfraestructura (pienso en Ansible, Chef, Puppet, etc.) han dado pie a la creación de esta corriente. Estas herramientas han puesto a disposición de «los de sistemas» las mismas posibilidades que los desarrolladores teníamos desde hace años.

Muchas gracias para tomar el tiempo de responder a mis preguntas.

Esta entrada está disponible también en Lire cet article en français y Read that post in english.