Integración continua en Roi Scroll: la experiencia de 2017

Entre bambalinas, el equipo de Roi Scroll ha estado todo el año trabajando en un nuevo sistema para conseguir hacer nuestros servicios de desarrollo y mantenimiento más rápidos, más seguros… y lo hemos conseguido.

En septiembre empezamos a aplicar la Integración Contínua (o CI) en nuestros servidores.

Integración Continua… ¿y esto qué es? Bueno, explicar la integración continua puede ser un poco arduo. A grosso modo, es forma de trabajo que se basa en combinar el trabajo de todo el equipo (el código que escriben) y someterlo a una serie de pruebas y condiciones que tiene que pasar para poder integrarse.

Vamos a hacerlo fácil. Por ejemplo, gracias a la integración contínua, los sitios web de nuestros clientes se podrán beneficiar de:

Mejoras de seguridad

• En el caso de WordPress, actualizaciones diarias automáticas tanto del core, como de los idiomas, plugins, themes y base de datos.
• Estas actualizaciones diarias, automáticamente se suben a nuestro control de versiones en la rama develop (la última barrera de seguridad antes de publicar los cambios en los sitios web) y se publican en el servidor de desarrollo, de forma que éste se encuentre siempre actualizado al 100%
• Pruebas automáticas para comprobar que la actualización no ha generado daños en el sitio web. ¿Que los ha generado? No pasa nada, el sistema automáticamente vuelve al estado anterior.

Detección temprana de problemas o conflictos

• Pruebas automáticas de código (test unitarios)
• Si nada falla, nuestro equipo lanza una petición de integración con la versión de código que se está utilizando en real (la web pública) y automáticamente se lleva a cabo la publicación del código; mediante un proceso de sincronización que mantiene limpio a los sitios web de ficheros ya no utilizados o innecesarios.
• Ups!! se ha publicado y por un motivo extraño algo ha fallado, no pasa nada, el sistema vuelve automáticamente a la versión previa (que iba OK) y nos avisa para que veamos que ocurre.
• ¿y si la publicación no falla, pero hay algo que quedó mal?… Vale, con la Integración Contínua y nuestro sistema de validación en el servidor de desarrollo antes de publicar es difícil que pase… ¿y si los duendes nos hacen la jugarreta? No es problema, tenemos un botón (literalmente hablando) que al clicar en él vuelve a la versión anterior… o a cualquiera de las anteriores 😀

Menos espacio en disco y otras bondades

• Menos espacio en disco para los sitios web. Con la Integración Contínua podemos hacer todo lo que requería que tuviésemos los sitios públicos «conectados» con nuestro control de versiones… así que… ya no se necesita: conexión off (ya lo hacemos por otro lado) y ahorro de espacio en disco para todos.
• Múltiples detalles más muy cercanos a la parte técnica que tienen un beneficio directo en la calidad del servicio y resultado (como la separación real de contenidos multimedia y de configuración del código del proyecto web)… esas cosas que hacen «los raritos» de desarrollo y que es mejor para todos que no nos arranquemos a explicarlos porque nos emocionamos… y ya sabéis lo que pasa entonces 😉

Arrancamos en Septiembre con un pequeño grupo de sitios web para ir controlando el funcionamiento y evolución del sistema. Aunque nuestra planificación marca fin de año como el momento en el que todos los sitios estarán bajo esta práctica… no os perdáis detalle de nuestras comunicaciones, porque en cualquier momento podrá llegarte el aviso de que ya estás bajo la mano férrea de la Integración Contínua. Eso sí, los sitios web tienen que cumplir unas pocas condiciones para poder funcionar bajo esta forma de trabajo:

1. Tiene que estar alojado en nuestros servidores.
2. Tiene que disfrutar del mantenimiento de Roi Scroll.

¿Mantenimiento web? Un motivo más que se une a la lista ya comentada de por qué el mantenimiento web importa

Voy a permitirme el lujazo de entrar un poco en las «entrañas técnicas»… que en marketing digital también podemos montar infraestructuras chulas de desarrollo, aunque pasen más desapercibidas 😉

Ahora tocaría que explicara con algo más de detalle lo que es la integración contínua, pero los cracks de Amazon lo explican de una forma clara y sencilla Integración Continua explicada por Amazon así que… eso sí, no te olvides de volver aquí o te perderás el final de esta historia!!!

Detectando la necesidad de CI

Desde el 2016 teníamos claro internamente que necesitábamos incorporar la integración contínua a nuestra metodología de trabajo. En 2015 instauramos el control de versiones como requisito obligatorio en todo proyecto web, algo que nos hizo la vida más tranquila… aunque todavía quedaban muchos flecos sueltos… muchas acciones manuales:

• Probar el código
• Pasar el código del repositorio al entorno de pruebas (deploy a develop)
• Comprobar en el entorno de pruebas que todo esté OK
• Pasar el código al entorno real o de producción (deploy a production)

Y, prácticamente, por cada acción manual existía un proceso paralelo, también manual y más arduo de «volver para atrás» si pasaba algo malo.

Ya en 2016 empezamos a tener problemillas para poder tener un sitio web actualizado al mismo tiempo que estaba inmerso en cambios y mejoras paralelas… Por eso separamos todo desarrollo en dos ramas (caminos) diferentes: desarrollo y producción: Todo se hace sobre desarrollo y cuando está OK se traslada a producción y, posteriormente… se publica.

En fin, no hace falta estar metido en el proceso para darse cuenta de que se abren muchas posibilidades de incompatibilidades, errores, problemas, etc.

Primeros pasos para encontrar la Integración Contínua perfecta para nosotros

Estaba claro, teníamos que buscar la manera de garantizar que el repositorio estuviese siempre en un estado consistente y los problemas, de haberlos, trasladarlos al momento en el que el equipo está trabajando y no tenerlos cuando el equipo terminó el trabajo. La integración contínua encajaba como un guante en la necesidad. Pues nada, a buscar qué software utilizar para gestionarla.

Aquí empezó nuestra aventura… comenzamos a documentarnos a fondo sobre la integración contínua, todo apuntaba a la convivencia de cuatro tipos de software diferentes:

• Software de control de versiones: El lugar dónde todos almacenamos el código del proyecto y vamos incorporando las modificaciones… digamos que la versión programación de lo que sería una wikipedia.
• Software para la realización de test: Para garantizar que el código que escribes está bien y que, además, no tiene daños colaterales que hace que rompa otra cosa totalmente diferente (algo tipiquísimo). Aquí nos queríamos centrar en test unitarios y funcionales.
• Software de deployment: Para trasladar el código del repositorio a los servidores de desarrollo, producción, etc.
• Software Todo un mundo… de hecho la integración contínua realmente no incluiría la parte de trasladar los cambios a los servidores. Ahí ya estaríamos hablando de continuous deployment y continuous delivery, que extienden a la integración contínua, por lo que realmente lo que empezamos a hacer es trabajar en entrega continua… pero bueno, a veces los límites son muy difusos y nos quedamos con la palabreja de CI.

Ya con las ideas claras tocaba buscar opciones y profundizar más. ¿Qué probamos?

• Para los test barajamos behat, phpUnit y CasperJS entre otros
• Para despliegue… aquí nos volvimos locos. Ansible era una opción interesante… pero también Capistrano e incluso Deployer. Las charlas en PHP Vigo sobre Ansible y Deployer no ayudaban a tomar decisiones… todo mola!
• Para control de versiones poco había que buscar… usamos git bajo gitlab… cambiar ahora no era una opción.
• Para la integración continua, los reyes Jenkins y Travis claro está.

Tomando la decisión

Tomar la decisión fue muy complicado. Existen tantas opciones… todas son geniales, tanto que es muy fácil perder el foco entre tanta documentación y prueba. Tras varios meses de estar el tema encima de la mesa, teníamos sólo un par de cosas claras: phpUnit y Gitlab. Capistrano parecía que tenía muchas papeletas… pero un día de locura decidimos romper la baraja.

Gitlab tenía desde hace un tiempecito ya su sistema propio de CI que llaman Gitlab CI/CD y que permite tanto integración como entrega continua. No le habíamos prestado mucha atención, hasta que decidimos darle una oportunidad. La razón, simple: Si nos vale, ya está integrado con Gitlab y, por lo tanto, con nuestro control de versiones, con nuestra gestión de proyectos y con nuestra plataforma de SCRUM.

Tras darle la oportunidad quedó clarísimo que teníamos que haberlo hecho antes. Fácil, sencillo e intuitivo; totalmente integrado con nuestras herramientas habituale y rápido. Así que…

• Software de test: phpUnit y CasperJS (bajo PhantomJS)… aunque este último aún lo estamos puliendo.
• Control de versiones: Gitlab (o sea, git + interfaz de gestión de proyectos)
• Software para despliegue: Gitlab CI/CD
• Integración continua: Gitlab CI/CD

Y manos a la obra que nos pusimos!!! Vale, aún queda trabajo por hacer, pulir los test, mejorarlos… dotar de más inteligencia a los procesos de despliegue… Eso es bueno, significa que seguiremos mejorando el servicio que damos a nuestros clientes y que continuaremos con nuestro principal objetivo: La excelencia. Y como objetivo secundario… dormiremos más tranquilos con Gitlab CI/CD orquestando.

Es un hecho: Continuous Delivery for victory and glory.