cloud / sistemas
En Cómo construí este sitio web con prompts conté cómo la IA me ayudó a convertir una antigua instalación de WordPress en un sitio estático en AWS S3 y CloudFront. Lo que no anticipé fue la rapidez con la que una web sencilla se convertiría en un proyecto de software complejo.
Cómo fuimos acumulando complejidad
Comenzamos con unas pocas páginas. Luego llegaron las previsiones meteorológicas, los datos de entrenamiento, los juegos, las verificaciones de seguridad, los despliegues automáticos y nueve idiomas. Añadimos alemán, español, chino, francés, portugués de Brasil, japonés, hindi y neerlandés alrededor del original inglés. La web ganó alcance, pero cada idioma trajo nuevas páginas, enlaces, metadatos, feeds y posibilidades de error.
Nuestra suposición ingenua fue que generar nueve ediciones de una web estática siempre sería barato. En realidad, hasta una pequeña modificación en inglés podía quedar esperando la instalación de fuentes, la generación de imágenes, la navegación de todos los idiomas y los controles de seguridad. Convertimos nueve idiomas en una única dependencia de publicación.
Todos los idiomas tenían que terminar antes de publicar
El problema no eran las traducciones; era nuestro diseño de dependencias.
Cuando la seguridad también añade obstáculos
En GitHub sufrimos problemas con escáneres de secretos, discrepancias en compilaciones reproducibles, instalaciones de fuentes bloqueadas, errores de configuración de workflows y permisos IAM de AWS insuficientes. Durante una recuperación comprobamos 534 objetos públicos: 501 coincidían, 24 eran diferentes y nueve páginas nuevas no se podían leer.
Todos los controles tenían su razón de ser. Sin embargo, combinados hicieron que cambios pequeños fueran sorprendentemente difíciles. Más automatización no garantiza una automatización mejor. Ante un control fallido hay que investigar, no desactivar la protección.
El nuevo diseño: primero inglés, después ocho idiomas
Queremos separar la publicación del idioma principal de las traducciones revisadas.
menos es mejor
Este esquema representa el orden de publicación previsto, no una prueba de que ya se haya ejecutado así en producción. Las traducciones tienen autorizaciones ligadas mediante SHA-256 a la fuente inglesa exacta. Si cambia esa fuente, las autorizaciones anteriores dejan de ser válidas. Nunca deben publicarse páginas inglesas haciéndolas pasar por traducciones.
Mantenemos compilaciones reproducibles, OIDC, privilegios mínimos en AWS, límites presupuestarios y cero invalidaciones de CloudFront.
Lo que comprobamos de verdad
Los PR #119–#122 incorporaron un compilador de artículos ingleses, otro para ocho traducciones revisadas y una secuencia de prueba inglés → traducciones → integridad. La prueba manual no tiene permisos de escritura en AWS. La publicación por etapas sigue protegida por variables de autorización; el workflow OIDC habitual todavía ejecuta todas las comprobaciones del sitio antes de subir contenido.
Por eso, una CI verde no demuestra que inglés esté publicado mientras los otros idiomas se procesan. El ensayo previo indicaba sourceToHtmlBuildComplete=false, productionDeploymentApproved=false y cero escrituras en S3.
Los tiempos que sí medimos
Comparamos dos cambios similares del registro de novedades en nueve idiomas, el 7 de noviembre de 2026. Son mediciones de la pipeline completa anterior, no un antes/después de publicaciones inglesas independientes.
| Indicador | Antes | Después | Diferencia |
|---|---|---|---|
| Comprobaciones CI sin conexión | 3:38 min (218 s) | 3:18 min (198 s) | 9,2 % más rápido |
| Control de calidad completo | 2:55 min (175 s) | 2:27 min (147 s) | 16,0 % más rápido |
| Gitleaks | 56 s | 67 s | 11 s más lento |
| Semgrep | 10 s | 11 s | casi igual |
| pip-audit | 13 s | 12 s | casi igual |
| Apertura del PR hasta merge | 41:50 min | 34:29 min | 7:21 min menos |
menos es mejor
El control de calidad es parte de la CI, no un tiempo adicional. Los trabajos de seguridad se ejecutan en paralelo. Semgrep y pip-audit omitieron la fase costosa de análisis en ambos cambios de documentación. Dos ejecuciones tampoco prueban una mejora duradera.
Entre las mejoras encontramos eliminar controles repetidos de assets, reutilizar hashes SHA-256, almacenar en caché descargas de Python y Sharp, medir cada generador y ofrecer una vía rápida para cambios puramente documentales.
La vía rápida de inglés
Un benchmark independiente, solo de simulación, midió 0,562 segundos para el contrato HTML inglés (60 páginas, 96 assets, 514 enlaces HTML locales). La secuencia simulada de comprobaciones de merge tardó 15 segundos; 501 archivos de otros idiomas permanecieron intactos.
Son tiempos de componentes y ensayos, no el tiempo real de merge a publicación S3. Sería engañoso comparar los 15 segundos directamente con los 198 segundos de toda la CI.
De la idea a una página publicada
Un pull request no es un despliegue. Tras las pruebas, la revisión y el merge, el sistema de publicación valida archivos, hashes, permisos y presupuesto. Solo después escribe en S3. Sin invalidaciones de CloudFront, la caché se renueva según su TTL normal.
Para demostrar una publicación realmente escalonada mediremos T0 merge inglés, T1 fin de pruebas inglesas, T2 confirmación del upload inglés, T3 inicio y fin de traducciones y T4 confirmación del upload de los ocho idiomas. Solo esos datos permiten afirmar que los lectores reciben inglés antes.
Mi flujo favorito para depurar
ChatGPT puede revisar los logs de una PR, proponer correcciones pequeñas y comprobar otra ejecución de CI. Es especialmente útil al final del día. No significa que una sesión de chat funcione de forma autónoma e indefinida: sigue siendo necesaria una sesión activa y la revisión humana.
La lección
La mejora decisiva no es únicamente ahorrar segundos. Es dejar de hacer depender el primer resultado útil de ocho resultados posteriores. El inglés puede avanzar de forma fiable y las traducciones seguir cuando estén revisadas. Las mediciones de producción deberán demostrar cuánto tiempo ganamos en realidad.