Hace un par de semanas como ejercicio de programación decidí desarrollar un proyecto simple para probar algunas piezas de integración continua y despliegue de código (CI/CD) a Heroku así como poner en práctica algunas otras ideas y resolver dudas con Docker. El resultado fue chiqui.to, un acortador de URLs estilo tinyURL o bit.ly y lo mejor de todo es que pude completar la fase inicial del proyecto en un fin de semana.
El stack
No me compliqué mucho. Parte de estas vacaciones «largas» que me estoy tomando (estoy libre, o desempleado pues, por decisión propia, desde finales de Noviembre del año pasado) fue para tomar algunos cursos, en especial Vanilla JS, sin embargo, he utilizado casi exclusivamente Ruby por los últimos 6 años y en eso me enfoqué; Ruby On Rails, PostgreSQL, Sidekiq/Redis y amigos. La aplicación es bastante simple así que no hay necesidad de utilizar ningún framework de frontend aunque hice trampa utilizando lo único que sé y domino: jQuery.
Integración continua y despliegue
Varias veces he comentado sobre lo mucho que me gusta bitbucket. Si bien para proyectos OpenSource o donde existen muchos colaboradores externos Github me parece mas que adecuado, para flujos de trabajo donde lo hacemos solos o en equipos internos me parece que el (ahora) producto de Atlassian ofrece una interfaz más intuitiva.
Una característica en particular de Bitbucket que me encanta son los llamados «Pipelines» que no son otra cosa que flujos que podemos definir en un archivo .yml usando la sintáxis de Docker lo cual nos permite construir un entorno de integración/pruebas fácilmente sin tener que utilizar un producto externo como Codeship/CircleCI/Jenkins etc. Incluso recientemente Atlassian integró un nuevo feature o funcionalidad a los pipelines para manejar nuestros deployments o despliegues a diferentes entornos como desarrollo, staging o producción. Mi proyecto es público así que se pueden ver las bitácoras de los builds aquí y de los despliegues acá.
El proceso de desarrollo (SDLC)
Me encanta Trello. He utilizado bastantes productos diferentes para administración de proyectos, rastreo de incidencias, backlogs, etc. todos con diferentes conceptos y al final del día siempre encuentro Trello como el producto más simple y a la vez configurable de todos; utilizando un simple «board» podemos definir nuestro propio flujo de trabajo al estilo de un pizarrón pero podemos personalizar y automatizar muchas cosas con el uso de addons o plugins, desde integración a nuestro source control, documentos de google hasta acciones desencadenadas por eventos al estilo zappier utilizando Buttler, el addon de automatización de la propia compañía.
Lo mejor de todo es que al ser este ya también un producto de Atlassian la integración con Bitbucket es sensacional y podemos por ejemplo ligar un branch o pull request a una de las tarjetas de manera que llevemos tracking de los avances de esta, incluso nos muestra una simple representación visual de ello. Trello combinado con algunos plugins y conectado a nuestro source control puede ser la herramienta perfecta para administrar proyectos pequeños y medianos ya sea para proyectos personales o en equipos donde necesitemos colaboradores. El board del proyecto también se encuentra disponible de manera pública aquí.
Infraestructura
Como comenté al principio decidí usar Heroku y la razón es bastante simple: la relación entre precio / beneficio es bastante para mi, sobre todo en proyectos pequeños y medianos pues nos evitamos tener que invertir tiempo no solo montar toda la infraestructura en Amazon Web Services (o Microsoft Azure, para los diferentes) sino en el mantenimiento de la misma que no es cosa fácil. Por otra parte, Heroku ofrece una serie de addons o plugins listos para integrarse que ofrecen funcionalidad ya sea de la misma compañia o de terceros, como monitoreo, motores de bases de datos, rastreo de errores, etc. muy al estilo Trello, así que solo es natural que sea mi primera opción, sobre todo para aplicaciones en Ruby.
Finalidad del proyecto
Más que reinventar la rueda (ya usaba bastante bit.ly, por cierto) mi intención era comprobar que podía entregar un proyecto de software con infraestructura, documentación y un proceso de desarrollo ordenado en una cantidad de tiempo limitada. Por otra parte, y no menos importante, «calentar motores» para retomar uno de mis proyectos personales, un producto SaaS, que dejé «tirado» hace años y que estoy ya retomando desde hace un par de semanas cuando terminaron mis vacaciones auto-impuestas.
Me encantaría hacer un video para platicar sobre estos temas y como podemos organizar proyectos de software que se acoplen sobre todo a metodologías ágiles. Si alguien me está leyendo y me quiere invitar a algún podcast soy materia dispuesta!
Por lo pronto, aquí un acortador de URL’s más que pueden utilizar:
Podrías liberar una API, para el proyecto
Hola Javier, el código está disponible en bitbucket por si gustas ajustarlo a tus necesidades. Saludos.