Si alguna vez ha requerido trabajar con servidores, habrá notado que el proceso de configurar una u otra instancia es bastante similar. A pesar de que el proceso sea repetitivo, toma mucho tiempo; además de estar sometido a los errores humanos.

Cuando empecé a trabajar directamente en algunos servidores para configurar mis proyectos en Django y WordPress noté que los pasos eran básicamente los mismos siempre, con lo que surgieron las preguntas:

  1. ¿Por qué si hay un proceso manual y repetitivo no lo puedo automatizar?
  2. ¿Por qué me tendría que interesar el automatizar los procesos?

¿Por qué si hay un proceso manual y repetitivo no lo puedo automatizar?

Hay casos en los que no automatizar puede ser una opción válida, aunque los únicos que se me ocurren son:

  1. No soy el encargado de los servidores o de la infraestructura en mi empresa y/o los lapsos de tiempo en los que tengo que realizar algún proceso de servidor son bastante largos.
  2. Los cambios se hacen directamente en el servidor, por lo que una vez configurado solo se trabaja allí.

A partir de estas preguntas, de mi experiencia y de una extensa investigación, llegué a las siguientes conclusiones: En el primer caso se puede justificar la no automatización con una simple carencia de la necesidad. La frecuencia con la que debo realizar estas tareas es tan baja que no la considero repetitiva (Queda la duda de cómo se aplican los parches de seguridad en ese caso, pero no es el tema de este post).

En el segundo caso, cuando se trabaja directamente en el servidor se dificulta mucho la automatización de los procesos dado que se hacen cambios al código frecuentemente. Al trabajar directamente en el servidor, cualquier modificación que se haga automática, sin tener en cuenta dichas modificaciones, producirá que se pierda trabajo. En este caso antes de pensar en automatizar es mejor pensar en usar mejores prácticas a la hora de trabajar.

Teniendo esto en cuenta, a menos que rara vez toquemos el servidor, o que lo usemos como nuestro computador de escritorio, no pude encontrar razones válidas para no automatizar.

¿Y qué razones hay para automatizar?

Es más fácil encontrar razones para automatizar sus procesos de software:

  1. Desea optimizar su tiempo, usándolo para operaciones que realmente importan y no para procesos repetitivos. En promedio, configurar un nuevo servidor puede tomar entre 1 y 2 horas dependiendo del stack que utilice. Si lo automatiza puede reducir el tiempo que usted invierte a lo que tarda en dar un clic, y el servidor estará listo en 5 minutos o menos.
  2. Desea eliminar el error humano de la ecuación: Los humanos nos equivocamos, ¡especialmente cuando estamos cansados y realizando tareas repetitivas! Automatizar un proceso disminuye el riesgo de error y hace que recuperarse de los mismos sea mucho más fácil y rápido.
  3. Desea optimizar costos: El tiempo de un desarrollador es costoso, por lo que es importante usarlo en tareas adecuadas. Si el personal requerido para mantener funcionando su infraestructura se reduce, sus costos también lo hacen, a la vez que incrementa la calidad de sus productos.

Automatizar no es gratis, requiere una inversión inicial grande para familiarizarse con las tecnologías y metodologías necesarias. En mi caso empecé con scripts de BASH, después probé AWS CodeDeploy y finalmente me encontré con Ansible. Pasé de configurar mis servidores manualmente comando por comando a configurarlos según mis parámetros con una sola tarea. Después de estar en ese punto se pudo automatizar aún más, integrando pruebas dentro de nuestro proceso y creando un flujo similar a la siguiente imagen.

Grégoire Détrez, original by Jez Humble

Básicamente nuestro flujo es el siguiente:

  • Alguno de nuestros desarrolladores envía algo a nuestro sistema de control de versiones (GIT).
  • Se inicia el proceso de pruebas automatizadas.
  • Si el proceso de pruebas falla, el desarrollador a cargo debe corregir lo que salió mal para poder finalizar su tarea.
  • Si el proceso de pruebas es un éxito se procede a actualizar nuestro servidor de desarrollo.
  • Se realizan pruebas generales, adicionales a las automatizadas, por parte de alguien encargado de QA.
  • Si todos los features necesarios para el siguiente release están listos, el project manager, que no está muy familiarizado con el proceso técnico del deploy, puede hacer el release.
  • Se repite el proceso de pruebas, con la diferencia de que si todo sale como se espera se actualiza el servidor de producción, no el de desarrollo.

Hay varios detalles acerca de este flujo. Dentro de las múltiples ventajas que nos brinda este flujo, vale la pena recalcar que nuestro servidor de desarrollo siempre contiene la versión más actualizada que ha pasado las pruebas, por lo que se puede ver en vivo un feature en cuanto un desarrollador lo termina. Esto es muy importante tanto para los procesos internos como para la comunicación con el cliente; dado que podemos recibir feedback y reaccionar más rápidamente si se requieren cambios en la estrategia.

Por otro lado, pasemos a los costos. Tenemos actualmente 8 desarrolladores activos, quienes actualizan constantemente el repositorio de nuestros proyectos (más de 10 activos). Si quisiéramos mantener actualizadas todas las instancias de desarrollo sin nuestra herramienta de automatización requeriríamos una o dos personas adicionales dedicadas completamente a actualizarlos, con todas las desventajas adicionales que eso trae.

¿Quiere probar este proceso en su empresa? ¿No sabe por donde iniciar?

Como parte de nuestro proceso desarrollamos una herramienta que nos permite soportar todo nuestro proceso. Si está interesado en automatizar los procesos en su empresa le podemos asesorar en como empezar y estamos abiertos a ofrecer nuestra herramienta como servicio.


Comments