La semana pasada vimos algunas posibilidades de financiación adicionales para una startup adecuadas a distintos momentos del desarrollo de la misma, esta semana quiero introducir un tema que considero bastante importante y que es el de la organización que voy a dividir en 2 partes: la infraestructura y la metodología de trabajo. Podría parecer que en este tema una startup tiene poco que decir: es algo que empieza, no debería ser complicado de organizar. Sin embargo, como en muchos aspectos de la vida, tener previsto cierto orden no es malo y esas dos parcelas creo que son las mínimas sobre las que tenemos que actuar. La infraestructura es importante porque es lo que va a sustentar todo nuestro trabajo y es necesario pensar qué necesitamos y cómo podemos conseguirlo al menor coste. La metodología de trabajo va a influir en los resultados, el rendimiento que obtengamos y, muy importante, como nos llevamos entre nosotros. Hoy veremos el tema de la infraestructura, que es en lo que he estado trabajando en las ultimas semanas, y dejaremos el tema de la metodología de trabajo para la semana que viene.

¿Qué es esto de la infraestructura? La definición formal del diccionario nos dice esto:

infraestructura.
1. f. Parte de una construcción que está bajo el nivel del suelo.

2. f. Conjunto de elementos o servicios que se consideran necesarios para la creación y funcionamiento de una organización cualquiera.

En mi caso el conjunto de elementos o servicios que se consideraron necesarios al inicio fueron una habitación, un pc y una cafetera (y si me apuráis inicialmente casi me bastaba con la cafetera). Eso puede funcionar bien hasta que la idea se desarrolla un poco, se incorpora a más gente al equipo y queréis empezar a hacer algo de marketing para testar las ideas. En este punto las tareas a realizar se multiplican y si queréis mantener la salud, es mejor establecer unas pautas y automatizar todo lo que se pueda. Cada parte que queráis implantar va a necesitar un conjunto de servicios por lo que voy a describir estos ligados al proceso al que dan soporte:

Trabajo en equipo

Puesto que cada integrante del equipo tiene su propia vida, horarios y trabajos, lo subrealista en esta fase habría sido tratar de tener un sitio donde trabajar. Por tanto desde el principio decidí tomar un enfoque de trabajo colaborativo distribuido, intentando que todo lo que hagamos sea posible mediante teletrabajo y que no se necesiten más que los recursos de los que cada uno ya dispone.
  1. Gestión de versiones de código (SCM). Existen multitud de gestores de código y lo más seguro es que conozcáis alguno de ellos. Yo provengo del ámbito de subversión y al iniciar el proyecto encontré que tener un SCM que sólo puede gestionar el código si el servidor donde está instalado está activo podía suponer un problema. Mirando otras soluciones encontré el concepto de la gestión distribuida de código (DCVS) y dos de las herramientas que lo implementan git y mercurial. Si os preguntáis la diferencia entre una y otra, este artículo, os puede dar una idea. Al final me decidí por git y un servidor para compartir código con el resto del equipo en bitbucket que a diferencia de github, permite repositorios privados de forma gratuita.
  2. Gestión del ciclo de vida de la aplicación (ALM). Esta es una herramienta que permite coordinar el grupo introduciendo historias de usuario, tareas, bugs, wikis para el proyecto, documentación, etc. Una búsqueda en Google os dará cientos de productos de este tipo, pero yo he escogido Jira porque es un sistema muy extendido, probado, con posibilidades de configuración para distintas metodologías y sobre todo económico para startups.
  3. Sistema de mensajería. Para comunicarnos empleamos el correo, skype o gmail. En el último caso tiene la ventaja que gracias a los hangouts ni siquiera hace falta un local para mantener reuniones.
Desarrollo de productos

Al estar ligados a áreas distintas (creación musical, gráfica, web…) cada integrante del equipo tiene sus propias herramientas e incluso sistemas operativos distintos. En cualquier caso como infraestructura para dar soporte a este proceso resaltaría lo siguiente:

  1. IDEs de programación. Cualquiera que escojamos debería permitir instalar plugins para integrar el SCM y el ALM pues de esta manera se establece el pipeline completo del ciclo del software y es posible ligar de forma automática el trabajo que hemos hecho previamente en la parte de especificación/análisis con el trabajo de desarrollo. Un ejemplo de esto es el plugin Mylyn para Eclipse que posee multitud de conectores para diferentes SCMs.
  2. Servidor en donde almacenar «artefactos» (bibliotecas, datos, archivos…). Un tema que siempre me llevó de cabeza fue el de las bibliotecas de terceros que son necesarias para desarrollar. Descargarlas manualmente y tenerlas en un directorio está bien si eres el único en el proyecto. En cuanto hay varios desarrolladores coordinar las bibliotecas, las versiones y que todo funcione puede ser pesado y dado a errores. Nexus es nuestro chico para esto. Es un repositorio en donde almacenamos los distintos productos de la compilación.
  3. Gestor de construcciones. Muy ligado a lo anterior, yo empleo maven. Maven es la evolución de un makefile, pero con la ventaja que ya tiene un ciclo de construcción definido dependiendo del tipo de software que estás construyendo. Permite de forma integrada, entre otras muchas cosas, gestionar dependencias entre proyectos (descargando automáticamente las bibliotecas que hagan falta), automatizar la ejecución de los test y subir los artefactos construidos a nexus.
  4. Plataforma de pruebas. Un servidor en el que ir subiendo las cosas que creamos para probarlas en la nube. Si quieres tener datos reales sobre como funciona tu aplicación, yo recomiendo crear un entorno idéntico al que posteriormente ejecutará el software.
  5. Integración de código. La situación es la siguiente: imaginaos que cada vez que tenéis que desarrollar algo, lo hacéis todo en local, y posteriormente tenéis que subirlo e integrarlo para que no haya fallos. Lo que pasará con un 99% de probabilidad es que el único que escuchará vuestros rezos será Murphy, y si habéis sido cuidadosos, todo petara y os pasaréis el día preguntándoos dónde y por qué (no necesariamente en ese orden). Pues esto es posible minimizarlo si combináis 2 metodologías de programación y una herramienta. Las metodologías son el Test Driven Development (TDD) con la integración continua (esta última creada por Martin Fowler) y la herramienta en este caso es Jenkins. TDD promueve la creación de pruebas software ejecutables y repetibles, desde el mismo momento en que se conoce qué hay que hacer y antes de programarlo mientras que la integración continua promueve que si un fallo tiene que aparecer, mejor que aparezca cuanto antes. Jenkins permite automatizar la integración del código cada vez que subimos algo al repositorio SCM, jenkins se lo descarga, lo compila, ejecuta los test y sólo si estos no fallan, lo pone en el servidor de pruebas.
Pero claro todas estas cosas requieren de máquina para ejecutarlas como un servicio. Aquí podéis hacer 2 cosas (y yo he hecho las dos):
  • Utilizar tu pc como servidor. Esta fue mi primera opción y es la que más libertad os deja si sois buenos administradores de sistemas. Tendréis que abrir puertos en vuestro router para cada servicio,  crear un nombre virtual para vuestro pc en algún servicio de redireccionamiento (como dyndns) y si vuestra IP es dinámica, configurar en el router un envío de la nueva IP hacia el servidor de redireccionamiento. En mi caso esto funcionaba a veces, pero cuando algo cambiaba (por ejemplo las condiciones de servicio de dyndns) había que mirar donde estaba estaba el fallo y volver a configurar. Por eso me decidí por los proveedores de servicios externos.
  • Utilizar un proveedor de servicios externo. En muchas situaciones la mayor parte de esta infraestructura descrita anteriormente la podéis encontrar como productos que otras compañías venden. La parte buena es que en muchas ocasiones tienes planes de uso gratuitos con los que puedes funcionar. Lo malo de utilizar proveedores de este tipo es que los servicios que ofrecen pueden no adaptarse completamente a tus necesidades. Yo de este tipo utilizo Bitbucket aunque también consideré Assembla, JavaForge y Github en un principio.

Esto sólo me resolvía el problema del SCM para compartir el código entre los integrantes del equipo pues entre los proveedores de servicios no encontré quien ofreciera un servidor de integración continua, ni un repositorio nexus para los artefactos con la suficiente capacidad de configuración y privacidad. Por tanto la opción que quedaba era instalar estos servicios en los proveedores de cloud.
Cuando fui destilando la idea inicial sobre servicios de ejecución y desarrollo de juegos en la nube empecé a mirar qué era esto del cloud computing y qué tipos de proveedores existían. 
Para hacer esta historia corta diré que lo que yo buscaba era un proveedor que ofreciera: a) un plan gratuito con recursos de máquina suficientes, b) que no tuvieras que desarrollar bajo ninguna API propietaria del proveedor, c) que ofreciera servicio para websockets, d) que permitiera ofrecer servicio mediante un servidor Jetty un tanto especial y e) a ser posible que su plataforma de cloud fuera abierta o replicable. Con esas características el proveedor necesariamente cumple con los requisitos que me iban a permitir instalar tanto los servicios que me faltaban como posteriormente, si hay recursos suficientes para iniciar un cloud propio, replicar la misma plataforma sobre la que se están ejecutando actualmente los servicios. Quizás a alguno de los que estáis leyendo esto os ha entrado la risa floja al leer todo eso de ahí arriba y os habéis preguntado «si hombre, ¿quién va a haber que haga todo eso y deje replicar su plataforma?». Pues señores, tenemos un ganador, varios de hecho pues Cloud Foundry también cumple los requisitos, pero el que he probado ha sido este: OpenShift

En resumen, solo por registrarte, gratuitamente tienes 3 máquinas virtuales con 512Mb de RAM y 100 de swap, y un disco duro de 1Gb, permite establecer alias en sus DNS, escalar de forma automática el servicio y puedes configurar las maquinas virtuales para ejecutar distintas aplicaciones o servidores (mysql, JBoss, node.js…) y entre estas configuraciones existe una DIY (Do It Yourself) que permite instalar cualquier tipo de servidor, incluso uno que hayas hecho tú, por lo que :). El único problema de las DIY es que para configurarla, tienes que aprender por el camino difícil (ensayo, error, pregunta en los foros y en el chat) que ha podido ocurrir, pues hay documentación pero no es excesivamente buena. Mis últimas semanas han estado repletas de ese ciclo, inevitable de aprendizaje y sufrimiento, pero como suele decirse «sarna con gusto…».

Bueno hasta aquí la entrada de esta semana, la semana que viene continuaré con la metodología y como aprovechamos con ella esta infraestructura.