Changeloop

Blog changeloop

Poznámky k vydání v praxi

Dvě věci, na které hodně myslíme: jak psát poznámky k vydání, které si někdo přečte, a jak přestat udržovat changelog ručně. Žádný newsletter, žádná registrace. Jen texty.

  • Release notes k opravám chyb: jak psát použitelné záznamy

    Release notes k opravám chyb fungují, když každý záznam uvádí příznak, koho zasáhl a další krok. Přepisy před a po, pravidla pro bezpečnost a ztrátu dat.

    Poznámky k vydání v praxi6 min čtení

  • Jak žádat o zpětnou vazbu zákazníků v softwarovém produktu

    Ptejte se na jednu konkrétní věc hned poté, co uživatel něco udělal, tam, kde pracuje. Hotová znění pro každý okamžik a špatné dotazy, kterým se vyhnout.

    Smyčka zpětné vazby6 min čtení

  • Příklady produktové roadmapy: šest formátů a jak selhávají

    Šest příkladů produktové roadmapy s realistickými položkami: Now/Next/Later, kvartální, tematická, výsledková, veřejná a release. Komu se hodí a kde selže.

    Smyčka zpětné vazby6 min čtení

  • Proces správy vydání pro týmy, které vydávají často

    Proces správy vydání pro softwarové týmy v sedmi krocích, s vlastníkem a kritérii dokončení u každého, plus metriky DORA a jedno další KPI, které sledovat.

    Vývoj6 min čtení

  • Příklady release notes pro každý druh změny

    Příklady release notes pro funkci, opravu, zásadní změnu, bezpečnost, deprekaci, obchod s aplikacemi i interní zprávu, vždy s vysvětlením, proč fungují.

    Poznámky k vydání v praxi6 min čtení

  • Verzování API Stripe: jak funguje a co z něj převzít

    Verzování API Stripe připíná každý účet k datované verzi a každý požadavek ji může přepsat. Jak funguje, co stojí a co z něj může převzít malé API.

    Změny API6 min čtení

  • Kdo píše changelog, a kdo by měl

    Kdo píše changelog? Autorka PR ví, co se změnilo, PM proč na tom záleží. Žádná sama užitečný záznam nenapíše a výchozí volba changelog nechá zastarat.

    Vývoj5 min čtení

  • Pohotovostní release notes: psaní pod časovým tlakem

    Vydání vyvolaná incidentem potřebují poznámky napsané za minuty, ne dny, a běžný proces psaní počítá s časem, který v takové chvíli vůbec nemáte.

    Poznámky k vydání v praxi4 min čtení

  • Breaking changes v Protobuf: co přežije na drátě

    Breaking changes v Protobuf vznikají na drátě, ne v URL. Některé změny polí v gRPC jsou zdarma, jiné potichu rozbijí klienty, a v diffu vypadají stejně.

    Změny API5 min čtení

  • Formáty souborů changelogu: JSON, YAML nebo jen Markdown

    Formát souboru changelogu rozhoduje, jestli může krmit stránku a widget zároveň, nebo ho čte jen člověk. Markdown, JSON a YAML stojí něco jiného.

    Vývoj4 min čtení

  • Duplicitní požadavky: sloučení bez ztráty hlasu

    Seskupování duplicitních požadavků na funkce chrání počet. Neopatrné sloučení ztrácí formulaci, která dělala jeden z nich užitečným, tu menší ztrátu.

    Smyčka zpětné vazby5 min čtení

  • Deprekace GraphQL bez čísla verze

    GraphQL nemá v1 nebo v2 v URL. Pole se deprekují jedno po druhém direktivou, na schématu sdíleném všemi klienty, což mění, co dluží changelog.

    Změny API5 min čtení

  • Jak napsat migrační průvodce API

    Migrační průvodce API mění nekompatibilní změnu ve checklist místo výpadku. Co potřebuje, kdy ho zveřejnit, a proč samotný záznam changelogu nestačí.

    Změny API4 min čtení

  • Kontrola changelogu pro GitHub Actions

    Kontrola changelogu v GitHub Actions odmítne merge bez záznamu, protože krok závislý na paměti selhává podle vzorce. Jak ji nastavit a co rozbíjí.

    Vývoj4 min čtení

  • Jak odmítnout požadavek, aniž přijdete o klientku

    Uzavření smyčky obvykle znamená říct někomu, že jeho požadavek úspěšně vyšel. Těžší polovina je říct ne, aniž by se tím poškodil vztah s klientkou.

    Smyčka zpětné vazby4 min čtení

  • Release notes k feature flagu: co napsat a kdy

    Release notes k feature flagu musí rozlišit sloučení a vydání, s flagem to není totéž. Předčasné uzavření smyčky oznámí funkci, kterou žadatel nevidí.

    Smyčka zpětné vazby5 min čtení

  • Když je požadavek na funkci ve skutečnosti hlášení chyby

    Tiket podpory žádající o nové nastavení může být obchvat skryté chyby. Špatný štítek ho pošle ke špatné vlastnici a rovnou do špatné fronty.

    Smyčka zpětné vazby4 min čtení

  • Jak sledovat požadavky na funkce, aniž byste je ztratili

    Sledování požadavků na funkce selhává dvěma způsoby: požadavky nikam nedorazí, nebo tam, kam se nikdo nevrací. Jak postavit systém, který obstojí.

    Smyčka zpětné vazby5 min čtení

  • Git tagy, release a váš changelog

    Git tag, release a záznam changelogu jsou tři záznamy jedné události. Jejich zaměňování nechává changelog odchýlit se. Jak by si tyto tři měly odpovídat.

    Vývoj4 min čtení

  • Tickety Podpory vs. Požadavky Na Funkce: Čemu Věřit?

    Ticket podpory a nástěnka požadavků na funkce měří odlišné věci, a zacházení s nárůstem u jednoho jako u druhého dává sebejisté, chybné priority.

    Smyčka zpětné vazby5 min čtení

  • Interní API changelogy: co se mění pro druhý tým

    Veřejný API changelog má publikum, které nelze kontaktovat přímo. Interní má publikum o dvě patra dál, a to mění, co mu changelog vlastně dluží.

    Změny API4 min čtení

  • Interní release notes: kdo další musí vědět, co vyšlo

    Support a obchod se o uvedení obvykle dozví od zmateného zákazníka. Interní release notes to řeší, v jiné podobě než ty zákaznické, dřív než přijde tiket.

    Poznámky k vydání v praxi4 min čtení

  • Changelogy v monorepu: jeden, nebo jeden na balíček?

    Monorepo může mít jeden changelog pro celé repo, nebo jeden na balíček. Špatná volba udělá z každého release čtení buď příliš hlučné, nebo roztříštěné.

    Vývoj4 min čtení

  • Release notes pro mobilní aplikace: co usekne limit

    App Store a Play Store dávají pár viditelných řádků a žádné odkazy. Co funguje ve webovém changelogu, se tu rozpadne, a škrty proto musí být záměrné.

    Poznámky k vydání v praxi4 min čtení

  • Jak oznámit novou funkci (bez ticha)

    Většina oznámení funkcí umírá v kanálu, který nikdo nečte dvakrát. Kde oznamovat, co říct jako první, a jak se dostat k těm, kdo si o to skutečně řekli.

    Poznámky k vydání v praxi4 min čtení

  • Jak prioritizovat požadavky na funkce, které se hromadí

    Sledovaný backlog nechává otevřenou tu těžkou otázku: který požadavek jde první. Rámce, které fungují, kde každý selhává, a co skrývá hrubý počet hlasů.

    Smyčka zpětné vazby5 min čtení

  • Enterprise release notes: co se mění pro jeden účet

    Enterprise release notes pro zákazníka na soukromém buildu musí být kalibrované na jeho instanci. Špatná kalibrace prozradí roadmapu nebo zmate podporu.

    Poznámky k vydání v praxi4 min čtení

  • Semantic versioning a váš changelog

    Semantic versioning říká volající straně, jak moc může bolet release, ještě než přečte slovo z changelogu. Co slibuje každé číslo, a co dluží záznam.

    Vývoj4 min čtení

  • Hlavička API Sunset a kdy ji odeslat

    Hlavička API Sunset říká klientovi, kdy verze přestane odpovídat, na rozdíl od oznámení o deprekaci. Co pokrývá RFC 8594 a co přináší brownout před koncem.

    Změny API4 min čtení

  • Co je changelog a co by měl obsahovat?

    Changelog je datovaný záznam toho, co se v produktu změnilo, napsaný pro ty, kterých se to skutečně týká. Co do něj patří, co ne, a kde by měl žít.

    Poznámky k vydání v praxi5 min čtení

  • Changelogy webhooků: breaking change, o kterou nikdo nežádal

    Změna payloadu webhooku se rozbije potichu, protože ji nemá kdo odmítnout. Co dělá změnu payloadu breaking a jak ji krok za krokem verzovat.

    Změny API5 min čtení

  • API changelog: co publikovat a kdo to čte

    API changelog čtou lidé, kteří rozhodují, jestli jejich kód bude fungovat i příští měsíc. Co dluží každý záznam jim, kde má být, a jak se dá odebírat.

    Změny API6 min čtení

  • Jak postavit changelog stránku, kterou lidé sledují

    Changelog stránka se vyplatí, když se na ni lidé vracejí a čtou ji znovu. Kde by měla žít, co potřebuje záznam, feedy a markup, a kam patří widget.

    Vývoj5 min čtení

  • Šablona e-mailu o aktualizaci produktu, kterou lidé čtou

    E-mail o aktualizaci produktu, který se čte, šel někomu, kdo o něj požádal. Šablona, čtyři typy e-mailů, funkční předměty, segmentace a souhlas.

    Poznámky k vydání v praxi5 min čtení

  • Jak deprekovat API bez ztráty vývojářů

    Deprekace je slib s datem. Harmonogram, šablona oznámení, hlavičky odpovědi, a krok, který brání sunsetu stát se incidentem podpory pro celý tým.

    Změny API5 min čtení

  • Nejlepší praktiky verzování API, kvůli volajícím

    Verzujte jen to, co rozbíjí kompatibilitu, umístěte verzi tam, kde ji volající vidí, a starou udržujte funkční do data. Čtyři schémata porovnaná.

    Změny API6 min čtení

  • Breaking changes: co se počítá a jak je vydat

    Breaking change je každá změna, kterou by korektní volající nepřežil. Co se počítá, co ne, jak ji zachytit v CI a jak ji bezpečně vydat svým uživatelům.

    Změny API8 min čtení

  • Uzavření smyčky zpětné vazby ze strany changelogu

    Smyčka zpětné vazby se uzavře, když žadatel ví: vydáno. Smyčka ve čtyřech krocích, kde se trhá, a proč je changelog správné místo k jejímu uzavření.

    Smyčka zpětné vazby7 min čtení

  • Šablona požadavku na funkci, která se stává changelogem

    Požadavek na funkci je užitečný jen tehdy, když ho lze znovu najít při vydání. Šablona, štítky, které ho směrují, a pole, která pak čte changelog.

    Smyčka zpětné vazby5 min čtení

  • Veřejná roadmap z vašeho issue trackeru, tři sloupce

    Veřejná roadmap je slib o budoucnosti. Udržujte ji malou, napájejte ji z issue, která už sledujete, a každou položku posouvejte štítkem na jejím issue.

    Smyčka zpětné vazby5 min čtení

  • Automatizace changelogu, a její limity

    Automatizujte sběr, formátování a zveřejňování. Neautomatizujte výběr ani formulaci. Kde je hranice a co se stane pokaždé, když se ta hranice posune.

    Vývoj5 min čtení

  • Od conventional commits k changelogu

    Conventional commits dělají changelog odvoditelný. Nedělají ho čitelný. Co konvence poskytuje, kde se zastavuje, a jak přemostit tu mezeru mezi nimi.

    Vývoj5 min čtení

  • Changelog vs release notes: jaký je rozdíl?

    Changelog je průběžný záznam pro toho, kdo něco hledá. Release notes jsou vybraná zpráva pro toho, kdo se rozhoduje, zda ho to zajímá. Rozdělení.

    Poznámky k vydání v praxi5 min čtení

  • Jak psát release notes, které lidé skutečně čtou

    «Opravy chyb a vylepšení výkonu» není release note. Otázka, na kterou musí odpovědět každý záznam v release notes, a přepis skutečného příkladu.

    Poznámky k vydání v praxi5 min čtení

  • Keep a Changelog, skutečně zavedený

    Specifikace má jednu stránku a čte se deset minut. Zavádění je místo, kde se týmy odchylují. Co říká, co ponechává otevřené, a kde přesně selhává.

    Vývoj5 min čtení

  • Nejlepší praktiky pro release notes, na kterých záleží

    Většina seznamů nejlepších praktik jsou stylistické rady. Tyto mění chování čtenáře, plus tři populární, které se ukázaly být čistý kult cargo.

    Poznámky k vydání v praxi5 min čtení