Hoy tuve que despedir a un DevOps.

¿Porqué TRATAN de pasarse de listos?

Básicamente me pusieron como pretexto que estaba pasando un problema con Linux y servidores que configuré hace unos cuatro meses y en los que yo entro perfectamente desde hace varios meses. LO verifiqué y era mentira. Todo por justificar un problema de deployment de un gem ruby.

Lo malo es que perdí unas siete horas reales para demostrarlo. Necesitaba una pc con Linux no emulado para tener acceso a un entorno de Eclispse , y hacer algo con wireshark.

Por casualidad y otras razones, me traje el viernes de la oficina del cliente a mi casa la computadora Brix. Uno de los pasos previos fue instalar en un USB de 4 gb un Live CD de la versión 17.2 Cinnamon de 64 bits de Linux Mint, que tiene muy buen soporte de hardware raro y que se supone que si jala la Brix. Solo que, como necesitaba hardware no emulado, era necesario borrar todo e instalarle desde el USB. Varios problemas.

Tuve que configurar la Pc para que arrancara el disco SATA en modo IDE. Instalar como tres veces. Luego bajar wireshark. Firefox. Etc.

Luego ir a la oficina donde se supone estaban justificando los tiempos extras de domingo, porque capistrano, una herramienta práctica para deployment no estaba funcionando o estaba mal automatizado.

LLego junto con el socio de esa empresa, a la zona de Polanco.

A ver, muestrame que problema tienes con Docker y con Capistrano.

Es que …

Se supone que llevas con eso una semana. Conozco lo suficiente para saber que no estas usando control de versiones y que lo que me describes es Vagrant y no capistrano.

(Explicacion larga del DEVOPS que se resume a las direcciones ip no checan, el .gem esta mal y se esta mandando lo mismo y no la actual).

Me doy cuenta que a pesar que la gem está preparada para distribuirse con Capistrano y en su caso pasarse a un contenedor Docker (a los que detesto por varias razones, entre ellas que tiene derecho de root interno y externo asi como los problemas de conflictos de ip si n o es la misma en el docker que en el desarrollo), el esta usando rubygems.org o algo que se le parece.

Es que no se puede con capistrano !!!, dice.

Le pregunto enfrente de las otras dos personas, al socio que esta terco en agarrar cosas de Ruby en lugar de .net o .php …. que hacemos ?

– Que sugieres ?

– Les parece bien que si puedo hacer yo deployment de la versión de hace ocho dias por Capistrano, revisemos que esta pasando ?

– Si , pero necesitarías una computadora.

Saco de la bolsa del super una caja pequeña, le digo al programnador no docker que quite el teclado y raton de la pc del problema, mientras yo desconecto un monitor.

Conecto la Brix., Selecciono correo, slecciono lugar. Abro el SSH. Cambio una linea para que sea

require ‘bundler/capistrano’

Problema demostrado. Instalo el gem de hace ocho dias, y claro que se soluciona el problema.

Voy entonces a la maquina a la que le quitamos el teclado y veo que ni suqiera estan haciendo el deployment en el docker correcto. Así que aunque cedí en el uso de docker (cosa que fue un error ya que aunque es una forma rápida y mas o menos directa de hacer deployment en Ruby tiene detalles que complican su uso ), todo el probelma fue porque alguien actualizaba en base a su vagrant y no al deploymento que yo mandaba por Capistrano.

Resultado: Doce mil pesos tirados a la basura. Lo bueno es que no lo contraté yo, que el tipo no tenía siquiera un mes, y verificar que Capistrano, al ser herramienta de ruby, es mas estable que la via de Docker / Vagrant.

La razón de correrlo NO fue desobedecer ordenes, se supone que el era mas experto que yo en Ruby. Lo tuvimos que correr porque el menso no se dió cuenta que estaba haciendo deployment de algo de su computadora y no lo que yo le mandé. Así que no se dio cuenta de la versión y tampoco estaba usando el GIT. Nos hizo perder dos semanas, y las pruebas las hacía en su docker, no en el del cliente, que pudo haber sido en un principio un sitio web. Supongo que tendremos que hablar de nuevo con el gerente de sistemas del cliente para verificar que quiere docker y no sitio web. Probablemente no está consciente de la necesidad de root, o lo marearon con las ventajas de docker.

Pero a final de cuentas es mejor para todos hacer deployment a traves de una maquina virtual , un sitio web y el camino antiguo de Ruby on Rails, que meterse con docker.

Cuando descubro que esta haciendo deployment por Vagrant y no por capistrano, me pregunto porqué alguien que no programa en Ruby (mi socio) contrata a programadores Ruby sin pasarlos primero para visto bueno.

Y perdí muchas horas. Alcancé a activar en el proyecto del martes la interfaz para proveedores y programar una de las dos, pero no terminé la segunda.

Son las once de la noche, mañana que regrese de mi viaje, tengo además que llevar los cachorros al veterinario.

Dejaré bajando Rosa, la versión 17.3 de Mint y hora de acostarse. El miércoles tendré que dejar esta lnux para trabajar, pero por lo menos geany y bluefish ya funcionan.