9 consejos para realizar despliegues en producción sin dolores de cabeza

En este artículo te quiero contar algunos consejos y lecciones aprendidas sobre los despliegues en producción, a los que también podés llamar implementaciones, deploys o instalaciones. Me refiero a cuando instalás un nuevo sistema o una nueva versión de un sistema a un cliente. No importa si es un sitio web, un programa de escritorio o una intranet.

Lo que me motiva a escribir este artículo es transmitirte la idea de que el despliegue no es algo cotidiano que deba tomarse a la ligera, sino que requiere su preparación y que tiene un modo de ejecución.

Lo más importante es entender que no es cuestión de terminar un ticket, cerrarlo y mandarlo a producción. Hay todo un proceso que debe llevarse adelante. Crear ese proceso es tu tarea. Aquí te voy a enumerar algunas de las cuestiones que yo considero importantes y que podés tomar (o no) para armar tu propio proceso.

Disponer de un ambiente de prueba y de producción

Cuanto más complejo y grande es el proyecto más necesario es disponer de un ambiente de prueba o de stage para volcar los cambios antes de hacerlo en producción.

Este ambiente de prueba tiene que tener las mismas especificaciones técnicas y al momento de probar, se tiene que utilizar una base de datos similar o idéntica a la de producción.

Realizar un testing intensivo

Si bien esto está relacionado con el desarrollo en sí mismo, yo siempre considero que el testing intensivo es el primer paso del despliegue en producción. Allí pueden aparecer distintos errores, de esos que no quiero que me aparezcan en producción.

Mi recomendación es hacer este testing intensivo en el ambiente de prueba o stage, que como mencioné antes, tiene que tener exactamente las mismas características que el ambiente de producción.

La mentalidad de los despliegues en producción

En mi opinión, lo más importante a la hora del deploy es la mentalidad que se adopta.

Yo me lo tomo muy en serio. Elimino todas las distracciones a mi alrededor. Apago la música de fondo, la televisión y silencio las notificaciones del teléfono durante el tiempo que estimo lleve el deploy.

Luego, ejecuto cada paso con toda la concentración posible. Pienso en cada acción e intento estar atento en los posibles resultados.

La mentalidad de despliegue es lo más parecido a la mentalidad en pleno examen.

El horario del despliegue

A la hora de elegir un horario para los despliegues en producción (si esto es posible), yo recomiendo esos horarios en los que no hay usuarios utilizando el sistema. Si se trata de una página web entonces lo mejor es elegir los días y horarios donde hay menos tráfico.

No hay que olvidar que poner un sitio offline puede perjudicar los ingresos de un negocio. Eso es un punto más a favor de elegir momentos donde hay poco tráfico.

Generalmente estos momentos son en las madrugadas o en horas muy tempranas de la mañana. En caso de una intranet para una empresa, los mejores momentos son los fines de semana y feriados.

Esto que a priori puede parecer algo molesto para uno, es en realidad algo bueno. En esos horarios hay tiempo para trabajar sin apuros y de realizar el despliegue varias veces en caso de falla.

Documento con los pasos a seguir

Algo que me ha resultado útil a través de los años es crear documentos de despliegue. Esto lo aprendí trabajando en empresas y es una buena costumbre que heredé.

El documento solamente tiene que describir con claridad los pasos que hay que realizar para completar el despliegue.

A la hora del deploy se tiene que tomar este documento y seguirlo en el orden que corresponde. ¡Nada debería «malir sal»!

Backups

Parece una obviedad pero es necesario realizar todos los backups de los datos que se puedan ver afectados. Bases de datos y código, son los más comunes.

Más allá de que en los sistemas que desarrollo y administro dejo corriendo siempre un script de backup automático, igualmente a la hora de deployar vuelvo a hacer backups de bases de datos, por las dudas. Luego, chequeo que el archivo de backup se haya generado bien y finalmente lo subo a dos servidores distintos.

Puede parecerte excesivo, pero más vale prevenir que lamentar luego.

Con el código, cada tanto hago una copia exacta del que está corriendo en producción, aunque, al trabajar con Git e integración continua, esto no es necesario.

Y hablando de integración continua…

Favorecer los despliegues automatizados y la integración continua

Las herramientas de despliegues automatizados, como Ant en Java ó Phing en PHP, permiten ejecutar todos los pasos del despliegue de forma automática. Cuantos más pasos se automaticen, mejor.

Cuando empecé en este mundo me estudié por completo el manual de Phing y mi objetivo era automatizar absolutamente todo lo vinculado al proceso de despligue. Sin embargo, con el tiempo descubrí que cada deploy es un mundo aparte y que siempre me quedaba alguna tarea por fuera que tenía que ejecutar de forma manual.

Así, desde entonces, utilizo Jenkins + Phing para desplegar principalmente el código, incluyendo archivos de configuración que no pueden pisarse con datos erróneos. Con estas mismas herramientas y Git puedo volver el código atrás en caso de ser necesario.

Si no conocés este mundo de la integración continua, te recomiendo que comiences a investigar. Aumentará tu productividad como programador en un porcentaje elevado y disminuirá los errores en despliegues de forma drástica.

Log de cambios

Algo más que comencé a implementar hace tiempo es el de crear un log de cambios que acompañe a cada documento de deploy. Esto es porque a veces uno se olvida cuáles fueron los cambios que se incluyeron en cada versión y no alcanza con mirar el log de Git.

A veces, cuando se implementa seguido uno tiende a olvidarse de estos detalles. Pero quizás, unos meses o años después puede resultar clave saber en qué momento se añadió determinada funcionalidad. Por eso mismo, no cuesta nada agregar qué se agregó, qué se quitó y qué se actualizó en un log de cambios.

Plan B y reversibilidad de los despliegues en producción

Todo despliegue tiene que poder ser reversible a su estado inicial. Para ello, es recomendable tener un plan B en caso de falla.

Los backups por supuesto que son fundamentales, pero no siempre alcanzan. Es probable que haya que realizar alguna acción adicional a restaurar una base de datos.

Tener estas acciones de contingencia pensadas y anotadas con antelación puede salvarte de un serio dolor de cabeza.

Y eso es todo por este artículo. Espero que algunos de estos consejos te sean de utilidad para mejorar tus procesos de despliegues en producción.

Fuente foto:

Technology illustrations by Storyset