Release notes desde git commits y PR

La automatización reemplaza el ritual manual de «sentarse el viernes y anotar todo lo que se hizo durante el sprint» por un pipeline reproducible. El agente de IA lee el historial del repositorio, separa lo relevante del ruido técnico y genera un borrador estructurado que el ingeniero o el product manager revisa en 5-10 minutos en lugar de escribirlo desde cero.

El proceso paso a paso

1. Recopilación de datos. El agente se conecta al repositorio (GitHub, GitLab u otro Git-hosting) y extrae los commits y los merged pull requests desde el último release — por tag, fecha o número de rama.
2. Normalización. Las descripciones de PR, los títulos, labels, las referencias a issues y los nombres de autores se agrupan en una estructura unificada. Los commits técnicos (chore, refactor, test) se marcan, pero no se eliminan.
3. Clasificación. el modelo de lenguaje distribuye los cambios en categorías: nuevas funciones, correcciones, breaking changes, mejoras internas. La lógica de clasificación se basa en conventional commits, labels o la semántica de los títulos de PR.
4. Resumen para audiencias. El agente genera tres variantes: técnica (para desarrolladores, con referencias a PR), corta (para la dirección — qué cambió para el negocio) y para clientes (sin términos internos, con enfoque en el beneficio).
5. Borrador para revisión. El resultado llega a Slack, Notion o como pull request con la plantilla CHANGELOG.md — el ingeniero edita y publica.
6. Publicación. Paso opcional: publicación automática en el canal de release, actualización del widget de changelog in-app, envío de email a los clientes.

Lo que la automatización NO hace

• No reemplaza al tech lead. La decisión sobre qué considerar un breaking change o un major release corresponde al ser humano. El agente solo propone la clasificación.
• No redacta textos de marketing desde cero. La variante para clientes es un borrador estructurado, no un launch post listo con posicionamiento y CTA.
• No analiza la calidad del código. Métricas como test coverage, comentarios de seguridad o decisiones de arquitectura no se incluyen en las release notes.

El pipeline está construido sobre llamadas al Git-hosting y un único procesamiento LLM. La solución custom-code se despliega como cron-job, paso de CI o trigger manual — todo depende del ritmo de releases del equipo.

Flow técnico

El agente opera en tres etapas: extracción del historial, procesamiento LLM, entrega del borrador. Entre etapas, los datos se transfieren en JSON estructurado, lo que simplifica la depuración y permite añadir reglas manuales sin reescribir el prompt.

Pasos de implementación

1. Definición del rango de release. El script recibe dos anclas — la anterior y la actual. Opciones: el último tag (git describe --tags), fecha, nombre de rama o ID de deploy de CI. Para equipos sin tags se usa «todo lo que se mergeó en main en N días».
2. Consulta al Git-hosting. A través de REST o GraphQL API (GitHub, GitLab, Bitbucket) se extraen los commits y pull requests del rango. Para cada PR se recopilan: título, descripción, labels, autor, issues relacionados, merge timestamp.
3. Preprocesamiento. Los commits duplicados (el mismo PR squashed) se colapsan. Los conventional commits se parsean — si el equipo usa el formato feat:, fix:, chore:, el agente hereda la clasificación. Sin conventional commits, el LLM resuelve por contexto.
4. Llamada LLM. El LLM recibe una lista estructurada de PR y un prompt con instrucciones: qué categorías, qué audiencias, tono, longitud. La respuesta es un JSON con arrays features, fixes, breaking, internal.
5. Renderizado. El motor de plantillas (Mustache, Jinja o el mismo LLM en un segundo paso) convierte el JSON en un borrador markdown según el formato del equipo — CHANGELOG.md, página de Notion, Slack-message, in-app modal.
6. Entrega. El borrador se envía a través de webhook al canal de revisión — la opción estándar: pull request con el cambio de CHANGELOG.md, para que el ingeniero vea el diff y comente. Alternativa — drafts en Notion o Linear release.

Componentes de la solución

Matices y particularidades

• Procesamiento de rangos extensos. Para releases con cientos de PR, los datos se dividen en batches — el LLM procesa las partes y luego el agregador consolida el resultado. De lo contrario, el contexto se desborda y la calidad de clasificación disminuye.
• Estabilidad del formato. El prompt requiere JSON con esquema estricto, no markdown libre. Esto proporciona un resultado predecible para el renderizado y parseo automáticos.
• Memoria de estilo. Si el equipo mantiene CHANGELOG.md, el agente recibe las entradas anteriores como ejemplos few-shot — las nuevas release notes se escriben en el mismo tono.
• Reglas personalizadas. La lista de PR-labels que deben ignorarse (por ejemplo, internal, dependabot), se define en la configuración. El LLM no decide esto por sí solo.

La versión básica de la automatización se despliega en 2-5 días hábiles con un solo ingeniero — de ahí la designación de complejidad «weekend». La complejización posterior depende de los requisitos del equipo.

Datos y accesos

• Git-hosting con acceso a la API. GitHub, GitLab, Bitbucket o self-hosted — se necesita un token con permisos de lectura del historial y de los PR en los repositorios necesarios.
• Política de releases. El equipo utiliza tags, semantic versioning o al menos un merge regular en main. Sin un punto de referencia estable, el rango hay que definirlo manualmente cada vez.
• Acceso al canal de entrega. Slack webhook, Notion API-token, permiso para crear PR en el repositorio — depende del formato de publicación elegido.
• Clave API del modelo de lenguaje a través de Anthropic o plataforma wrapper.

Preparación del equipo

• Un ingeniero que mantiene el script y gestiona los accesos — tech lead o DevOps.
• Acuerdo sobre las categorías de release notes: qué se considera feature, qué fix, qué PR-labels ignorar. Sin esto, la clasificación LLM acertará, pero no siempre conforme a las expectativas.
• Una plantilla CHANGELOG.md o un formato equivalente en Notion/Linear — aunque sea borrador.

Plazos

• Versión Weekend (2-5 días): un repositorio, una audiencia (técnica), publicación en Slack o CHANGELOG.md a través de PR. Mínimo de prompts, formato estándar.
• Ampliación (hasta 2 semanas): varios repositorios en monorepo o arquitectura multiservicio, tres variantes de texto (tech/mgmt/customer), integración con Notion y widget de in-app changelog.

Para los equipos con un workflow no estándar (feature flags, release trains, varios productos en un mismo repositorio) conviene reservar tiempo adicional para definir la lógica del rango.