Release flow

Průběžná next-release nástěnka

Každý projekt má jednu průběžnou nástěnku příštího vydání, která sbírá všechno zamergované od posledního střihu — ve všech repozitářích vydání (nový release track bere všechny repozitáře navázané na projekt), v každém z jeho vlastní větve. Okno je přesné: v každém repozitáři běží od commitu, kterým v něm skončila jeho část minulého vydání, nikdy od odhadu podle data — a release stránka se na nástěnku skládá sama, jak okno roste.

Dělba práce je záměrná: AI píše prózu — hero, položky ✨ novinek, 🐛 oprav a 🔧 vylepšení — zatímco server počítá fakta: pás statistik, odkazy na PR, propojené nástěnky z toho, co skutečně sesbíral. Halucinovaný počet PR není možný, protože počet nikdy neputuje přes model. Odkazy na PR nesou svůj repozitář, takže se #123 dvou repozitářů nikdy nesmíchá.

Co stránka ukazuje

Hero, pás statistik a časová osa mergů; pak ✨ novinky, 🐛 opravy a 🔧 vylepšení — jedna položka na funkci s odkazy na PR (každý do svého repozitáře), nejvýš jedním screenshotem a až třemi odkazy na nástěnky; nakonec Made this sprint — portály na až 24 nástěnek, kterých se okno dotklo. Screenshot se vybírá z až 24 kandidátů: z obrazovek zachycených v okně a ze snímků z runnerů a uploadů na nástěnkách, kterých se okno dotklo, seřazených podle vizuální kvality, souvislosti s PR v okně a čerstvosti, bez téměř shodných duplikátů. Každý screenshot se na stránce objeví jen jednou: když si stejný vyberou dvě položky, zůstane té, jejíž PR a odkazované nástěnky odpovídají nástěnce, na které vznikl — při shodě vyhraje položka výš na stránce — a druhá položka se vykreslí přes celou šířku bez obrázku. Před refreshem publikujte aktuální obrazovky, ať stránka ukazuje nejnovější UI.

Tři slovesa

Refresh release a Cut release jsou v sekci Release v briefu projektu, jakmile release track existuje, a jako ↻ refresh a ✂ cut release v hlavičce nástěnky příštího vydání. První sběr se spouští z checkoutu, protože potřebuje větev a začátek okna každého repozitáře:

1. Start — vitrinka project release --refresh --repo <owner>/<name>:<branch>@<commit> …, jedno --repo na repozitář. U práce na integrační větvi je začátkem její first-parent fork point z větve, ze které vznikla, ne git merge-base (viz release skill). Do prvního střihu nové spuštění s jiným začátkem okno opraví.
2. ↻ refresh — projde GitHub pro všechno zamergované od kurzoru a předá okno release writerovi. Stránka se na nástěnce objeví, když writer odpoví, a opakované spuštění přegeneruje AI karty na místě — maže přesně svoje předchozí karty, nikdy nic, co na nástěnku dal člověk. Větve a začátky jsou uložené na vydání, tlačítko nic dalšího nepotřebuje.
3. ✂ cut — zmrazí nástěnku jako vydání a otevře další okno; další okno každého repozitáře začne na headu, kterým v něm tohle skončilo. Střih se potvrzuje a na stejném okně nejde zopakovat.

Pipeline, která stříhá po nasazení, připíchne konec okna na nasazený commit: vitrinka project release --refresh --until <sha> (REST: "until": "<sha>" v těle refreshe, nebo po repozitářích v repos[]). Sebere se jen to, co ten commit obsahuje, co se zamergovalo po něm, počká na další okno, a head okna je ten commit sám; refresh vrací headSha, takže ho pipeline před střihem ověří. Commit, který repozitář nemá (release_until_unknown), který jeho větev neobsahuje nebo který leží před začátkem okna (release_until_outside), server odmítne dřív, než cokoli sebere. Připíchnutí se neukládá: další refresh bez něj sbírá až po head větve.

Začátek okna je výlučný: okno, které začíná na commitu, drží jen mergy po něm, takže PR, který ten commit zamergoval, patří k vydání, ve kterém vyšel, a to jak u opraveného prvního začátku, tak u okna po střihu. Dvě další fakta dovolují pipeline stříhat bez dozoru. Stav vydání hlásí docHeadSha, head okna, pro který byla napsaná současná stránka: refresh, který head posune, ho nechá za sebou, a refresh, který okno změní jinak (opravený začátek), ho vymaže (hasDoc s docHeadSha jiným než headSha je zastaralá stránka), a odpověď writera na nový průchod ho nastaví na head toho průchodu. A střih může uvést head, který očekává: vitrinka project release --cut --expect-head <sha> (REST: "expectHead": "<sha>" v těle střihu) odmítne s release_head_mismatch a nic nestřihne, když okno mezitím posunul refresh.

Každé vydání po střihu zůstává jako zmražená nástěnka v podskupině releases projektu; vitrinka project release vypíše historii střihů s počty PR.

Dokument s poznámkami

Úplné poznámky k vydání jsou samostatný dokument — pushnutý jako jakýkoli artefakt — a vydání na něj odkazuje: vitrinka project release --notes <project>/<branch>/<key> (adresa setu), --notes <document link> nebo --notes <card id>. Release nástěnka pak vedle statistik ukáže náhledovou kartu dokumentu a sekce Release v briefu projektu na něj odkáže; odkaz na jiný dokument nahradí právě tuhle jednu kartu a --notes-clear ji odebere. Dokument musí žít ve stejném workspace jako vydání — odkaz do jiného workspace server odmítne. Střih odkaz na zmraženém vydání ponechá; další okno začíná bez něj.

Dokument s poznámkami má vlastní rejstřík (direction: "release"): sekce ve stylu kapitol a KPI dlaždice, obrazovky jako galerie místo figur pod sebou, čísla před a po jako srovnávací graf a bloky označené publikem, takže jeden dokument poslouží uživatelům, vývojářům i týmu — čtenář si publikum vybere v prohlížeči a exporty do PDF, HTML, e-mailu a Wordu ho zachovají. Release skill ho tak píše; slovník elementů je v přehledu elementů.

Připravenost před vydáním a po něm

Přehled sjednocuje vnořené úkoly, podmínky a podmíněná připomenutí jednou za každou identitu. Povinnosti Before release a Ship blokují vydání; povinnosti After release blokují uzavření. Výslovný odklad potřebuje vlastníka i spouštěč a začne platit, jakmile se spouštěč naplní. Volitelná práce zůstává viditelná, ale neblokuje.

Počty připravenosti pokrývají celý vybraný rozsah. Stránkovaná čtení API nesou verzi rozsahu z první stránky; pokud se rozsah změní, začněte čtení znovu místo spojování různých verzí.

Přesní kandidáti vydání

V Přehledu vyberte sprint a zvolte Prepare candidate. Kandidát uchová verzi rozsahu, úplnou revizi každého repozitáře a platformu, druh, přesnou identitu a zdrojovou revizi každého buildu. Volitelný digest může určit obsah buildu. Můžete připojit existující poznámky k vydání; kandidát pak musí odpovídat všem revizím repozitářů v jejich posledním sběru.

Změněná práce, novější kandidát nebo jiné revize propojeného vydání učiní staršího kandidáta neaktuálním. Připravte nového kandidáta a ověřte jeho přesné buildy místo použití starých důkazů pro jinou práci.

Ke kandidátovi zaznamenejte odkazy na původní důkazy ověření a nasazení. Označit je jako ověřené nebo použít Record shipment může pouze přihlášený člověk s rolí správce workspace. Vyberte ověřený důkaz nasazení pro stejného kandidáta a prostředí; povinnosti Before/Ship musí být splněné. Záznam vydání uchová kandidáta, připravenost a důkaz jako neměnné faktum v Historii. Opakování stejného ID požadavku ho nezaznamená dvakrát.

Agenti a Eve mohou číst připravenost, vysvětlovat blokátory, připravovat kandidáty a zaznamenávat neověřené důkazy. Nemohou se sami ověřit ani potvrdit vydání. Střih poznámek zmrazí jejich okno; nezaznamenává nasazení.

Nebo z repozitáře

Stejná slovesa jsou vitrinka project release (--refresh, --cut, --notes) a release skill (/vitrinka:release status|refresh|cut) — viz skills. Ať ✂ stiskne člověk, nebo střih spustí agent, je to tatáž pipeline a tatáž nástěnka.