Los beneficios de la cultura DevOps en la creación de productos digitales ya no se discuten. Si no te interesan, tendrás tus motivos y lo respetamos. Si por contra estás interesado en asegurarte esos beneficios, la Integración Continua (CI) es una práctica omnipresente.

Competitividad a velocidad digital

Como proclamaba Manuel Recena, la integración continua es una práctica de Ingeniería del Software difícil, pero que nos ofrece una gran recompensa.

La integración continua es esencial para la creación y lanzamiento de productos digitales en mercados competitivos, que nos exigen adaptarnos con celeridad.

Esa es la gran recompensa “para negocio”, pero además las personas involucradas se benefician del impulso en la colaboración, la automatización y los ciclos cortos de evaluación. Todos ganan.

Alternativas para no fallar

La riqueza de alternativas para implementar la integración continua es un universo en permanente expansión. Encontrar el sabor adecuado es uno de sus muchos retos. A las opciones en casa (“on premise”) tenemos que sumar las opciones en nube, que son extremadamente atractivas: Azure DevOps, Google Cloud, AWS DevOps y así un sinfín más. En muchos de nuestros artículos podéis brujulear al respecto… Pero antes de emocionarnos con estas deslumbrantes opciones, os proponemos recuperar las bases, los fundamentos para alimentar nuestra convicción.

Los señores fundamentos de la integración continua

En este sentido, recuperamos algunos de los mantras de la notable charla organizada allá por el año 2014, por el grupo madrileño de DevOps sobre Integración continua. Ingredientes: gran ponente (Manuel Recena), buen marco y asistencia, e intenso tercer tiempo.  Manuel y Antonio Manuel Muñiz (su socio de la época) se conjuraron para “no hablar de su libro” y cumplieron. Muchas de las perlas que nos regalaron, cultivadas tras años de experiencias, clientes y reflexiones, están aún vigentes hoy en día. Sinceridad en vena.

1. Fundamentos desde un punto de vista puramente técnico…

¿Qué alternativas tecnológicas tenemos? El número de opciones sigue creciendo notablemente. Los fabricantes están sacando suites e incluso se debe elegir, como decíamos antes, entre «on premise» (en local) o en la nube. Y la elección no es trivial.

¿Cómo se integran con las herramientas que tenemos? Hay que tenerlo presente puesto que condiciona las opciones reales. También hay que considerar el soporte para múltiples stacks tecnológicos, puesto que la integración continua es un sistema de propósito general, y soporte para distintas herramientas de construcción.

Si no se tiene ya en uso una herramienta de construcción, es decir, un proceso ya modelado, hay que solventar antes este aspecto.

¿Y qué pasa si aumenta el número de usuarios y proyectos? Si la solución elegida está vinculada al número de usuarios/proyectos, se nos puede disparar el coste. ¿Y cómo será el mantenimiento? Es muy peligroso escalar una iniciativa experimental, pues nos podremos encontrar con el efecto «el que lo montó se fue».

También hay que considerar que hay vida más allá de Java, Ruby o Javascript, por ejemplo, quienes programan micro-controladores. En estos escenarios es cuando destaca el disponer de capacidad para aportar integración continua a stacks tecnológicos «exóticos». Asegurar el ritmo en estos casos rinde el doble.

2. Aparece en escena el factor humano…

• Desde personas con falta de perspectiva:
  • «Eso lo montamos en una semana».
  • «Integración Continua es montar un Jenkins y listo».
  • «Eso es culpa del Jenkins, en mi equipo funciona».
• Hasta graves problemas evolutivos:
  • Equipos donde no hay cabida a ideas frescas y existe reticencia al cambio.
  • Mejora continua es un término que solo usan cuando hablan con el tutor de su hijo.
  • «Interesante, pero ahora no tenemos tiempo». Nunca hay tiempo.
  • «Si funciona, no lo toques»… llevado al extremo.
  • «Trabajamos para un cliente y el NDA impide …».
  • En cada proyecto resuelven sus necesidades.
• Pasando por ideas mal concebidas:
  • Automatizar no es hacer integración continua.
  • La integración continua es un medio, no un fin.
  • Las herramientas ayudan, pero lo importante son los procesos.

En fin, como somos seres humanos, ventilemos la información. Cuidar los radiadores de información compensa porque:

• Para dar valor, hay que medir.
• Evitamos tener información dispersa y desorganizada.
• Utilizamos sistemas de notificación explícitos: correo, mensajería, chat, twitter, iRC, …

La integración continua busca controlar la relación Causa -> Efecto -> Radiar. Segmento los pasos y los automatizo con el objetivo de poder controlar el efecto. Así, ante cambios en el efecto («algo ha fallado») puedo centrarme en buscar las causas dentro de ese segmento.

3. El proceso de decisión que nos espera…

Primer cruce en el camino
¿Nos lo montamos o utilizamos producto?
Una máxima. Si no es tu negocio, no te metas. Si haciéndolo tú, no eres capaz de justificar un ROI positivo, no lo hagas. El coste existe. No está en la instalación y configuración, sino en el mantenimiento e integraciones. Considera también el control de acceso, único a ser posible.

Segundo cruce en el camino
¿En casa o como servicio?
¿Tienes infraestructura y gente con experiencia administrando (sysadmin) este tipo de herramientas?
¿Te sigue dando miedo el cloud?
¿Tienes restricciones contractuales impuestas?

Sobre las herramientas de construcción
Son una pieza clave. Requisito básico.
Es el lenguaje que entenderá nuestro servidor de Integración Continua.
Existe una relación muy importante entre la herramienta de construcción (Maven) y el servidor de IC (Jenkins). Hay para todos los gustos, lo importante es que puedas llegar a los mismos objetivos.

Por último, cabe mencionar un conjunto de Buenas Prácticas, que son fruto del esfuerzo, la atención al detalle y la madurez en Integración Continua.

4. Organización.

Es aconsejable respetar una estructura para que se navegue fácil entre proyectos, y además, aporta madurez. Las líneas de automatización propuestas son:

1. Compilación, empaquetado y distribución.
   • Actividades hasta que genero mi artefacto.
   • Distribución es la tarea que coge el artefacto y lo sube a la biblioteca (digamos Nexus).
2. Generación de documentación.
   • Os explicamos en este artículo la magia de la documentación continua en dos píldoras.
3. Testing.
   • Se abre un abanico muy grande, desde pruebas unitarias a pruebas de rendimiento.
4. Inspección de código.
   • Ciberseguridad … «call me DevSecOps!»
5. Deployment
   • Desplegar o pasar el resultado a algún entorno (pre, test), no solo producción.

5. Tareas.

Y ahora unos consejos muy sabios para asegurar la productividad:

1. Crea tareas por cada «causa» que se quiera controlar.
2. Define convenciones en el nombrado.
3. Define una política de ejecución. Esta política condiciona el coste que va a suponer el uso del ecosistema. Por ejemplo:
   • Inspección de código por la noche.
   • Empaquetar con cada commit.
4. Utiliza listas de correo para las notificaciones.
   • Luego los miembros del equipo se suscriben a las listas de correo que les interesan.
5. Aplica definición temprana.
   • Define las tareas mínimas que se quiere tener en todos los proyectos y así, cuando el proyecto crezca, ya tienes la base de tareas montada.

Y como cierre, os rescatamos estas 4 perlitas:

• Hay muchos aspectos que influyen en la implantación corporativa de esta práctica.
• Hay que completar las herramientas de integración continua con herramientas de notificación.
• ¿Tenemos todo el peso del proceso de construcción en el herramienta de desarrollo (IDE)? Hay gente que está atrapada por el IDE, como los de iOS o los de microcontroladores. Les cuesta saber cómo construir su software sin IDE.
• ¿Cómo convencer a un dinosaurio? Es muy difícil. Tal vez haciéndole reflexionar sobre los esfuerzos o problemas que le supone el pasar las cosas a producción.

En definitiva, la Integración Continua (CI) es una práctica DevSecOps para controlar la relación Causa -> Efecto -> Radiar información al construir productos software. Segmentar y automatizar para poder controlar el efecto, detectar los cambios rápido y reaccionar rápido. Y así, se acelera el Time to Market. En Panel sabemos que aplicar Integración Continua es un proceso exigente que requiere una cultura de construcción de software particular, así que si tienes interés en conocer nuestra interpretación y puesta en práctica de las cuestiones aquí planteadas, anímate a descubrir una nueva perspectiva en la creación de software.

---

Enlaces relacionados:

• Presentación de la sesión Madrid DevOps en 2014 de Manuel Recena y Antonio Manuel Muñiz que tenéis aquí disponible.
• El vídeo de esta sesión compartido por la gente de Madrid DevOps: https://youtu.be/1sRAUMx4erA