Razones por las que prefiero Bitbucket sobre GitHub

Mentiría si digo que fui un early adopter de git. Cuando comencé a utilizar un sistema de manejo de control de revisiones de código (Dios que largo nombre!) o SCM fue por allá en el 2007 y no fue precisamente la mejor experiencia; ya que todo el stack con el que trabajabamos en ese momento era Microsoft era solo natural que utilizaramos Visual Source Safe, una de las peores herramientas de manejo de control de versiones por cierto.

Para cuando comencé a usar Source Safe ya tenía algunas nociones de lo que era dicho software cuando tuve que hacer alguna danza obscura para descargar el código fuente del driver de mi «winmodem«, compilarlo y hacerlo funcionar en Linux usualmente utilizando CVS.

Al poco tiempo de que mi jefe se dió cuenta que Source Safe nos daba más problemas que ayuda decidimos migrarnos a otro sistema y bueno, ese sistema era SVN que parecía era lo que la gran mayoría de proyectos OpenSource estaban usando en ese momento, reemplazo por cierto, de CVS.

No fue sino hasta hace unos 6 que comencé a utilizar git, esa herramienta indispensable de trabajo para cualquier programador hoy en día. Una de las grandes diferencias entre GIT y otros sistemas de control de versiones es obviamente su naturaleza «distribuida» que permite tener flujos de trabajo más ágiles como gitflow por ejemplo.

Curiosamente, Github es sinónimo de git, casi casi como decirle «corn flakes» al cereal. Llegaría a creer que hay personas que de hecho creen que git es un producto de github o una interfáz a su servicio. La verdad es que, probablemente, sin la ayuda de Github, git no tendría tantos usuarios como ahora. Una de las razones por las cuales Github acaparó rápidamente el mercado es que el producto se enfoca en funcionalidad que permite a muchos usuarios colaborar en proyectos, o como ellos le dicen «social code sharing». El concepto de pull requests, discusiones, etc. son términos prácticamente dados a conocer a la mayoría por Github.

Actualmente me encuentro trabajando en dos proyectos personales: uno que espero lanzar como un producto y otro una simple herramienta que pensé sería útil tener para resolver algunas necesidades y que pienso liberar públicamente una vez que tenga una versión estable. Tengo poca actividad como contribuyente a repositorios open-source así que la mayoría de mis proyectos o repos son privados. Como la mayoría de usuarios buscando una opción para hospedar gratuitamente repositorios privados terminé usando Bitbucket aunque con el tiempo de usar ambos productos tanto para proyectos privados como públicos mi preferencia se ha inclinado mas a bitbucket y aquí están las 5 principales razones:

Repositorios privados

Al igual que github, bitbucket ofrece cuentas gratuitas, sin embargo, en dichas cuentas no es posible tener repositorios privados mientras que en bitbucket si y como dije antes, este es uno de los ganchos más atractivos de bitbucket. Parecería que solo esta opción por si sola es la razón mas obvia sin embargo personalmente encuentro el flujo de toda la aplicación web de bitbucket más intuitiva para proyectos personales o donde no se tiene colaboración de miembros fuera de un equipo o empresa. Los últimos cambios hechos por Atlassian, dueños de Bitbucket me parecen geniales y mucho más limpia la interfáz que la de github.

Mejor bugtracker

Otra de las características que encuentro más intuitivas en bitbucket que en github es su bugtracker. Aunque está un poco limitado, lo cual es de esperarse, pues uno de los principales productos de Atlassian es su bugtracker JIRA, me parece que sigue siendo mejor que el de github. Para un proyecto personal o bien para equipos pequeños que utilicen metodologías ágiles me parece que el bugtracker de bitbucket es más que suficiente. Quizá sea que tengo un pensamiento más «lineal» y por eso me parece más natural el user experience de bitbucket pues encuentro el de github en esta área en particular muy enfocada a las discusiones y no tanto al tracking del issue en si.

Integración Continua

Una de las cosas más importantes en un proyecto de software en estos tiempos es contar con una herramienta de integración continua que no es otra cosa que probar que la integración entre la base de código y los branches de features no solo pasen las pruebas unitarias sino que además se comporten adecuadamente en un entorno que emule o sea lo más parecido al entorno de producción al cual hacemos deploy. Aunque github cuenta con decenas de integraciones de servicios de integración continua como Travis, Codeship, etc. bitbucket recientemente introdujo un nuevo feature a bitbucket llamado «pipelines«. Estos pipelines no son mas que archivos de configuración YAML en los cuales definimos una imagen de docker, algunas configuraciones y finalmente pasos a ejecutar dentro del contenedor. Obviamente todo el feature se encuentra integrado en la interfáz de bitbucket por lo cual no tenemos que instalar herramientas externas y lo mejor de todo es que incluso las cuentas gratuitas cuentan con hasta 50 minutos al mes de «build time» que aunque es poco, es suficiente para probar el feature o para proyectos pequeños como los personales.

Una opción en particular que me encantó de los pipelines de bitbucket es la posibilidad de guardar un cache con los paquetes que instalamos para ahorrar recursos no solo de ancho de banda sino además para que el build-time sea menor y por lo tanto nos ahorremos algo de dinero. Por ejemplo si usamos bundler en rails o composer en php, npm en nodejs etc. Podemos definir que folders deseamos guardar como cache, de manera que en el siguiente build se copie ese cache al contenedor y no tener que reinstalar todo.

Integración con Trello

Una de las mejores herramientas para desarrollo ágil creadas en los últimos años en mi opinión es trello. Es el único software de «administración de proyectos» que encuentro placentero utilizar. Quizá sea precisamente que trello no es particularmente un software para administrar proyectos sino más bien un board de kanban en esteroides pero precisamente ese approach ágil lo hace mi herramienta preferida. Comencé a utilizar trello creo que incluso antes que bitbucket y para mi sorpresa Atlassian adquirió a trello por lo cual era solo cuestión de tiempo para que mejoraran la integración entre ambos productos.

Aunque ya existía digamos plugins de trello para poder interactuar con repositorios de bitbucket estos no eran necesariamente los mejores. Hace apenas unos meses que Atlassian mejoró dicha integración y ahora podemos tener por ejemplo un repositorio ligado a un board lo cual nos permite darle seguimiento a algún card de trello ligandolo a un branch y/o pull request. Muy útil por ejemplo para utilizar trello como una especie de pivotal tracker donde cada card es un user story y cada branch y pull request corresponde a ese feature.

Precio

Finalmente creo que la última razón es el precio. Muchas personas preferirían utilizar github si de plano tienen que pagar, sin embargo, me parece que para lo que ofrece bitbucket por el precio la relación costo-beneficio es mejor. Por ejemplo, el plan actual con el que tengo mis proyectos es de $10 usd al mes que no solo me incluye los repos privados sino todas las integraciones que mencioné arriba, en particular la de los pipelines que de otro modo tendría que ser un servicio contratado a un tercero pues github no cuenta con eso. Si sumamos por ejemplo el plan mas pequeño de github + un servicio de continous delivery estamos hablando de alrededor de $100 usd al mes por la misma cantidad de usuarios y de minutos de build time, es decir, 10x el precio de bitbucket.

En resumen no solo me parece que bitbucket es más económico e intuitivo que github sino que en general me parece que tiene un mejor flujo para proyectos privados o de empresas pequeñas que buscan desarrollar un workflow personalizado que no solo incluya integraciones sino herramientas para ayudar con todo el proceso del software development life-cycle. Me gustaría desarrollar más este tema y como trabajo en un «one-person startup» integrando todas estas herramientas pero eso lo dejo para otra ocasión.