Hoe publiceert u release notes zonder ze vanaf nul te schrijven?
Een AI werknemer voor release notes die bij elke release elke PR leest die sinds de vorige is samengevoegd, ze groepeert per gebied, leesbare notities schrijft en een changelog PR opent voor een aangewezen persoon om te beoordelen en samen te voegen.
×
Release notes schrijven betekent alles teruglezen wat sinds de vorige release is samengevoegd, bepalen wat een lezer belangrijk vindt, en het verwoorden voor iemand die niet bij de PR's betrokken was. Het is het soort taak dat gemakkelijk wordt uitgesteld, waardoor de changelog achterop raakt of een samenvatting van één regel krijgt die niemand helpt. De gangbare oplossingen zijn onvolledig. Een automatisch gegenereerde lijst met PR titels is accuraat maar onleesbaar: interne bewoordingen, geen groepering, elke afhankelijkheidsverhoging inbegrepen. Ze met de hand schrijven is beter maar traag, en het concurreert met het daadwerkelijk uitbrengen. Hoe dan ook komen de notities na de release, als ze al komen.
De AI werknemer voor release notes wordt geactiveerd bij elke release. Wanneer er een tag wordt gepusht, start hij een geïsoleerde run in uw eigen omgeving met de rechten die u instelt voor de repository. Hij zoekt de vorige release op, leest elke PR die ertussen is samengevoegd, groepeert ze per gebied, schrijft notities in gewone taal en opent een PR op de changelog. Een aangewezen persoon beoordeelt en voegt samen. Hij publiceert, tagt of kondigt nooit iets aan.
Zie precies hoe het werk wordt gedaan.
Geactiveerd bij elke release
Een ondertekende GitHub webhook wijst naar het project. Een gepushte tag of een gepubliceerde release activeert hem, en elke activering start een nieuwe run in uw eigen omgeving, voorzien van de nieuwe tag. Eén release komt overeen met één run, dus er wordt niets overgedragen tussen releases.
Draagt het notitiedraaiboek mee
Hoe u release notes schrijft, reist met de AI werknemer mee als skills en geheugen: hoe wijzigingen per gebied worden gegroepeerd, welke labels louter intern werk aanduiden dat wegvalt, de toon waarin de changelog is geschreven, en de opmaak die het bestand verwacht. Wanneer u aanpast hoe een onderdeel leest, legt u het vast en volgt hij het bij de volgende release.
Maakt verbinding met de repository met de rechten die u instelt
Hij lokaliseert de vorige releasetag en het commitbereik tot de nieuwe; leest de titels, beschrijvingen, labels en auteurs van elke PR die in dat bereik is samengevoegd; en opent op GitHub een changelog PR met de opgestelde notities. Inloggegevens blijven in het geheugen, worden nooit naar schijf geschreven en worden nooit aan het model getoond.
Groepeert en schrijft, laat de ruis vallen
Hij groepeert de samengevoegde PR's per gebied en schrijft notities in gewone taal, waarbij hij intern geschuif en de ruis van afhankelijkheidsverhogingen laat vallen, zodat het resultaat leest voor iemand die niet bij de PR's betrokken was.
Stopt bij een changelog PR
Zijn uitvoer is een pull request op de changelog en niets meer. Hij publiceert, tagt of kondigt niets aan. Een aangewezen persoon beoordeelt de bewoordingen en voegt samen.
Draait in uw eigen omgeving
Elke release draait geïsoleerd binnen uw eigen infrastructuur. Hij leest de PR geschiedenis en stelt de notities op; alleen de changelogtak verlaat de omgeving, en uw data verlaat uw omgeving nooit.
Stelt een PR op, publiceert nooit
Hij opent een pull request op de changelog en stopt. Hij publiceert of kondigt de release nooit aan. Een aangewezen persoon beoordeelt de bewoordingen en voegt samen.
Lezen op de repo, alleen het concept schrijven
Hij leest PR titels, beschrijvingen, labels en auteurs, en zijn enige schrijfactie is de changelogtak die hij ter beoordeling opent. Hij wijzigt verder niets in de repository.
Inloggegevens blijven beschermd
De inloggegevens voor GitHub maken verbinding met de rechten die u instelt, blijven in het geheugen, worden nooit naar schijf geschreven en worden nooit aan het model of de logs getoond.
Alle regels zijn van u
De groeperingsregels, de labels om te laten vallen, de toon van de changelog en de rechten zijn van u, met versiebeheer en aangepast op uw voorwaarden, niet in het dashboard van een leverancier.
De changelog raakt niet langer achterop, en de notities die ter beoordeling komen, zijn al gegroepeerd en leesbaar in plaats van een ruwe lijst met PR titels. Beoordelaars bewerken de bewoordingen in plaats van uit de git geschiedenis te reconstrueren wat er is uitgebracht.
Elke release
Notities automatisch opgesteld uit de PR geschiedenis
Gegroepeerd
Wijzigingen gegroepeerd per gebied, met intern geschuif weggelaten
Menselijke beoordeling
De AI werknemer stelt op; het team is eigenaar van de bewoordingen
Onze gratis AI-audit laat zien waar AI kansen biedt voor uw bedrijf, welke risico's daarbij komen kijken, en zet meteen uw eerste AI werknemer aan het werk.
Hoe houden AI werknemers uw documentatie synchroon met de code?
Doorloopt dagelijks de samengevoegde code, herschrijft de documentatie die door die wijzigingen is geraakt, en opent één beoordeelbare pull request. Publiceren wacht op een merge door een mens.
×Hoe testen AI werknemers elke pull request voordat een mens deze beoordeelt?
Checkt elke pull request uit, draait de suite, beproeft de wijziging via de edge op een testdeploy, en plaatst het resultaat. Blijft weg van productie en laat de merge aan een persoon over.
×Hoe krijgt u een postmortem opgesteld op het moment dat een incident is opgelost?
Reconstrueert de incidenttijdlijn, zet die af tegen deploys en logpieken en opent een gestructureerde postmortem als een document PR. De AI werknemer stelt op, het team maakt af.
×