La 08-01 terminaba señalando un hueco: hay una clase de conocimiento que no está en ningún libro porque depende del contexto y caduca demasiado rápido para publicarse. Por qué tu workflow_run no se dispara aunque el YAML sea idéntico al del ejemplo. Por qué el OIDC contra AWS funciona en un repositorio y no en el de al lado. Por qué esa acción de terceros dejó de funcionar el martes sin cambiar de versión. Ninguna de esas respuestas está en Continuous Delivery, y muchas tampoco en la documentación oficial: viven en la cabeza de alguien que ya se topó con ello hace tres semanas.

Esta lección trata de dónde está esa gente, qué esperar de cada sitio, cómo preguntar para que te respondan y —lo que casi nadie hace y es lo que más rápido enseña— cómo devolver algo desde el primer día. También trata de algo menos agradable: la mayor parte del contenido que circula en estos espacios es ruido, moda o cargo culto, y necesitas un filtro.

1. Por qué esto importa de verdad
2. El mapa de espacios: qué esperar de cada uno
3. Fundaciones y ecosistemas
4. Eventos: conferencias, meetups y el pasillo
5. Comunidades en español y por qué participar en dos lenguas
6. Cómo preguntar para que te respondan
7. Cómo contribuir desde el primer día
8. Higiene informativa: distinguir el consejo del cargo culto
9. La ética de compartir logs y datos
10. Errores Comunes y Consejos
11. Ejercicios
12. Conclusión

Hay tres tipos de problema y solo el tercero justifica esta lección.

Problemas de conocimiento. "¿Qué es un digest?" Se resuelven leyendo. Los libros y la documentación bastan.

Problemas de habilidad. "No sé escribir un workflow reutilizable." Se resuelven practicando. El módulo 7 era esto.

Problemas de contexto. "El workflow reutilizable funciona en mi repositorio pero cuando lo llamo desde el repositorio de la organización, secrets: inherit no propaga nada y el error no dice por qué." Este no se resuelve leyendo ni practicando, porque la información necesaria es la intersección entre una herramienta concreta, una versión concreta, una configuración concreta y un comportamiento no documentado. Se resuelve preguntando a alguien que ya estuvo ahí, o encontrando el hilo donde otro lo preguntó.

Cuando trabajabas siguiendo un laboratorio del módulo 7, los problemas de contexto estaban previstos: el material anticipaba los fallos. En tu trabajo real no lo estarán. Y el tiempo que separa a quien se queda bloqueado tres días de quien lo resuelve en dos horas casi nunca es diferencia de talento: es diferencia de saber dónde y cómo preguntar.

Hay un segundo motivo, más lento y más importante. Las comunidades son donde ves la distribución de soluciones. Tú has visto una forma de montar un pipeline: la de este curso, con sus decisiones y sus sesgos. En una comunidad ves cincuenta contextos distintos con cincuenta compromisos distintos, y eso es lo que convierte una técnica aprendida en criterio propio. No puedes calibrar si tu decisión es razonable si solo conoces una decisión.

GitHub Community (el foro de discusiones de GitHub) es el primer sitio al que ir con un problema de GitHub Actions que no sea un bug evidente. Tiene la ventaja de que responde gente de la propia plataforma y de que las respuestas quedan indexadas. La categoría de Actions concentra exactamente los problemas del módulo 6: permisos de GITHUB_TOKEN, contextos disponibles en cada evento, límites de concurrencia, comportamiento de workflow_run y de los entornos con revisores.

El foro de GitLab funciona parecido y con la misma estructura Discourse. Para GitLab hay además una particularidad valiosa: el issue tracker de GitLab está abierto y es el producto mismo. Muchas preguntas de "¿por qué esto es así?" tienen respuesta literal en la issue donde se discutió.

Jenkins tiene el ecosistema más antiguo y el más disperso: listas de correo (jenkinsci-users), un Jira propio para bugs de core y plugins, y canales de chat. Si trabajas con Jenkins —lo que, como decía la 06-01, sigue siendo el caso en la mitad de las empresas con historia— aprender a buscar en su Jira es una habilidad concreta y rentable: la mayoría de los comportamientos raros de un plugin están reportados ahí, a veces desde hace años, con un workaround en el comentario 14.

El Discourse de Kubernetes y los foros de CNCF cubren la parte de orquestación de la 06-05. Kubernetes tiene además un modelo de gobernanza documentado con SIGs (grupos de interés especial) y sus propias reuniones públicas grabadas: si algún día necesitas saber por qué una API se comporta así, la respuesta está en las notas de un SIG.

Qué esperar: precisión sobre la herramienta. Qué no esperar: consejo sobre si deberías estar usando esa herramienta. En el foro de Jenkins, la respuesta a "¿debería migrar a GitHub Actions?" tendrá un sesgo previsible, igual que la contraria en el otro sitio.

Stack Overflow sigue siendo el mejor archivo de errores concretos que existe. Si tienes un mensaje de error literal y raro, ponerlo entre comillas en un buscador y encontrar la pregunta de 2019 con la respuesta aceptada sigue funcionando y sigue ahorrando horas.

Pero hay que ser honesto sobre su estado. El volumen de preguntas nuevas ha caído de forma sostenida, por tres razones que se acumulan: los asistentes de IA responden ahora la mayoría de preguntas de nivel medio sin coste social; la cultura del sitio se volvió notoriamente hostil con quien pregunta mal, lo que expulsó a los principiantes; y buena parte del soporte de las herramientas modernas se ha movido a Discord y a los foros propios de cada producto.

Consecuencia práctica: trátalo como archivo, no como comunidad. Búscalo siempre, y comprueba la fecha y la versión de cada respuesta antes de aplicarla. La mitad de las respuestas de Docker o de Actions con más votos describen sintaxis obsoleta o prácticas hoy desaconsejadas —hay respuestas muy votadas que recomiendan pasar secretos por argumentos de build, algo que la 04-03 te enseñó a no hacer nunca porque quedan en las capas de la imagen—. Los votos miden antigüedad tanto como calidad.

Kubernetes Slack es el ejemplo canónico: decenas de miles de personas, canales por SIG y por tema, y gente que mantiene el proyecto respondiendo. CNCF tiene espacios equivalentes para sus proyectos, y muchas herramientas de este módulo (Argo, Flux, OpenTelemetry, Backstage) tienen su canal ahí o un Discord propio.

Lo bueno: velocidad. Un problema de contexto bien planteado en el canal correcto puede resolverse en veinte minutos por alguien que escribió el código en cuestión. No hay nada comparable.

Lo malo, y es serio: la conversación no persiste de forma útil. Lo que se resuelve en Slack se pierde, no se indexa y no ayuda a nadie más. Es un desperdicio sistemático de conocimiento: los mismos problemas se resuelven una y otra vez sin dejar rastro. La contramedida está en tu mano: cuando un canal te resuelva algo no documentado, escríbelo. En tu PIPELINE.md, en el wiki de tu equipo o —mejor— como respuesta en el foro oficial o como PR a la documentación del proyecto. Convertir una conversación efímera en un artefacto buscable es una de las contribuciones más valiosas y menos hechas.

Y una regla de convivencia: en estos espacios se responde por buena voluntad, en el tiempo libre de alguien. Preguntar bien no es cortesía, es lo que hace que el sistema siga funcionando.

r/devops es útil para algo que ningún otro espacio te da: saber qué está frustrando de verdad al gremio. Los hilos sobre herramientas concretas, migraciones fallidas, salarios y agotamiento profesional te dan una foto de la profesión que no aparece en ninguna conferencia, donde todo el mundo presenta éxitos.

Su sesgo es evidente y hay que descontarlo siempre: la gente publica cuando algo va mal. Nadie escribe "llevamos tres años con Jenkins y funciona". El resultado es una impresión sistemáticamente negativa de todas las herramientas maduras y sistemáticamente entusiasta de las nuevas —hasta que dejan de ser nuevas y empiezan a aparecer los hilos de queja—. Es un termómetro con la escala descalibrada: mide bien las tendencias relativas, mal los valores absolutos.

Hay un segundo sesgo: quien publica en r/devops no es representativo del sector. Está sobrerrepresentado el perfil de infraestructura pura, empresa mediana o grande, entorno anglosajón. Si lees ahí que "nadie usa X ya", significa que en ese subconjunto no lo usan.

Sirven para descubrir que algo existe y, ocasionalmente, para leer los comentarios de la persona que construyó el sistema del que habla el artículo, que a menudo valen mucho más que el artículo. Los hilos sobre post-mortems públicos y sobre arquitecturas reales suelen tener una densidad técnica alta.

Sus sesgos: fuerte inclinación hacia lo novedoso y lo contrarian, sobrerrepresentación de startups y de contextos de escala extrema, y una tendencia al comentario seguro-de-sí-mismo sobre dominios que quien comenta no conoce. Un consejo de HN sobre bases de datos distribuidas puede venir de alguien que las opera o de alguien que leyó un artículo ayer, y el tono es idéntico.

Lobsters es más pequeño y con menos ruido, pero con el mismo perfil.

Uso recomendado: revisión rápida, dos o tres veces por semana como mucho, para el radar. Nunca como fuente de decisión. El coste de atención de estos sitios es su peligro real: son adictivos y producen la sensación de estar aprendiendo mientras solo estás enterándote.

Hay valor real —contactos, ofertas de trabajo, contenido ocasional de gente que sí opera sistemas— envuelto en una capa muy gruesa de marketing personal. El formato premia la afirmación categórica, la lista de "5 cosas" y la historia con moraleja; penaliza el matiz, que es exactamente lo que necesitas.

Uso sensato: red profesional y visibilidad de tu trabajo (la 08-04 hablará de esto), no fuente de aprendizaje. Y desconfía especialmente de los diagramas de "roadmap DevOps" con cuarenta logotipos: consolidan la peor idea posible, que es que esto consiste en acumular herramientas.

Aquí está el conocimiento más fiable de todos y el peor indexado.

Cuando quieres saber por qué una herramienta se comporta como se comporta, la respuesta definitiva está en la issue o en el RFC donde se decidió. Ahí verás las alternativas consideradas, quién se opuso y con qué argumento, y qué compromiso se aceptó. Es una lectura extraordinariamente formativa: te enseña cómo piensan sobre compromisos las personas que diseñan lo que usas.

El problema es encontrarlo. La búsqueda de GitHub sobre issues es mediocre, los RFC están dispersos y las listas de correo tienen archivos incómodos. Técnica que funciona: buscar en un buscador general con site:github.com/<org>/<repo>/issues y el mensaje de error o el nombre exacto de la opción. Y ordenar por comentarios en vez de por relevancia: las issues largas son donde está el workaround.

Un hábito concreto y muy rentable: cuando una herramienta te sorprenda —hace algo que no esperabas y la documentación no lo explica— busca la issue antes de asumir que es un bug tuyo. La mitad de las veces es un comportamiento conocido, discutido, y con solución en un comentario.

Tres nombres aparecen constantemente y conviene saber qué significan.

CNCF (Cloud Native Computing Foundation). Alberga Kubernetes, Prometheus, OpenTelemetry, Argo, Flux, Helm y buena parte del ecosistema que la 06-05 y la 08-03 tocan. Clasifica sus proyectos en tres niveles: sandbox (experimental), incubating (uso real en producción, comunidad creciente) y graduated (maduro, gobernanza establecida, múltiples empresas dependiendo de él).

Qué significa para tus decisiones. Que un proyecto sea graduated es una señal razonable de que no va a desaparecer y de que no depende de una sola empresa —el riesgo de "proyecto abandonado" o "cambio de licencia" baja mucho—. Que sea sandbox significa lo contrario: interesante, posiblemente excelente, pero adoptarlo en producción es apostar. Esa distinción es un criterio directo para la pregunta "¿quién mantiene esto?" que la 08-03 propone antes de meter cualquier herramienta en tu pipeline.

Qué no significa. No es un sello de calidad técnica ni de que lo necesites. El catálogo de la CNCF —el famoso mapa con cientos de logotipos— se usa a menudo como lista de la compra, y es exactamente el uso equivocado: es un catálogo de piezas para problemas que la mayoría de los equipos no tienen.

OpenSSF (Open Source Security Foundation). Es donde vive buena parte del trabajo sobre seguridad de la cadena de suministro que aplicaste en la 04-03 y la 07-05: Sigstore, el marco SLSA, los scorecards de proyectos, guías de buenas prácticas. Si esa parte del curso te interesó, es el ecosistema al que seguir.

Linux Foundation. El paraguas de las dos anteriores y de muchos otros proyectos. También el emisor de una familia de certificaciones que la 08-04 valorará con detalle.

KubeCon + CloudNativeCon es el evento grande del ecosistema CNCF: miles de asistentes, decenas de pistas paralelas, y un peso comercial considerable —una parte de las charlas son, con mejor o peor disimulo, presentaciones de producto—. Las charlas se graban y se publican, lo que tiene una consecuencia importante para tu decisión: si vas por las charlas, no hace falta ir.

DevOpsDays es un formato distinto y, para la mayoría, más útil: eventos locales, de uno o dos días, organizados por comunidades en muchas ciudades, con precios accesibles y un formato que incluye open spaces —sesiones sin ponente donde los asistentes proponen los temas y se discuten en grupo—. Ahí es donde de verdad se comparte lo que no se cuenta en una charla: los fracasos, los costes reales, las migraciones que salieron mal.

FOSDEM, en Bruselas, es gratuito, enorme y centrado en software libre, con salas dedicadas por proyecto. Es el evento con mejor relación conocimiento/precio que existe, y también el más caótico.

Meetups locales. Grupos de decenas de personas, mensuales, en tu ciudad. Su valor no está en el nivel técnico medio de las charlas —variable— sino en que son la red profesional real de tu mercado laboral. La gente que decide contrataciones en las empresas de tu ciudad está ahí.

Por qué el pasillo vale más que las charlas. Las charlas están grabadas, pulidas y presentan la versión que quedó bien. La conversación de pasillo es donde alguien te dice "nosotros probamos eso y lo quitamos a los seis meses, te cuento por qué". Ese es el contenido que no existe en ningún otro formato, porque nadie sube a un escenario a contar que su plataforma interna no la usa nadie.

Regla práctica para aprovechar un evento: elige tres charlas que quieras ver de verdad, ignora el resto (las verás grabadas si acaso), y dedica el tiempo restante a hablar con gente. Prepara una pregunta concreta sobre tu propio sistema y hazla veinte veces a veinte personas distintas. Volverás con veinte respuestas contradictorias, que es exactamente el material que necesitas para desarrollar criterio.

Existe un ecosistema hispanohablante activo: grupos locales de Kubernetes y de Docker en las principales ciudades de España y Latinoamérica, comunidades de AWS y de otras nubes con capítulos regionales, DevOpsDays en varias ciudades hispanohablantes, canales de Telegram y Discord por tecnología, y una producción creciente de contenido técnico en español.

Por qué merece la pena participar en las dos lenguas, no elegir una:

• En inglés está el volumen y la fuente. La documentación, las issues, los RFC y la mayor parte de la respuesta experta están ahí. Renunciar al inglés es renunciar a la mitad larga del conocimiento, y la barrera es mucho menor de lo que parece: el inglés técnico escrito es un subconjunto pequeño y muy repetitivo del idioma. Se aprende leyendo issues.
• En español está el contexto de tu mercado. Cómo son las empresas de tu país, qué se paga, qué exige tu normativa, cómo son los procesos de contratación. Nada de eso está en r/devops.
• Y hay una asimetría que te favorece: en español hay mucho menos contenido de calidad. Escribir en español sobre lo que ya sabes —lo que has construido en el módulo 7, por ejemplo— tiene mucha más probabilidad de ser leído y de destacar que hacerlo en inglés, donde compites con miles de personas. Es la vía más rápida a la visibilidad profesional que la 08-04 mencionará.

Esta sección es la más práctica de la lección. La diferencia entre una pregunta ignorada y una respondida en diez minutos casi nunca es la dificultad del problema: es cuánto trabajo le ahorras a quien responde.

Veamos un fallo real del curso. En la 07-03 desplegabas por digest y varios laboratorios tropezaban con lo mismo: el cd.yml se dispara con workflow_run, el CI pasó en verde, pero el despliegue no llega a ejecutarse o falla al autenticarse contra AWS.

Asunto: No me funciona el deploy

Hola, tengo un workflow de GitHub Actions para desplegar a AWS y no funciona. El CI pasa bien pero el deploy no. He probado de todo y no sé qué hacer. ¿Alguien ha tenido este problema? Gracias.

Por qué nadie va a responder:

• No hay error. "No funciona" describe una emoción, no un comportamiento. ¿No se dispara? ¿Se dispara y falla? ¿Falla en qué paso?
• No hay código. Nadie puede razonar sobre un YAML que no ve.
• No hay versiones ni entorno. ¿Runner alojado o propio? ¿Qué versión de las acciones? ¿Repositorio público o privado? ¿Hay un entorno con revisores de por medio?
• "He probado de todo" no aporta nada y además es falso, y quien responde lo sabe. Lo que consigue es que la primera sugerencia razonable —que probablemente no has probado— parezca una pérdida de tiempo para ambos.
• El asunto no permite buscar. Dentro de un año, nadie con tu mismo problema encontrará este hilo.

Asunto: workflow_run no dispara el workflow de despliegue cuando el CI se ejecuta desde un PR de un fork

Contexto. Tengo dos workflows en un repositorio privado: ci.yml (se ejecuta en push y pull_request) y cd.yml, que debe ejecutarse cuando el CI termina correctamente en main. El objetivo es desplegar a ECS el mismo digest de imagen que el CI publicó, sin reconstruir.

Comportamiento esperado. Al hacer merge a main, el ci.yml termina en verde y el cd.yml arranca.

Comportamiento real. El ci.yml termina en verde (run #482), pero el cd.yml no aparece en la pestaña de Actions. No hay ejecución fallida: no hay ejecución en absoluto.

Entorno.

• Repositorio privado, organización con plan Team.
• Runners alojados por GitHub, ubuntu-latest.
• actions/checkout@v4, aws-actions/configure-aws-credentials@v4 (ambas fijadas por SHA).
• Ambos workflows están en main.

Disparador del cd.yml:

on:
  workflow_run:
    workflows: ["CI"]
    types: [completed]
    branches: [main]

jobs:
  desplegar:
    if: ${{ github.event.workflow_run.conclusion == 'success' }}
    runs-on: ubuntu-latest
    environment: produccion

Qué he comprobado ya:

1. El name: del workflow de CI es exactamente CI (verificado en el fichero, no en la interfaz).
2. El ci.yml que terminó en verde se ejecutó sobre main — lo confirma la interfaz de la ejecución.
3. El entorno produccion existe y tiene un revisor asignado; con un workflow_dispatch manual, el cd.yml sí se ejecuta y espera aprobación correctamente. Así que el problema parece estar en el disparador, no en el despliegue.
4. He mirado si el fallo era de permisos del token, pero no llega a haber ejecución, así que descarto esa vía.

Hipótesis actual. Que branches: [main] en workflow_run filtre por la rama de la ejecución del CI y no por la rama de destino del merge, y que en mi caso no coincidan. No he encontrado confirmación de esto en la documentación.

La pregunta concreta: ¿sobre qué rama se evalúa exactamente el filtro branches en un disparador workflow_run? ¿Y hay alguna forma de verificar por qué un workflow_run no se disparó, dado que no queda ningún registro?

Por qué esta se responde:

El efecto secundario más útil: escribir la pregunta buena resuelve el problema sin llegar a publicarla en un porcentaje muy alto de los casos. El acto de tener que enunciar qué esperabas, qué pasó y qué descartaste es un método de depuración. Cuando alguien te diga "escribe el problema como si fueras a publicarlo", no te está dando largas: te está dando la técnica.

• Un problema por pregunta. Las preguntas con tres problemas encadenados no se responden.
• Pega texto, no capturas de pantalla, salvo que el problema sea visual. El texto se busca, se cita y se lee en el móvil.
• Recorta el log a lo relevante, pero incluye las líneas de alrededor. Un error suele tener su causa cinco líneas antes.
• Publica en un solo sitio a la vez. Preguntar simultáneamente en Slack, el foro y Stack Overflow desperdicia el tiempo de tres personas.
• Vuelve y cierra el hilo. Si lo resuelves —tú o alguien—, escribe la solución. Un hilo abandonado con "ya lo arreglé, gracias" es una crueldad con quien llegue en el futuro con tu mismo problema.

La creencia extendida es que hay que ser experto para contribuir a un proyecto abierto. Es falsa, y creerla te cuesta la vía de aprendizaje más rápida que existe.

Por qué contribuir enseña tan rápido: te obliga a entender un sistema real que no escribiste tú, con estándares de calidad que no puedes negociar, y recibes revisión de personas que saben más que tú, gratis. No existe otra forma de conseguir eso.

Cinco formas de contribuir sin ser experto, ordenadas por facilidad:

1. Reproducir issues. Un mantenedor recibe "esto no funciona" sin versiones y sin ejemplo. Alguien que coja esa issue, la reproduzca en un repositorio mínimo, confirme en qué versiones ocurre y lo escriba en un comentario ha hecho la mitad del trabajo de arreglarla. Es lo que más agradecen los mantenedores y casi nadie lo hace. Y para ti es un ejercicio de depuración con solución conocida al final.

2. Documentación. Acabas de recorrer un curso completo tropezando con cosas mal explicadas. Esa perspectiva de recién llegado es un activo que se pierde en semanas: quien lleva dos años en un proyecto ya no ve qué falta. Arreglar un ejemplo que no funciona, añadir el paso que faltaba, aclarar una frase ambigua: todo eso son PRs pequeños y bienvenidos.

3. Ejemplos. Muchos proyectos tienen un directorio examples/ con lo básico. Un ejemplo real de integración —cómo usar esa herramienta dentro de un workflow de GitHub Actions, por decir algo que ahora sabes hacer— es una contribución de alto valor y bajo riesgo.

4. Traducciones. Si el proyecto tiene documentación traducida, hay hueco en español casi siempre. Es una contribución que no requiere entender el código a fondo y que sirve a mucha gente.

5. Revisar PRs de otros. No hace falta permiso para leer un PR abierto y comentar. Probarlo y decir "lo he aplicado en mi entorno y funciona / falla con esto" es una revisión útil, y leer los PRs de un proyecto es la mejor forma de aprender cómo se escriben las cosas ahí.

El sitio por donde empezar: el proyecto que ya usas y con el que ya has tropezado. La motivación de arreglar algo que te molestó a ti es la única que aguanta el primer PR rechazado. Busca las etiquetas good first issue o help wanted, lee el CONTRIBUTING.md entero antes de tocar nada, y empieza pequeño de verdad.

Una advertencia honesta: contribuir es lento y a veces frustrante. Los PRs se quedan sin revisar durante semanas, los mantenedores están saturados y trabajan gratis, y a veces tu propuesta se rechaza por razones de dirección del proyecto que no conocías. Nada de eso es personal. Si buscas gratificación rápida, esta no es la vía; si buscas aprender de verdad cómo se construye software que otros usan, no hay mejor.

El término "cargo culto" viene de la práctica de imitar la forma de algo sin entender su función. En esta disciplina es endémico: gente que copia la estructura del pipeline de una empresa grande sin tener ni sus problemas ni sus recursos.

Tiene marcadores igual de identificables:

• Declara el contexto sin que se lo pidan: "en un equipo de ocho, con despliegues diarios y sin guardias formales…".
• Menciona lo que costó: "funcionó, pero nos comió dos semanas y tuvimos que formar a todo el equipo".
• Incluye el fracaso: "lo intentamos primero con X y lo quitamos porque…". Quien cuenta lo que quitó ha operado el sistema de verdad.
• Distingue lo que sabe de lo que supone: "no lo he probado en esa versión, pero debería…".
• Responde con una pregunta antes de recomendar nada. La primera respuesta de la gente que sabe suele ser "¿cuánta gente sois y qué falla ahora mismo?".

El riesgo de esta lección es que la conviertas en una lista de suscripciones. El resultado sería la sensación permanente de ir por detrás, que es el estado de ánimo más común y más inútil de la profesión.

Una dieta que funciona:

• Profundidad, semanal. Una cosa larga y de fondo: un capítulo del plan de la 08-01, un post-mortem público, un RFC. 45 minutos. Es lo único de esta lista que produce criterio.
• Actualidad, diaria y limitada. Quince minutos como techo, y solo de la herramienta que usas en producción: sus notas de versión, su changelog, sus avisos de seguridad. Eso es todo lo que necesitas saber al día.
• Radar, semanal. Una pasada por HN o r/devops o el boletín que sea, con una regla explícita: enterarse de que algo existe no es una tarea pendiente. Anótalo en una lista de "existe" y sigue.
• Comunidad, cuando la necesites. Preguntar y responder cuando toque; no vivir ahí.
• Y una regla de descarte: si llevas seis meses viendo un nombre y nunca ha resuelto un problema tuyo, bórralo de tu radar. Volverá si importa.

Lo que hay que interiorizar del ciclo del hype: las herramientas que de verdad importan siguen ahí dentro de cinco años, y las aprenderás entonces con mejor documentación, más ejemplos y menos aristas. Llegar tarde a una herramienta buena cuesta poco; llegar pronto a una mala cuesta una migración.

Este es el único apartado de la lección donde un error tiene consecuencias serias y potencialmente legales.

Cuando pides ayuda, pegas logs. Y los logs de un pipeline contienen, con más frecuencia de la que la gente cree:

• Credenciales. Tokens en URLs, cabeceras Authorization, cadenas de conexión con contraseña, claves de acceso en variables de entorno volcadas por un env de depuración.
• Identificadores de infraestructura. IDs de cuenta de AWS, ARNs, nombres de bucket, endpoints de RDS, IPs internas, ARNs de rol de OIDC. Individualmente parecen inocuos; juntos son un mapa para quien quiera atacarte.
• Datos personales. Un log de un test de integración puede llevar nombres, teléfonos y correos reales si alguien pobló el entorno de pruebas con un volcado de producción —práctica más común de lo admisible—.
• Información comercial. Nombres de clientes en rutas, en nombres de rama o en identificadores de proyecto.

La 04-03 te enseñó el mecanismo defensivo: los secretos se enmascaran en los logs del CI, se rotan cuando se exponen, y Gitleaks los detecta en el repositorio. Pero ninguna de esas defensas actúa cuando copias y pegas un log en un foro. El enmascarado de GitHub Actions solo cubre los valores registrados como secretos en ese repositorio, no un token que un comando imprimió por su cuenta ni un ARN que nunca fue secreto.

Protocolo antes de publicar cualquier log o fragmento de configuración:

1. Anonimiza de forma consistente. Sustituye por marcadores evidentes (<ID_CUENTA>, arn:aws:iam::<CUENTA>:role/<ROL>, empresa.example.com). Consistente significa que el mismo valor real siempre sea el mismo marcador; si no, el problema deja de ser reproducible.
2. No inventes valores plausibles. Un ARN falso pero verosímil puede pertenecer a otra empresa de verdad. Usa example.com y <PLACEHOLDER>, que existen precisamente para esto.
3. Recorta antes de anonimizar, no después. Cuanto menos texto publiques, menos hay que revisar.
4. Léelo entero una vez más antes de pulsar enviar, buscando específicamente: password, token, key, secret, Authorization, Bearer, números de doce dígitos y direcciones de correo.
5. Si dudas, no lo publiques. Describe el error en palabras.
6. Y si publicas algo por error: rota el secreto inmediatamente y después borra el mensaje. En ese orden. Borrar no deshace: el contenido puede estar en cachés, en clientes de escritorio, en correos de notificación y en archivos de terceros. La única acción efectiva es invalidar la credencial. Lo mismo que la 04-03 decía de un secreto commiteado: no se borra, se rota.
7. Datos de clientes: nunca, bajo ninguna circunstancia. No es una cuestión de prudencia sino de normativa de protección de datos, y publicar en un foro un log con nombres y teléfonos de los clientes finales de Reservalia es un incidente reportable, exactamente como decía la restricción 4 del encargo de la 07-06.

Al revés también aplica. Si alguien publica un secreto en un canal, avísale en privado y de inmediato. No lo cites, no lo comentes en público y no lo uses. Es lo que esperarías que hicieran contigo.

• Preguntar antes de buscar. Una parte enorme de las preguntas ya está respondida en la primera página de resultados. Buscar primero no es solo cortesía: es más rápido que esperar respuesta.
• Buscar solo en Google y no en el issue tracker. Los problemas recientes de una herramienta están en sus issues antes que en ningún blog. Es el sitio donde menos gente mira y donde más suele estar.
• Confundir popularidad con adecuación. Que una herramienta domine las conversaciones significa que mucha gente habla de ella, no que resuelva tu problema. El módulo 6 entero era un ejercicio de separar esas dos cosas.
• Tomar el consenso de un espacio por el consenso del sector. Cada comunidad tiene su sesgo: el foro de una herramienta la defiende, r/devops se queja de todo, HN prefiere lo nuevo. Triangula siempre entre al menos dos espacios distintos.
• Consumir sin devolver nunca. Además de ser injusto con quien sostiene esto, es una pérdida propia: responder es lo que fija lo aprendido. La primera vez que expliques a alguien por qué se promociona por digest descubrirás qué partes no tenías claras.
• Pegar logs sin revisar. El error de esta lección con consecuencias reales. Protocolo del apartado 9, siempre, aunque tengas prisa. Sobre todo si tienes prisa.
• Consejo: guarda tus propias respuestas. Cuando resuelvas un problema difícil, escríbelo donde sea buscable —tu wiki, tu blog, el foro—. Tu yo de dentro de un año es el principal beneficiario, y de paso ayudas a desconocidos.
• Consejo: elige dos espacios y sé constante. Estar presente en dos comunidades durante un año construye reputación y contactos reales. Pasar por diez durante un mes no construye nada.
• Consejo: responde preguntas de nivel inmediatamente inferior al tuyo. Es donde más puedes ayudar y donde más aprendes, porque te obliga a articular lo que sabes de forma aproximada. No hace falta ser experto para ayudar a quien empezó hace tres meses.

Un compañero publica esto en el canal de la comunidad:

"Buenas! Tengo un problema con Terraform, cuando hago apply me da error de state lock y no puedo desplegar. Ya probé de todo, incluso borré el .terraform. Alguien sabe cómo arreglarlo? Urge, tenemos release hoy."

Reescríbela de forma que tenga probabilidad alta de respuesta. Inventa los detalles técnicos que hagan falta —siendo coherente con el stack del curso— y señala explícitamente qué información has añadido y por qué cada pieza importa. Añade también qué le dirías a tu compañero sobre dos cosas concretas de su mensaje original más allá de la falta de datos.

En un hilo sobre pipelines, alguien con muchos seguidores escribe:

"Regla de oro: nunca uses acciones de terceros en tus workflows. Escribe todo tú. Es lo que hacen todas las empresas serias, y cualquier otra cosa es una brecha de seguridad esperando a ocurrir."

Analiza el consejo: qué parte tiene fundamento real (conéctalo con la lección concreta del curso), qué señales de alarma presenta, qué contexto falta, y cómo reformularías el consejo para que fuera útil. Decide después qué harías tú en Mini-Reservalia y justifícalo.

Diseña tu propia dieta de información para los próximos seis meses, con un límite de tres horas semanales en total, y justifica cada elección en función de tu situación (puedes usar la de Nuria si prefieres un caso concreto: frontend/QA, quiere moverse hacia entrega y operación, trabaja en un equipo de tres). Después, elige una contribución concreta que podrías hacer en las próximas dos semanas a un proyecto que ya uses, y describe el primer paso exacto.

Solución 1

Pregunta reescrita:

Asunto: terraform apply falla con "Error acquiring the state lock" en DynamoDB tras cancelar una ejecución en GitHub Actions

Contexto. Terraform 1.7.5, backend S3 con bloqueo en DynamoDB. La infraestructura se aplica desde un workflow de GitHub Actions con autenticación por OIDC. Ayer cancelé manualmente una ejecución del workflow que se había quedado colgada en el apply.

Comportamiento real. Desde entonces, cualquier terraform apply —tanto desde el workflow como desde mi máquina— falla con:

Error: Error acquiring the state lock
Lock Info:
  ID:        9f3c1a2e-...
  Operation: OperationTypeApply
  Who:       runner@fv-az512-393
  Created:   2026-07-30 09:14:22 UTC

Qué he comprobado:

1. No hay ninguna otra ejecución del workflow en curso ni ningún compañero aplicando.
2. La entrada del lock sigue en la tabla de DynamoDB, con el ID que aparece en el error.
3. Borré el directorio .terraform local y ejecuté terraform init de nuevo: no cambia nada, lo cual tiene sentido porque el lock es remoto y no local.

Hipótesis. La cancelación del job mató el proceso sin darle ocasión de liberar el bloqueo, y quedó huérfano.

Preguntas concretas: (a) ¿Es terraform force-unlock <ID> la forma correcta de resolverlo, y qué riesgo tiene si el estado quedó a medio escribir? (b) ¿Cómo verifico antes de forzar que el estado remoto es consistente? (c) ¿Hay alguna forma de que el workflow libere el lock al cancelarse?

Qué información se ha añadido y por qué importa cada pieza:

Las dos cosas que le diría más allá de los datos:

1. "Ya probé de todo" y borrar .terraform son la misma señal: estaba probando acciones sin modelo del problema. Borrar el directorio local ante un bloqueo remoto no podía funcionar nunca, y saber por qué no podía funcionar es lo que le habría llevado directo a DynamoDB. Antes de probar, formular la hipótesis: "si el lock está en DynamoDB, ¿qué acción local podría afectarlo?".
2. "Urge, tenemos release hoy" es contraproducente. No acelera a nadie —quien responde lo hace gratis y en su tiempo— y sí transmite que puede recibir consejo de emergencia mal calibrado. Y aquí hay un riesgo concreto: la respuesta rápida es "haz force-unlock y ya", que en el peor caso —estado escrito a medias— corrompe el estado remoto y convierte veinte minutos de problema en un día entero. La prisa es exactamente la razón para preguntar bien, no para preguntar mal.

Solución 2

Qué tiene de fundamento. La preocupación es legítima y el curso la comparte: la 04-03 y la 07-05 tratan las acciones de terceros como una superficie de ataque real. Una acción es código ajeno ejecutándose en tu runner, con acceso al workspace, a las variables de entorno y potencialmente a tus credenciales. Un mantenedor comprometido, o una etiqueta de versión movida a un commit malicioso, ejecuta código en tu pipeline. Por eso la práctica del curso es fijar las acciones por SHA completo, no por etiqueta.

Señales de alarma, según la tabla del apartado 8.1:

• "Nunca": absoluto sin condición. La versión honesta tiene condiciones.
• "Es lo que hacen todas las empresas serias": apelación a autoridad no citada, más definición circular de "serio". Muchísimas organizaciones competentes usan acciones de terceros con controles.
• Sin contrapartidas: no menciona el coste de escribirlo todo tú, que es enorme y continuado.
• Sin escala declarada: no dice de qué tamaño de equipo habla.

Qué contexto falta. El decisivo. En una organización con equipo de plataforma dedicado, mantener acciones internas es viable y probablemente correcto: el coste se amortiza entre decenas de equipos y hay quien las mantenga. En un equipo de tres, escribir y mantener tu propia versión de actions/checkout, setup-node o configure-aws-credentials significa mantener código de infraestructura crítico sin nadie que lo revise ni lo actualice ante cambios de la plataforma. El resultado más probable no es más seguridad: es una acción propia sin mantener y con vulnerabilidades más antiguas que las del ecosistema. El consejo, aplicado sin contexto, empeora justo lo que pretende mejorar.

Falta además una distinción crítica que el consejo aplana: no todas las acciones de terceros son iguales. Las oficiales de GitHub (actions/*), las del proveedor de nube (aws-actions/*) y las de proyectos con gobernanza sólida no están en la misma categoría de riesgo que una acción de un repositorio personal con doce estrellas y sin commits en dos años.

Reformulación útil:

"Cada acción de terceros es código ajeno con acceso a tu pipeline. Antes de añadir una, mira quién la mantiene, con qué frecuencia y cuánta gente depende de ella. Fija siempre por SHA completo, nunca por etiqueta, y automatiza la actualización de esos SHA con Dependabot o Renovate para que fijar no signifique quedarse atrás. Da a cada job los permisos mínimos, para que una acción comprometida no pueda hacer mucho. Si tienes equipo de plataforma y muchos repositorios, plantéate mantener tus propias acciones internas para lo crítico; si sois pocos, escribirlas tú suele salir peor porque nadie las mantendrá."

Qué haría en Mini-Reservalia. Seguir usando acciones de terceros, con los controles que ya están implantados desde la 07-05: SHA completo en todas, permisos mínimos por job, Dependabot vigilando las actualizaciones y preferencia por acciones oficiales o con gobernanza clara. La restricción de equipo pequeño hace que escribirlo todo sea inviable, y el riesgo residual está mitigado por controles que sí puede sostener un equipo de tres. Eso, con su fecha y su condición de revisión, va al PIPELINE.md: si algún día hay equipo de plataforma, se reevalúa.

Solución 3

Dieta de Nuria, tres horas semanales:

Total: unas 2 h 45 min, con margen. Lo deliberadamente excluido: boletines diarios, Twitter/X y LinkedIn como fuente de aprendizaje, y cualquier cosa sobre herramientas que Nuria no usa. Con tres horas semanales, cada minuto en algo que no toca su trabajo es un minuto que no dedica a lo que sí.

Primera contribución, con primer paso exacto. Documentación de Playwright o de una acción de GitHub Actions relacionada con pruebas E2E.

Paso exacto para las próximas dos semanas: la próxima vez que siga la documentación de Playwright para configurar algo —paralelización, reintentos, informes en CI— y encuentre un ejemplo que no funciona tal cual, un paso que falta o una frase ambigua, anotarlo en el momento (esto es lo que se pierde: al día siguiente ya no lo recuerdas). Después, buscar el repositorio de la documentación del proyecto, leer su CONTRIBUTING.md entero, comprobar si ya hay una issue abierta sobre ello y, si no la hay, abrir un PR con la corrección mínima y una descripción de qué le pasó a ella siguiendo el documento.

Por qué este y no otro: es de riesgo bajo —un cambio de documentación no puede romper el producto de nadie—, aprovecha su perspectiva de recién llegada antes de que se le pase, y le enseña el flujo completo de contribución (fork, rama, PR, revisión, cambios pedidos, merge) sobre un cambio trivial. La segunda contribución, ya con el flujo conocido, puede ser más ambiciosa.

La diferencia entre quien se queda tres días bloqueado y quien resuelve en dos horas casi nunca es el talento. Es saber que el problema es de contexto, saber en qué espacio vive ese contexto y saber preguntar de forma que le ahorre trabajo a quien responde.

Lo esencial de esta lección:

• Hay tres tipos de problema y solo el de contexto exige comunidad. Los otros dos se resuelven leyendo y practicando, y confundirlos hace perder tiempo a todo el mundo.
• Cada espacio tiene su sesgo declarado: los foros oficiales son precisos sobre su herramienta y parciales sobre las demás; Stack Overflow es un archivo excelente y envejecido; Slack es rápido y efímero; Reddit mide frustración; HN mide novedad; LinkedIn es marketing. Triangula siempre.
• La verdad definitiva está en las issues y los RFC de los proyectos, que son la fuente peor indexada y más fiable que existe.
• Preguntar bien es una técnica con partes identificables: asunto buscable, esperado frente a real, mínimo reproducible, versiones, qué has probado con sus resultados, hipótesis propia y pregunta concreta. Y con frecuencia resuelve el problema antes de publicarla.
• Contribuir desde el primer día es posible y es la vía de aprendizaje más rápida: reproducir issues, documentación, ejemplos, traducciones, revisar PRs. No hace falta ser experto; hace falta haber tropezado.
• La higiene informativa se defiende con preguntas: ¿en qué caso no aplicaría?, ¿qué se pierde?, ¿de qué tamaño era tu equipo? Los absolutos, los argumentos de autoridad y los consejos sin contrapartidas son señales de alarma.
• Y nunca se publica un log sin revisarlo. Anonimizar de forma consistente, releer buscando credenciales y datos personales, y si algo se escapa: rotar primero, borrar después.

Los libros de la 08-01 te dan fundamento y las comunidades de esta lección te dan contexto. Falta la tercera pieza: las herramientas concretas que el curso rozó o dejó fuera y que resuelven problemas que ahora sabes reconocer —gestionar secretos fuera del repositorio, automatizar el canary que en la 03-04 configuraste a mano, validar políticas antes de aplicar infraestructura, medir la cadena de suministro con un marco de niveles—.

Eso es 08-03: Herramientas y Plugins Adicionales. Y se presenta por problema, nunca por moda: exactamente la higiene que acabas de aprender a aplicar a los consejos ajenos, aplicada ahora a las herramientas.