Una situación común que nos encontramos al desarrollar software para proyectos de diversa índole, es que nuestra máquina de desarrollo puede verse envuelta rápidamente en un cierto caos provocado por la coexistencia de varios lenguajes o plataformas, servidores de bases de datos locales, espacios de trabajo de nuestro IDE, proyectos de git y subversion, etc…
En otros casos, puede ocurrir que nos incorporemos a un proyecto ya existente y en el que existe un camino ya prefijado para configurar el entorno. Este camino nos puede venir marcado por distintos grados de formalidad dependiendo del estado y características del proyecto, pero puede perder precisión con el paso del tiempo, ya que vamos haciendo los cambios según van surgiendo las necesidades específicas de cada entorno a lo largo de semanas, meses o incluso años. Así, cuando hay una nueva incorporación o se retoma el proyecto después de un tiempo, configurar el entorno de una forma rápida y sencilla puede ser todo un reto.
Una opción interesante para solucionar los problemas planteados es el uso de máquinas virtuales, para de esta forma, aislar cada proyecto en un entorno independiente. El problema de esta solución es que el proceso de configuración y distribución sigue siendo una tarea manual, repetitiva y en definitiva, poco conveniente.
Una variante de la idea anterior y que hemos adoptado de forma interna es un flujo de trabajo basado en la virtualización (Virtualbox, Vagrant y git) que simplifica de gran manera la configuración de los entornos y nos permite resolver rápidamente los problemas expuestos anteriormente.
Ventajas
- Aislamiento, cada entorno incluye únicamente el software necesario y si hace falta establece versiones específicas. Con esto evitamos posibles conflictos entre proyectos.
- Automatización, sólo se especifica la configuración del entorno, no su contenido. Esto nos permite modificar y compartir el entorno de forma fácil y rápida gracias al control de versiones.
- Repetibilidad, la especificación completa del entorno nos permite experimentar sin miedo. Si hacemos algo mal, siempre se puede destruir y crear uno nuevo.
- Adios al «Funcionaba en mi máquina», podemos crear un entorno de desarrollo lo más parecido posible al de producción y evitar problemas derivados de diferencias entre plataformas (finales de línea en ficheros, etc…)
Con este primer artículo hemos querido introducir el problema al que nos enfrentamos los desarrolladores y las ventajas de la solución propuesta. En un próximo artículo hablaremos de como implementar la solución propuesta.