Tu agente de programación no es un flujo de despliegue

9 min de lectura

El arreglo ya está en producción. Comprar es imposible.

El atajo de ayer es el procedimiento de hoy

Imagina a la dueña de una tienda que ha creado una pequeña aplicación de pedidos con un asistente de IA. Conoce a sus clientes y sabe qué excepciones complican el trabajo en su negocio. Poner software en servicio es terreno nuevo. La primera versión funcionó en su portátil, así que la copió a un servidor de alquiler. Los clientes hicieron pedidos. Estupendo.

El cambio siguiente también funcionó. Al poco tiempo, el asistente ya editaba los archivos en el propio servidor. Se ahorraban la copia. Todo un avance, al parecer.

Hasta que un cambio en los gastos de envío introduce un formato nuevo en una parte de la aplicación mientras otra todavía espera el anterior. Un cliente intenta comprar en plena actualización. Puede ver el carrito, pero no completar el pedido. La dueña vuelve a cargar la página de inicio. Funciona. Su compañero prueba a comprar de verdad. Eso ya no.

Los clientes podían usar la aplicación mientras el asistente la modificaba. Que un pedido saliera adelante dependía de cuándo se hiciera y de si las piezas viejas y nuevas podían funcionar juntas. Nadie había comprobado ninguna de las dos cosas.

Echarle la culpa al agente tranquiliza. También deja al siguiente agente ante la misma trampa.

Cada versión necesita una identidad

Empieza por una pregunta sencilla. ¿Qué versión está en servicio exactamente?

«Los archivos del servidor» indica un lugar. No identifica una versión. Si algunos llegaron ayer del portátil y otros salieron del arreglo de esta mañana, la carpeta puede contener una mezcla que nunca ha existido en ningún otro sitio.

Guarda el código fuente y las instrucciones de compilación y empaquetado en el control de versiones. Registra una versión concreta del código y genera a partir de ella un paquete versionado con un proceso que puedas repetir. Fija las dependencias de forma que puedas reproducir el resultado previsto. Separa los ajustes que cambian de un entorno a otro y guarda las credenciales en un almacén de secretos.

A ese paquete se le suele llamar artefacto de compilación. Puede ser una imagen de contenedor, un archivo comprimido con la aplicación o una carpeta de archivos estáticos empaquetada para el despliegue. El formato depende de la aplicación. Lo importante es poder identificar el paquete y conservarlo intacto durante las pruebas y el despliegue.

La guía de DORA sobre automatización de despliegues recomienda usar los mismos paquetes en todos los entornos, separar la configuración propia de cada entorno y guardar los scripts de despliegue en el control de versiones. Así evitas descubrir que a producción llegó algo distinto de lo que superó las pruebas.

Volver a generar el paquete para producción puede introducir una dependencia distinta o un archivo generado de otra manera. Si cambias el paquete después de las pruebas, todavía queda por probar lo que acabas de cambiar. El resultado de una prueba vale para la versión que la pasó.

Todo esto tiene poco glamour. Es una de sus virtudes.

La página de inicio carga. Prueba a hacer un pedido.

A la tienda le interesa saber si el cliente puede hacer un pedido con los gastos de envío correctos y si al negocio le llega la información necesaria para tramitarlo. También conviene comprobar qué pasa cuando falla un pago, cuando se envía dos veces el mismo pedido y cuando la aplicación tiene que cumplir lo que promete sobre las existencias.

Ejecuta comprobaciones automáticas rápidas cada vez que se integren cambios. Prueba el paquete en un entorno separado antes de llevarlo a producción. Ese entorno debe parecerse lo suficiente al de producción para que aparezcan los fallos que importan. Para eso sirven las cuentas de prueba y los datos de ejemplo adecuados. No hace falta copiar los datos privados de todos los clientes.

Ensaya también el despliegue. Una tienda pequeña puede instalar el paquete nuevo junto al anterior, comprobar que arranca y que puede conectarse a los servicios que necesita, y luego dirigir las peticiones a la nueva versión. Si esas comprobaciones fallan, los clientes pueden seguir usando la anterior. Mientras compartan la base de datos, las dos versiones tienen que poder trabajar con los mismos datos.

Martin Fowler describe el flujo de despliegue como una sucesión de etapas en las que cada comprobación aumenta la confianza en la versión. Los resultados rápidos llegan primero y las pruebas más costosas vienen después. En algunas etapas, una persona puede decidir si se sigue adelante. Así queda a la vista el camino desde el cambio hasta las pruebas que justifican su puesta en servicio.

Con la integración continua, los desarrolladores reúnen sus cambios con frecuencia y comprueban automáticamente el resultado. La entrega continua mantiene el software listo para desplegar cuando haga falta. La dueña puede decidir cuándo reciben el cambio sus clientes. Si cada cambio que supera las pruebas pasa a producción de forma automática, hablamos de despliegue continuo.

Para una aplicación diminuta pueden bastar unas pocas comprobaciones y un script de despliegue corto. El esfuerzo puede ir a la medida del negocio. Dejar fuera el proceso de compra al probar una aplicación de pedidos ya es un logro de otro tipo.

La vuelta atrás tiene que funcionar con los datos de hoy

Ten a mano la última versión que sabes que funcionaba y define cómo volver a ella. Ensaya el cambio antes de darlo por bueno como plan de recuperación. Comprueba también el servicio después de poner la nueva versión en marcha. Un proceso puede seguir en ejecución y fallar en cada compra.

Ahora viene la parte incómoda. Supón que la versión nueva guarda los gastos de envío de otra manera. La anterior quizá no pueda leer los pedidos registrados desde el cambio. Volver al paquete anterior podría cambiar un fallo por otro.

Cuando se pueda, planifica los cambios de base de datos para que las dos versiones de la aplicación puedan coexistir durante la transición. Añadir un campo, pasar a usarlo poco a poco y retirar el anterior más adelante suele facilitar la recuperación frente a un reemplazo de golpe. Algunos cambios aun así exigen una corrección en la versión nueva o un procedimiento de recuperación bien preparado.

Una copia de seguridad protege frente a la pérdida de datos. Restaurarla puede borrar pedidos válidos que llegaron después de hacerla. Un reembolso ya tramitado por el proveedor de pagos no va a desaparecer por cortesía cuando alguien restaure la base de datos. La recuperación tiene que contar con esas operaciones externas.

La dueña puede plantear la pregunta sin hacer un examen de vocabulario. Si la nueva versión falla al tramitar pedidos después de tres compras que sí salieron bien, ¿podemos recuperar el servicio y conservar esos pedidos y sus registros de pago?

Mejor preguntarlo antes de que el cuarto cliente haga la prueba.

El asistente debería explicar el paso que falta

Cuando alguien dice «pon mi aplicación en línea», el asistente debería averiguar qué hará la aplicación y dónde va a funcionar. ¿Es una demo de usar y tirar, una herramienta interna o un servicio que cobra a clientes? ¿Cómo se despliega hoy? ¿Quién se responsabiliza de los datos de producción? ¿Qué puede cambiar el asistente?

Después toca concretar. Registrar el cambio, ejecutar las comprobaciones pertinentes, generar un paquete identificable, ensayar el despliegue en el entorno adecuado y preparar la recuperación antes de poner la versión en servicio. Si el proyecto ya tiene un comando de arranque y un procedimiento de despliegue, el asistente debería usarlos. Abrir otra vía para ahorrarse un mensaje es una idea peculiar de la eficiencia.

Un agente puede ayudar a preparar y ejecutar ese procedimiento. Puede investigar una prueba fallida, mejorar el script o iniciar un despliegue autorizado. El procedimiento tiene que existir fuera de la sesión del agente. La configuración y los resultados de las pruebas deben seguir disponibles después de la conversación.

Da al proceso de despliegue los permisos necesarios para instalar un paquete aprobado y registrar qué versión entró en servicio. El asistente puede editar y probar el código con sus propios permisos, por separado.

Una reparación de emergencia puede exigir una excepción. Registra el cambio, incorpora el arreglo al código fuente habitual y restablece después un estado conocido. De lo contrario, la excepción se convierte discretamente en el sistema de despliegue de mañana.

Que sea fácil de crear no lo hace fácil de operar

Mucho antes de programar conversando con una IA, la gente hacía aplicaciones útiles para su departamento con Visual Basic, hojas de cálculo y macros. Una herramienta práctica podía convertirse en algo de lo que dependían los compañeros. Eso no daba de repente a su creador experiencia en pruebas, despliegues, control de accesos y recuperación. La IA puede acortar el trayecto entre la idea y esa responsabilidad.

Una herramienta alojada por un proveedor puede encargarse de buena parte del despliegue. Pagar por ello puede tener sentido. El proveedor opera la plataforma y el usuario trabaja dentro de lo que esta permite. Comprueba dónde están esos límites, sobre todo cuando entran en juego datos de clientes o servicios externos.

Llevar el código a un servidor propio cambia quién tiene que responder por el funcionamiento del servicio. Haber pulsado un botón para compartir en otra plataforma no resuelve esas cuestiones. El entusiasmo del asistente tampoco.

No hace falta inventar un plan secreto de los proveedores para explicar la diferencia. Una demo rápida se ve enseguida. Un segundo despliegue fiable cuesta más de mostrar en un vídeo de lanzamiento.

La dueña de la tienda merece las dos cosas. Convertir un experimento útil en un servicio fiable implica que los cambios sean tan rutinarios que su compañero pueda seguir preparando pedidos mientras se hacen.

La próxima vez que le pida al asistente corregir los gastos de envío, tiene que haber una versión completa que probar, un procedimiento conocido para ponerla en servicio y una respuesta creíble si falla. Los clientes ya tienen bastante con ver cuánto cuesta el envío.