Continuous Integration DNG Photo Magazine

Hace un tiempo que no escribimos sobre aspectos técnicos de la revista DNG Photo Magazine, con anterioridad hemos escrito diversos artículos al respecto y de vez en cuando seguiremos escribiendo sobre el tema, aunque quizás no sean los temas que más buscan los asiduos lectores de DNG, pero siempre puede ser del interés de algún lector más geek y también de paso compartimos los entresijos de nuestros sistemas.

Tenemos mucho por contaros con futuros cambios en los servidores, con la implantación de Docker, Kubernetes, RancherOS y Rancher, Ansible y muchos otros cambios que esperamos repercutan en la escalabilidad del sistema, estabilidad y mejoras en la administración, pero hoy voy a hablaros sobre Continuous Integration y Continuous Delivery.

El último desarrollo en el que estamos trabajando en DNG Photo Magazine y del que pronto oiréis hablar, supone el desarrollo del código en local, para lo cual utilizamos una máquina virtual de Virtual Box, lo que viene a ser algo así como tener un servidor o varios dentro de nuestro ordenador, para la implantación de dicho servidor utilizamos Vagrant Up, lo que nos permite con un sólo comando «encender, apagar, actualizar» nuestro servidor, entre otras utilidades en las que no entraremos para no ponernos excesivamente técnicos. Como el núcleo de nuestra web es WordPress, todo esto lo orquestamos con Varying Vagrant Vagrants, lo que a su vez nos permite crear una nueva copia de todo el sitio en un simple comando, levantar nuevos servidores, etc., además de ir comprobando los fallos, hacer Debug, probar nuevas configuraciones, realizar copias de la base de datos… en resumen, junto con plugins como Debug Bar, tenemos un entorno para desarrollo en local donde podemos realizar todo tipo de pruebas, cambios, actualizamos y lo que se nos ocurra sin interferir en el sitio web que estáis viendo.

Todos los cambios de código se van registrando mediante el control de versiones Git y guardando dichos cambios en GitLab que a su vez los sincroniza con BitBucket. Incialmente sólo guardábamos el código en BitBucket, pero debido a los frecuentes cambios empezamos a mirar un sistema de Continuous Integration (CI) y comenzamos a utilizar el de GitLab, pero seguimos manteniendo una réplica en BitBucket por diversos temas de comodidad de consulta de código. El sistema de GitLab funciona bien, pero ¿en qué consiste?, básicamente en que después de desarrollar una determina funcionalidad y probar en nuestro sistema en VVV local que todo funciona correctamente, enviamos el código al repositorio Git de Gitlab (git push) y este se encarga de enviar una copia al servidor externo de desarrollo, desde donde ya lo podemos ver en el servidor definitivo (aunque no es la versión pública), en este paso si comprobamos que todo está correcto, etiquetamos el código (tag deploy-x) y volvemos a enviarlo a GitLab, con lo que el sistema de CI envía el código al servidor definitivo y lo que ya podéis ver públicamente…

Pero esto era hasta hace poco, ya que después de la lectura del libro Ansible for DevOps de Jeff Geerling, hemos cambiado el flujo de trabajo a Ansible, lo que nos evita tener que ejecutar ningún software de CI en los servidores y ahora el proceso tan pronto tenemos los cambios realizados se limita a lanzar un comando en la consola de Ubuntu (desde Windows 10 ya que ahora la integra para desarrolladores) del tipo #ansible-playbook y el «libro de órdenes a ejecutar».

Esta nueva integración nos permite desarrollar en local y tener el código en producción en unos segundos con un simple comando y sin tener que abrir un programa sftp, enviar archivos, etc., etc., entre otras muchas ventajas como la realización de pruebas unitarias… pero no vamos a entrar hoy en detalles más técnicos, que ya bastante jerga técnica se ha volcado en esta entrada.

Seguiremos contando de vez en cuando los nuevos desarrollos, la instalación de todos los contenedores de servicios con un comando desde Ansible y otras maravillas que seguro resultarán muy aburridas para los menos geeks.