De los pull requests fusionados a un changelog publicado
Okou lee los pull requests que fusionaste esta semana, se queda con los que afectan al usuario, escribe el changelog y lo publica en tu blog, tu lista de Resend y X en la misma ejecución, en cuanto apruebas el borrador.
¿Qué es la automatización del changelog?
La automatización del changelog consiste en generar la actualización de producto a partir del trabajo que tu equipo fusionó de verdad, en lugar de escribirla de memoria al final de la semana. Okou actúa como el agente intermedio: lee los pull requests fusionados en GitHub, se queda con los que afectan al usuario, los agrupa por temas, escribe el changelog y lo publica en tu blog, en una newsletter de Resend y en un hilo de X en una sola ejecución. El resultado es una actualización semanal que sale puntual y dice lo mismo en todos los canales.
Por qué el changelog semanal se come un viernes
Viernes por la tarde. Esta semana se fusionaron treinta y tantos pull requests y alguien tiene que convertirlos en una actualización que la gente lea de verdad. Repasas la lista de merges, adivinas qué cambios afectan al usuario, escribes el post, lo recortas para el email, lo vuelves a recortar para X y pegas cada versión en una herramienta distinta. Es la misma lectura tres veces, y lo que acaba en X casi nunca dice exactamente lo mismo que llegó a la bandeja de entrada.
Cómo Okou convierte una semana de merges en un changelog publicado
Paso 1: Conecta tus herramientas
Paso 2: Pregúntale a Okou
Paso 3: Llévalo más lejos
Integraciones de GitHub, Resend, X y Slack para automatizar el changelog
Este flujo lee de una herramienta y escribe en tres. GitHub es la única fuente de verdad sobre lo que se lanzó; Resend y X son destinos; Slack es donde el borrador espera a una persona. Cada conector se concede por separado y se limita a lo que el flujo usa realmente, así que el acceso de lectura a tu repositorio nunca implica el derecho a publicar desde tu cuenta.
Integración con GitHub: lo que Okou lee para construir el changelog
ObligatorioOkou consulta los pull requests fusionados en los repositorios que indiques dentro de tu ventana y, de cada uno, lee el título, el cuerpo, las etiquetas, la hora del merge, el autor y las rutas de archivo modificadas. Esas cinco señales son las que separan un cambio de cara al usuario de una refactorización interna: la etiqueta de nota de release es la más fuerte, las rutas modificadas cazan los que nadie etiquetó y el cuerpo aporta el detalle que el título deja fuera. En este flujo la integración con GitHub es de solo lectura. Okou no abre issues, no hace commits y no edita pull requests. Apúntalo a más de un repositorio y los leerá todos en la misma pasada, de modo que un frontend y un backend separados siguen produciendo un único changelog.
Integración con Resend: la newsletter que envía Okou
ObligatorioOkou lee tus audiencias de Resend para poder dirigirse por nombre a la que indiques, en lugar de por ID, y después crea y envía la campaña: asunto, preencabezado, cuerpo HTML y alternativa en texto plano. Tras el envío vuelve a leer el resultado e informa de cuántos mensajes se entregaron, se aplazaron y rebotaron, que es la razón por la que el informe y la campaña nunca se contradicen. El permiso de envío se concede aparte del acceso de lectura a las audiencias, y Okou nunca añade, elimina ni exporta contactos.
Integración con X: el hilo que publica Okou
ObligatorioEl hilo se escribe para X, no se recorta del post: una publicación por tema, una de apertura que dice qué ha cambiado y una de cierre que enlaza al texto completo. Okou publica cada entrada como respuesta a la anterior para que el hilo se mantenga unido, y comprueba la longitud antes de publicar en lugar de dejar que una publicación se corte. El acceso de escritura se limita a la cuenta que conectes, y publicar el hilo es todo lo que hace. Okou no lee tu timeline, ni tus menciones, ni tus mensajes directos.
Integración con Slack: donde el borrador espera aprobación
OpcionalSlack es opcional y se gana su sitio en el paso de aprobación. Okou publica el borrador completo en el canal que indiques, incluidos el texto del blog, el asunto del email y todas las publicaciones del hilo, y ahí se detiene. No se publica nada hasta que alguien lo apruebe, y puedes pedir una reescritura en el mismo hilo y recibir el borrador actualizado en el sitio. Sin Slack el flujo sigue funcionando de principio a fin; el borrador vuelve allí donde iniciaste la ejecución.
Okou frente a escribirlo a mano y frente a un generador de changelogs
Automatizar el changelog son en realidad dos problemas: decidir qué merece anunciarse y hacer llegar ese anuncio a todos los canales. La mayoría de herramientas resuelve solo uno.
Escribirlo a mano
Alguien lee la lista de merges, decide qué importa, escribe el post y lo reescribe dos veces para el email y para X. El criterio es bueno y el texto suena a marca, pero cuesta los mismos 90 minutos cada semana y es lo primero que se cae en una semana ocupada.
Un generador de changelogs
Los títulos de commits o pull requests se recopilan solos en una página de notas de release. Nunca se salta un merge, pero publica títulos en lugar de temas, no distingue una refactorización de una función y se queda en un único destino.
El flujo de changelog de Okou
Okou lee los mismos merges, aplica tu regla sobre qué afecta al usuario, agrupa el resto por temas y escribe el texto de cada canal. Blog, Resend y X se publican desde un único borrador aprobado en una sola ejecución, y la ejecución informa de qué retuvo y por qué.
Consejos para mejores resultados
Preguntas frecuentes
¿Cómo se automatiza un changelog a partir de los pull requests de GitHub?
Conecta GitHub a Okou y dale un horario o un disparador de release. Okou lee los pull requests fusionados en tu ventana, los filtra con tu regla sobre qué afecta al usuario, agrupa los que quedan por temas y escribe el changelog. Añade Resend y X y la misma ejecución lo publicará también en esos canales.
¿Cómo decide Okou qué merges afectan al usuario?
Con la regla que le des, aplicada a cuatro señales: la etiqueta de nota de release, las rutas de archivo modificadas, el título del pull request y su cuerpo. La etiqueta es la señal más fuerte y la que la mayoría de equipos acaba estandarizando. Todo lo que Okou excluye aparece en el informe de la ejecución con su motivo, así que un criterio equivocado se ve en lugar de pasar desapercibido.
¿Se puede publicar un mismo borrador en la newsletter y en X a la vez?
Sí. Okou escribe los temas una vez y luego los adapta a cada canal: el post completo en el blog, el email con longitud de bandeja de entrada más asunto y preencabezado, y un hilo con una publicación por tema. Los tres se publican en la misma ejecución desde el mismo borrador aprobado, así que los hechos no pueden desviarse entre canales.
¿Se publica algo sin mi aprobación?
No, salvo que lo pidas. El flujo por defecto publica el borrador en un canal y espera. Puedes aprobarlo, pedir una reescritura en el mismo hilo o descartarlo. Si prefieres que se publique sin supervisión, dilo en el prompt y Okou se salta el paso de aprobación.
¿Qué herramientas necesita esta automatización del changelog?
GitHub es obligatorio como fuente de lo que se lanzó. Resend y X son obligatorios como los dos destinos de publicación. Slack es opcional y solo se usa en el paso de aprobación; sin él, el borrador vuelve allí donde iniciaste la ejecución.
¿Qué permisos necesita este flujo?
GitHub necesita acceso de lectura a los repositorios desde los que publicas. Resend necesita permiso de envío y acceso de lectura a las audiencias. X necesita acceso de escritura en la cuenta que publica el hilo. Slack, si lo usas, necesita poder publicar en el canal de aprobación. Cada conector se concede por separado en Okou, y revocar uno deja los demás intactos.
¿Puede Okou crear un solo changelog a partir de varios repositorios?
Sí. Nombra todos los repositorios en el prompt y Okou los leerá en la misma pasada, agrupando después los cambios por el comportamiento que modifican y no por el repositorio del que vienen. Un frontend y un backend separados siguen dando un único post.
¿Puedo ejecutarlo con una etiqueta de release en vez de un horario semanal?
Sí. Crea una automatización que inicie el flujo cuando se etiquete una release en GitHub. Okou construirá entonces el changelog con los pull requests de esa release en lugar de con una ventana de fechas, y el resto de la ejecución es idéntico.
Publica el changelog de esta semana
Conecta GitHub, Resend y X y usa el prompt semanal para ver la ejecución completa: revisar, agrupar, redactar, aprobar y publicar.