Como parte de la infraestructura de desarrollo del proyecto de HBit, nos hemos apoyado de algunos servicios en la nube para facilitar la labor de desarrollo sin tener que preocuparnos por la instalación, configuración, administración y mantenimiento de dichos servicios, lo cual representa una gran ventaja de por si.
Solo por mencionarlos, actualmente se ocupan los siguientes servicios que ofrecen ciertos beneficios.
- BitBucket. Repositorio de código privado y control de cambios y versiones, donde almacenamos y compartimos el código fuente de las aplicaciones.
- Codeship. Servicio de integración y despliegue continuo el cual se ocupa para la integración, ejecución de pruebas y despliegue del API REST consumido por las aplicaciones móviles. Básicamente utilizado para tomar el código del repositorio, ejecutar las pruebas unitarias y publicar los cambios en Heroku.
- Heroku. Ofrece un ambiente completo Ruby on Rails, para el despliegue del API REST con el plus de poder accederlo mediante una URL pública y HTTPs (requerido para el consumo de recursos en iOS 9).
Este esquema nos permite agilizar en gran medida el proceso de publicación de cambios en el API de modo que no tenga gran impacto en las actividades de desarrollo móvil, sin mencionar que con nuestra demanda actual podemos utilizar estos servicios sin costo.
Además de los beneficios mencionados que nos han llevado al uso de estos servicios, esta semana tuve una reflexión surgida a raíz de un pequeño incidente con el servicio de bitbucket, pues durante dos días algunas características ofrecidas por el servicio, que para nuestro caso rompía con el proceso automático de la publicación de cambios en Heroku.
En un principio se pensaba que era un problema de codeship, aunque revisando la página de estado del servicio (http://codeshipstatus.com), mencionaba sin mucho detalle que se trataba de un problema de los hooks de Bitbucket que disparan el proceso en codeship.
A pesar de la deshabilitación de nuestro proceso automático de despliegue y la intermitencia del sitio web de bitbucket, el servicio núcleo de Bitbucket (control de versiones mediante git y mercurial) seguía siendo totalmente funcional por lo cual podíamos seguir compartiendo cambios de código. Además, utilizando las herramientas de línea de comandos de Heroku era posible seguir desplegando cambios aunque se tuviera que hacer de forma manual.
Leyendo la respectiva página de estado del servicio (http://status.bitbucket.org) se podía conocer mayor detalle de lo que estaba ocurriendo con bitbucket. Dentro de los mensajes que me llamaron la atención podría mencionar:
Update - We have a technician on-site to begin the process of physically routing around the failed network hardware causing the availability problems experienced over the past 48 hours. We will have some more intermittent instability as this work is being done.Oct 22, 18:30 UTC
Al final de todo esto me quedaron las siguientes reflexiones.
¿Que tan valioso puede ser tener un equipo especializado y dedicado para cada tema?. De haber tenido un problema similar en un esquema local que nuestro mismo equipo les de soporte, nosotros mismos hubiéramos tenido que resolver el problema. Esto seguramente nos hubiera distraído y retrasado en nuestra labor de desarrollo para rehabilitar el servicio.
¿Que tan acertado es aceptar que se tiene un problema y hacerlo público? Quizá por cuestiones culturales, cuando hay un problema pareciera que se intenta ocultar a toda costa y negar su existencia para dar una apariencia pública de perfección. Esto creo que al final sale contraproducente para uno como consumidor pues el desconocer la problemática lo pone a uno en una situación de "dar palos de ciego". En cambio algo tan sencillo como el poder conocer rápidamente cual es el eslabón débil de la cadena, a través de una página pública, nos permitió reaccionar de manera más ágil y eficiente.
Pensando un poco a la ITIL (el cual ha sido un tema recurrente últimamente en Innbit), es interesante observar que al montar un proceso en una serie de servicios que ofrecen cierto nivel de servicio, nos permite continuar enfocados en nuestro trabajo a pesar de eventualidades.
Si nuestra aspiración es en algún momento poder ofrecer servicios de este estilo, creo que habrá que pensar en ir más allá de solo decir que vamos ha hacer un software o que lo vamos presumir con clientes. Quizá empezar a hacer una reflexión interna y cuestionarnos preguntas del tipo ¿como será la transición?, ¿como y quién lo va a operar?, ¿cómo podemos mejorar?... dicho probablemente en un cliche, "a la ITIL" o "mas o menos a la ITIL". Esto para que algún día alguien que ocupe algún servicio que lleguemos a ofrecer y que le ocurra algo similar a esta experiencia pueda decir que ofrecemos magia y otras cosas del diablo.
