Prácticamente desde que comencé mis Prácticas de Empresa del Grado en Códice Software no he usado ningún otro software de control de versiones que no sea Plastic SCM (salvo cuando usar Git ha sido obligatorio para compartir algo en GitHub, o con mis compañeros y profesores del Máster).

Enlace directo al blogpost en blog.plasticscm.com

Y, prácticamente desde que comencé a utilizar Plastic SCM como mi opción principal para controlar no solo código, sino todo tipo de ficheros que requiera versionado, tengo un servidor instalado en una Raspberry Pi, al que puedo acceder cómodamente desde cualquier lugar gracias a un servicio de Dynamic DNS y redirección de puertos en el NAT.

Sin embargo, por cómodo que fuese el acceso, debido al alto ritmo al que se publican nuevas versiones de Plastic SCM (muchas veces más de dos a la semana) mantener todas las instalaciones al día (portátil de trabajo, portátil y ordenador sobremesa personales, Raspberry Pi…) se había convertido en una tarea tediosa. Así pues, me propuse automatizar la instalación de Plastic SCM en la Raspberry Pi lo máximo posible, convirtiéndola de una simple commodity a un full-blown-central-server-de-la-leche.

Los objetivos eran los siguientes:

  1. Actualización del servidor de Plastic SCM a nuevas versiones en un plazo máximo de 24 horas desde su publicación.
  2. Backups comprimidos, automatizados, cifrados y en Cloud de los ficheros de backend en los que Plastic SCM almacena los repositorios.
  3. Que los puntos 1) y 2) no interrumpiesen mi trabajo ni requiriesen supervisión explícita (esto es: tener que entrar por SSH a la Raspberry y comprobar versiones, logs…)

Y el TL;DR de lo que hice para conseguirlo es:

  • Seis recetas de IFTTT, con un WebHook como trigger, para mandar notificaciones a mi teléfono móvil desde la Raspberry Pi con información sobre las acciones que esta iba ejecutando tanto en materia de actualizaciones como de copia de seguridad.
  • Un script que hiciese backup automático del backend a OneDrive, cifrado con GPG, asegurando la consistencia de los datos activando y desactivando el modo readonly en el servidor de Plastic SCM cuando fuese necesario.
  • Otro script que, comprobando las release notes de plasticscm.com, pudiese hacer scrapping de cuál es la última versión publicada para:
    • Descargar de Internet y descomprimir los binarios de la versión correcta.
    • Parar el servidor en ejecución de manera ordenada, para evitar la posible pérdida de datos (¡como si eso fuese posible! 😜)
    • Sustituir los binarios viejos por los nuevos.
    • Arrancar de nuevo el servidor en modo daemon.

Ahora que os he contado el qué, si tenéis la curiosidad suficiente, podéis consultar el cómo en el blogpost que escribí (en inglés) en el blog oficial de Plastic SCM.