Ingeniería
Cómo un manifiesto adios.yaml lleva una aplicación del entorno local a producción
Un archivo adios.yaml pequeño mantiene las decisiones de compilación y ejecución cerca del código, tanto si el código fuente parte de una carpeta local como de un espacio de trabajo compartido.
La configuración del despliegue es más fácil de entender cuando está junto al código que describe.
Mantén el contrato pequeño
Un manifiesto de Adios define el contrato de ejecución de una carga de trabajo: cómo compilarla e iniciarla, en qué puerto escucha y qué valores de entorno o volúmenes necesita. Estos detalles suelen desajustarse cuando solo están en un panel o en un manual operativo mantenido a mano.
Incluirlos en adios.yaml hace visible la ruta de despliegue durante la revisión del código. Un compañero puede ver que una aplicación Node.js se compila con npm run build o que un servicio Go se compila en un único binario sin abrir primero la consola de la plataforma.
- —El comando de compilación se puede reproducir desde una copia limpia del repositorio.
- —El comando de inicio lanza el proceso de producción, no un servidor de desarrollo.
- —El puerto y la dirección de escucha funcionan dentro de un entorno de ejecución aislado.
- —Las credenciales necesarias usan referencias a secretos en lugar de valores literales.
name: api
build_cmd: npm ci && npm run build
start_cmd: node dist/main.js
runtime:
name: node@24
port: 8080
health_path: /healthzUtiliza el mismo archivo en cada flujo de código fuente
El código fuente puede partir de un directorio local, un repositorio Git o un espacio de trabajo de Adios. El manifiesto sigue dando las mismas instrucciones a las capas de compilación y ejecución. Esa continuidad importa cuando un prototipo rápido se convierte en un servicio que el equipo debe mantener.
Puedes cambiar juntos el código del framework y el contrato de despliegue, ejecutar las comprobaciones pertinentes y promover el resultado sin trasladarlo a un segundo sistema de configuración.
Mejor explícito que ingenioso
Un manifiesto debe resultar predecible. Prefiere un comando que un desarrollador pueda ejecutar y depurar a una cadena de convenciones ocultas. Usa referencias para los secretos, declara explícitamente los datos persistentes y haz que la comprobación de estado refleje lo que la carga de trabajo puede servir realmente.
Así tienes menos cosas que recordar cuando algo falla y resulta más fácil inspeccionar la ruta del código fuente a producción.
Revisa los cambios del manifiesto como cambios operativos
Cambiar start_cmd, una comprobación de estado o un volumen persistente puede alterar la disponibilidad aunque el código de la aplicación no cambie. Revisa esas líneas con el mismo cuidado que una migración de base de datos: ¿qué ocurre con las réplicas existentes, qué datos se conservan y cómo demostrará el nuevo proceso que está listo?
Una pull request útil explica el comportamiento anterior y el nuevo del entorno de ejecución, incluye el comando usado para verificar la compilación e indica cómo revertir el cambio. El manifiesto es breve, pero sigue siendo código de producción.