Tenemos nueve scripts que funcionan, cada uno con sus opciones, su configuración y su manera de invocarse. Eso no es un producto: es una carpeta. Un compañero que entra mañana no sabe cuál ejecutar, la ayuda está repartida en nueve --help distintos, la instalación es «copia esto y acuérdate de los permisos», y nadie sabe qué versión corre en srv-veloz-02. Este último proyecto convierte la colección en veloz-ops: un único comando con subcomandos, instalable, configurable, versionado, probado, desplegado en la flota y documentado. Es el cierre del curso, y el paso que separa «sé programar en Bash» de «he entregado algo».

1. El toolkit visto entero
2. El patrón de comando único con subcomandos
3. Reorganización final del repositorio
4. Configuración unificada y veloz-ops config
5. Autocompletado de Bash
6. Instalación idempotente
7. Versionado semántico y veloz-ops version
8. Calidad antes de desplegar
9. Despliegue en la flota y vuelta atrás
10. Documentación: README y runbook

El diagrama muestra la propiedad que buscamos: una puerta de entrada, una librería común, una configuración. Los scripts pasan a libexec/ porque dejan de ser interfaz pública; nadie los invoca directamente, los invoca veloz-ops.

Es el patrón de git, systemctl o docker, y en Bash se implementa con case y funciones (04-05):

Tres decisiones. exec reemplaza el proceso en lugar de crear uno hijo: ahorra un proceso y, más importante, el código de salida y las señales llegan al script real sin intermediario, así que Ctrl-C sobre veloz-ops respaldo interrumpe el respaldo de verdad. El case es una lista blanca explícita (08-03): construir la ruta como "$LIBEXEC/$sub.sh" sería más corto y permitiría a cualquiera ejecutar veloz-ops ../../bin/loquesea. Y el subcomando desconocido sale con código 2 y escribe en stderr, siguiendo el convenio de 05-03.

El criterio merece la pena enunciarlo: bin/ es lo que el usuario invoca, libexec/ lo que invoca el programa, lib/ lo que se carga con source y nunca se ejecuta, etc/ lo que se edita sin desplegar. Esa última frase decide las dudas: si cambiarlo exige revisión de código, es código; si es una ruta, un umbral o una lista de objetivos, es configuración.

La precedencia de 05-06 —defecto < fichero < entorno < opciones— se implementa en un único punto de lib/comun.sh, y se hace auditable guardando el origen de cada valor:

${!env_var} es la expansión indirecta (03-06): construye el nombre VELOZ_UMBRAL_DISCO y lee esa variable. Guardar el origen junto al valor cuesta un array asociativo más y resuelve la pregunta que consume horas en producción: «el umbral está a 95, pero el fichero dice 85, ¿de dónde sale?». veloz-ops config lo imprime en tres columnas —clave, valor, origen— y por eso es un subcomando de primera clase y no un echo de depuración.

COMP_WORDS y COMP_CWORD son las variables que Bash rellena al pulsar Tab, y compgen -W filtra una lista por el prefijo tecleado. No es cosmética: el autocompletado es la documentación que la gente lee de verdad, y evita la mitad de los errores de tecleo en un subcomando delicado como restaurar.

install.sh debe poder ejecutarse cien veces con el mismo resultado (07-02):

install en lugar de cp + chmod porque crea el destino y fija los permisos en una sola operación, y es idempotente por naturaleza; ln -sfn sobrescribe el enlace sin quejarse; systemctl enable --now activa y arranca, y repetirlo no hace daño. La línea clave es la condicional: la configuración existente no se pisa nunca. Un instalador que sobrescribe veloz-ops.conf borra los umbrales que alguien ajustó a las tres de la mañana; por eso el repositorio versiona veloz-ops.conf.ejemplo y no el fichero real (08-04). La desinstalación es simétrica: --desinstalar para y deshabilita los timers, borra las unidades, hace daemon-reload, elimina el enlace y el árbol, y conserva etc/ y los respaldos, avisando de dónde quedan.

La versión sale de Git, no de una constante que alguien olvidará actualizar (08-04):

git describe --tags --dirty da v1.4.0 en una etiqueta exacta, v1.4.0-7-gab12cd3 si hay siete commits encima —lo que revela al instante que en ese servidor hay algo sin publicar— y añade -dirty si hay cambios sin confirmar, que en producción es una alerta en sí misma. El install.sh escribe además un fichero VERSION para el despliegue por rsync sin repositorio.

Un solo script recoge todas las comprobaciones del módulo 8:

El orden va de lo rápido a lo lento: bash -n tarda milisegundos y descarta un error de sintaxis antes de gastar treinta segundos en Bats. shellcheck -x sigue los source para analizar también lib/comun.sh (08-05), y -S style sube el listón por encima de los errores. shfmt -d no reformatea, solo muestra la diferencia y falla: en CI hay que fallar, no arreglar por sorpresa. La batería de Bats se amplía a los subcomandos (08-06):

La segunda prueba es la más valiosa del toolkit: verifica que el modo simulación no tiene efectos, que es la promesa en la que se apoya cualquiera antes de lanzar un respaldo con --delete. El hook pre-commit (08-04) ejecuta las tres primeras etapas y CI la batería completa en cada rama.

El despliegue es secuencial y con verificación posterior en cada host: si srv-veloz-01 falla, no se toca el segundo, y en el peor caso queda un servidor mal y dos intactos. ssh -n (07-06) impide que el bucle se coma la entrada estándar, el error clásico que hace que solo se despliegue el primer host. Se despliega una etiqueta, nunca una rama: git checkout v1.4.0 da exactamente el código que se probó, y la vuelta atrás es la misma orden con la etiqueta anterior (despliega v1.3.2). Que revertir sea idéntico a desplegar es lo que hace que alguien se atreva a ejecutarlo a las cuatro de la mañana. Con una salvedad para el runbook: revertir el código es trivial, revertir un cambio de formato de los ficheros de estado o del histórico no lo es, y por eso ese tipo de cambio incrementa la versión MAYOR.

Son dos documentos con dos lectores distintos y forman parte del entregable. El README.md lo lee quien llega nuevo, en frío: qué es, qué requiere, cómo se instala en cinco órdenes copiables, los subcomandos con un ejemplo real cada uno y dónde está la configuración. Si alguien no puede instalarlo y ejecutar veloz-ops estado siguiendo solo el README, el README está mal. El docs/runbook.md lo lee alguien medio dormido con una alerta en el móvil: se organiza por alerta, no por script, sin prosa y con órdenes copiables.

Un script sin documentación es un script que solo puede ejecutar quien lo escribió; y quien lo escribió acabará de vacaciones justo la noche en que falle.

• Construir la ruta del subcomando con el argumento del usuario. "$LIBEXEC/$1.sh" abre la puerta a ../. Lista blanca con case, siempre.
• Instaladores que pisan la configuración. Versiona .conf.ejemplo; el .conf real solo se crea si no existe.
• Desplegar una rama en lugar de una etiqueta. main significa una cosa distinta cada hora; una etiqueta significa siempre lo mismo.
• Bucle for host con ssh sin -n. El primer ssh consume la lista y el resto de la flota se queda sin desplegar, en silencio.
• Documentar por script en vez de por alerta. A las cuatro de la mañana nadie busca «analiza-logs»; busca el texto que le llegó al móvil.
• Consejo: ejecuta veloz-ops config en los tres servidores y compara. Las diferencias no explicadas entre nodos son el origen de la mitad de los incidentes de «en este servidor sí funciona».

1. Subcomando doctor. Verifica la salud de la propia instalación: dependencias (jq, rsync, curl, awk), permisos de etc/ (600), timers activos, antigüedad del último respaldo y del último ciclo del monitor. Un símbolo por comprobación y código 0/1/2 global.
2. Panel del estado de la flota. Un veloz-ops flota estado que recoja el JSON de estado de los tres servidores en paralelo y marque las diferencias de versión, kernel y configuración efectiva.
3. Retos abiertos de ampliación. Empaqueta el toolkit como .deb con postinst/prerm y la configuración marcada como conffiles; añade un veloz-ops api que exponga los informes por HTTP decidiendo qué no exponer; unifica un --json en todos los subcomandos con una prueba Bats que valide cada salida; y lleva el toolkit a Debian o Alpine anotando cada bashismo que haya que resolver (08-07).

1. doctor no comprueba nada por su cuenta: reutiliza lo ya construido.

La función anidada chk, que recibe una orden y la ejecuta, evita repetir el mismo if diez veces; y devolver 0/2 permite que el propio doctor se vigile desde vigilante.sh con el convenio de 07-04.

2. flota.sh ya ejecuta en paralelo, así que basta con consolidar los JSON con jq -s:

Detectar la divergencia —no listar los valores— es lo que convierte el panel en una herramienta útil: si kernels_distintos es mayor que 1, hay un servidor sin actualizar.

Empezamos el curso escribiendo echo "Hola" en un terminal y lo terminamos con un producto instalado en tres servidores: un comando único con subcomandos y ayuda, configuración con precedencia y auditable, autocompletado, instalador idempotente y desinstalador simétrico, versionado semántico atado a las etiquetas de Git, una batería de pruebas que corre en cada commit, despliegue por etiqueta con vuelta atrás y documentación escrita para quien la leerá de madrugada. Ninguna de esas piezas es Bash avanzado: son case, funciones, arrays, printf, source y códigos de salida —lo del módulo 4— aplicados con el criterio del módulo 8. Ese es el mensaje del curso entero: la diferencia entre un script y una herramienta no está en el lenguaje, está en la disciplina.

Conviene terminar con honestidad sobre los límites. Bash es insuperable pegando programas, moviendo ficheros y automatizando el sistema; es exactamente la herramienta correcta para los cinco proyectos de este módulo. Deja de serlo cuando aparecen estructuras de datos anidadas (más de dos niveles de JSON y jq ya no basta), cuando hacen falta pruebas unitarias de lógica de negocio, concurrencia real, aritmética de coma flotante sostenida, o cuando el script pasa de las mil líneas y cada cambio da miedo. Si te encuentras escribiendo un analizador de expresiones o un cliente HTTP con estado en Bash, la señal es clara: toca Python, Go o el lenguaje que use tu equipo. Saber cuándo parar forma parte de dominar la herramienta, y reescribir en otro lenguaje un script de Bash bien estructurado es sencillo precisamente porque estaba bien estructurado.

Y por dónde seguir. El manual de Bash (man bash, y sobre todo su sección de expansiones, que se lee entera una vez en la vida) es la única fuente definitiva. La guía de estilo de shell de Google, para discutir decisiones con argumentos en lugar de con gustos. ShellCheck como maestro permanente: cada aviso que no entiendas, búscalo por su código y aprenderás algo que no sabías. Y sobre todo, lo que de verdad consolida: automatiza lo tuyo. Coge esa tarea que haces a mano cada lunes, escríbela como un script con set -euo pipefail, dale opciones, ponle un --simular, pruébala con Bats, súbela a Git y dispárala con un timer. En eso consiste el oficio, y ya lo sabes hacer entero.