Sloučené PR do Launch Copy
Okou přečte pull requesty, které jste tento týden sloučili, ponechá ty, které jsou pro uživatele, napíše příspěvek o změnách a zveřejní ho na vašem blogu, vašem seznamu Resend a X v jednom běhu, jakmile schválíte návrh.
Co Okou dodává: příspěvek, e-mail a vlákno
Toto je skutečná aktualizace produktu Okou, publikovaná na okou.ai 20. července 2026, zobrazená přesně tak, jak vyšla: blogový příspěvek, stejná aktualizace jako newsletter a jako vlákno na X. Jeden běh napsal všechny tři z týdenních sloučených pull requestů.
Co je to automatizace changelogu?
Automatizace changelogu je praxe generování aktualizací produktu z práce, kterou váš tým skutečně sloučil, namísto psaní z paměti na konci týdne. Okou funguje jako agent uprostřed: čte sloučené pull requesty v GitHub, ponechává ty, které jsou viditelné pro uživatele, seskupuje je do témat, píše příspěvek do changelogu a publikuje ho na váš blog, do newsletteru Resend a do vlákna X v jednom běhu. Výsledkem je týdenní aktualizace produktu, která se vydává včas a říká to samé na všech kanálech.
Proč týdenní changelog zabere celý pátek
Páteční odpoledne. Tento týden bylo sloučeno třicet a něco pull requestů a někdo je musí proměnit v aktualizaci, kterou si lidé skutečně přečtou. Projdete seznam sloučení, odhadnete, které změny jsou pro uživatele viditelné, napíšete příspěvek, zkrátíte ho pro e-mail, zkrátíte ho znovu pro X a poté každou verzi vložíte do jiného nástroje. Je to stejné čtení třikrát a verze, která se objeví na X, obvykle říká něco mírně odlišného od té, která se objevila v doručené poště.
Jak Okou přemění týden sloučení na publikovaný changelog
Krok 1: Připojte své nástroje
Krok 2: Zeptat se Okou
Krok 3: Jděte dál
Integrace GitHub, Resend, X a Slack pro automatizaci changelogu
Tento pracovní postup čte z jednoho nástroje a zapisuje do tří. GitHub je jediným zdrojem pravdy o tom, co bylo dodáno; Resend a X jsou cíle; Slack je místo, kde návrh čeká na člověka. Každý konektor je udělen samostatně a omezen na to, co pracovní postup skutečně používá, takže přístup pro čtení k vašemu úložišti nikdy neznamená právo publikovat z vašeho účtu.
Integrace GitHub: co Okou čte k vytvoření changelogu
PovinnéOkou dotazuje požadavky na sloučení (pull requests) sloučené do repozitářů, které určíte ve svém okně, a pro každý z nich přečte název, tělo, štítky, čas sloučení, autora a cesty změněných souborů. Těchto pět signálů je to, co odděluje změnu orientovanou na uživatele od interního refaktoringu: štítek poznámky k vydání je nejsilnější, změněné cesty zachytí ty, které nikdo neoznačil, a tělo dodává detaily, které název vynechává. V tomto pracovním postupu je integrace GitHub pouze pro čtení. Okou neotevírá žádné problémy, netlačí žádné commity a neupravuje žádné požadavky na sloučení. Nasměrujte jej na více než jeden repozitář a přečte je všechny v jednom průchodu, takže rozdělený frontend a backend stále produkují jeden changelog.
Integrace Resend: newsletter, který posílá Okou
PovinnéOkou čte vaše publikum Resend, takže může oslovit to, které pojmenujete jménem, spíše než ID, a poté vytvoří a odešle kampaň: předmět, preheader, tělo HTML a alternativu v prostém textu. Po odeslání přečte výsledek a nahlásí, kolik zpráv bylo doručeno, odloženo a vráceno, proto se zpráva a kampaň nikdy neshodují. Povolení k odesílání je uděleno odděleně od přístupu ke čtení publika a Okou nikdy nepřidává, neodstraňuje ani neexportuje kontakty.
Integrace X: vlákno, které Okou zveřejňuje
PovinnéVlákno je napsáno pro X, nikoli zkráceno z blogového příspěvku: jeden příspěvek na téma, úvod, který říká, co se změnilo, a závěrečný příspěvek, který odkazuje zpět na celý text. Okou zveřejňuje každý záznam jako odpověď na předchozí, takže vlákno drží pohromadě, a před zveřejněním kontroluje délku, místo aby nechal příspěvek zkrátit. Přístup pro zápis je omezen na účet, který připojíte, a zveřejnění vlákna je vše, co dělá. Okou nečte vaši časovou osu, vaše zmínky ani vaše přímé zprávy.
Integrace Slack: kde návrh čeká na schválení
VolitelnéSlack je volitelný a své místo si zaslouží v kroku schválení. Okou zveřejní celý návrh v kanálu, který pojmenujete, včetně textu blogu, předmětu e-mailu a každého příspěvku ve vlákně, a poté se zastaví. Nic se nezveřejní, dokud někdo neodpoví schválením, a vy můžete požádat o přepsání ve stejném vlákně a získat aktualizovaný návrh na místě. Přeskočte Slack a pracovní postup se stále spustí od začátku do konce; návrh se vrátí tam, kde jste spuštění začali.
Okou vs. ruční psaní vs. generátor changelogu
Automatizace protokolu změn se dělí na dva problémy: rozhodování, co stojí za oznámení, a doručení oznámení do každého kanálu. Většina nástrojů řeší jeden z nich.
Psaní ručně
Někdo si přečte seznam sloučení, rozhodne, co je důležité, napíše příspěvek a dvakrát ho přepíše pro e-mail a X. Úsudek je dobrý a text je v souladu se značkou, ale stojí to stejných 90 minut každý týden a je to první věc, která se v rušném týdnu vynechá.
Generátor changelogu
Názvy commitů nebo pull requestů se automaticky shromažďují na stránce s poznámkami k vydání. Nikdy nezmešká sloučení, ale publikuje názvy spíše než témata, nedokáže rozlišit refaktorování od funkce a zastaví se na jednom cíli.
Workflow changelogu Okou
Okou čte stejné sloučení, aplikuje vaše pravidlo pro to, co se počítá jako uživatelsky viditelné, zbytek seskupí do témat a píše text pro každý kanál. Blog, Resend a X publikují z jednoho schváleného návrhu v jediném běhu a běh hlásí, co zadržel a proč.
Tipy pro lepší výsledky
Často kladené otázky
Jak automatizovat changelog z požadavků na stažení GitHub?
Připojte GitHub k Okou a dejte mu plán nebo spouštěč vydání. Okou přečte pull requesty sloučené ve vašem okně, filtruje je podle vašeho pravidla pro to, co se počítá jako uživatelsky orientované, seskupí přeživší do témat a napíše příspěvek do changelogu. Přidejte Resend a X a stejné spuštění ho publikuje i na tyto kanály.
Jak Okou rozhoduje, která sloučení jsou viditelná pro uživatele?
Podle pravidla, které mu dáte, aplikovaného na čtyři signály: štítek poznámky k vydání, změněné cesty k souborům, název žádosti o stažení a tělo. Štítek je nejsilnější signál a ten, na kterém se většina týmů standardizuje. Vše, co Okou vyloučí, je uvedeno ve zprávě o spuštění s důvodem, takže špatné volání je viditelné, nikoli tiché.
Může být jeden návrh publikován do newsletteru a na X současně?
Ano. Okou napíše témata jednou, poté je přizpůsobí pro každý kanál: celý blogový příspěvek, e-mail v délce doručené pošty s předmětem a preheaderem a vlákno s jedním příspěvkem na téma. Všechny tři se publikují v rámci stejného spuštění ze stejného schváleného návrhu, takže se fakta nemohou mezi kanály lišit.
Publikuje se něco bez mého schválení?
Ne, pokud o to nepožádáte. Výchozí tok zveřejní koncept v kanálu a čeká. Můžete ho schválit, požádat o přepsání ve stejném vlákně, nebo ho zrušit. Pokud byste raději, aby se zveřejnil bez dozoru, uveďte to ve výzvě a Okou přeskočí krok schválení.
Jaké nástroje potřebuje automatizace changelogu?
GitHub je vyžadován jako zdroj toho, co bylo odesláno. Resend a X jsou vyžadovány pro dvě publikační destinace. Slack je volitelný a používá se pouze pro krok schválení; bez něj se návrh vrátí tam, kde jste spustili běh.
Jaká oprávnění tento pracovní postup potřebuje?
GitHub potřebuje přístup pro čtení k repozitářům, ze kterých publikujete. Resend potřebuje oprávnění k odesílání a přístup pro čtení publika. X potřebuje oprávnění k zápisu na účtu, který zveřejňuje vlákno. Slack, pokud jej používáte, musí zveřejňovat v kanálu schválení. Každý konektor udělujete samostatně v Okou a zrušení jednoho ponechá ostatní nedotčené.
Může Okou vytvořit jeden changelog z několika repozitářů?
Ano. Pojmenujte každý repozitář ve výzvě a Okou je přečte v jednom průchodu, poté seskupí změny podle chování, které mění, spíše než podle toho, z jakého repozitáře pocházejí. Rozdělený frontend a backend stále vytváří jeden příspěvek.
Mohu to spustit na značce vydání namísto týdenního plánu?
Ano. Vytvořte automatizaci, která spustí pracovní postup, když je vydání označeno v GitHub. Okou pak sestaví changelog z pull requestů v tomto vydání namísto časového okna a zbytek běhu je identický.
Zveřejněte changelog tohoto týdne
Propojte GitHub, Resend a X, poté použijte týdenní výzvu k zobrazení celého běhu: skenování, seskupení, návrh, schválení, publikování.
