Blogul changeloop
Note de lansare, în practică
Două lucruri la care ne gândim des: cum scrii note de lansare pe care le citește cineva și cum nu mai întreții un changelog de mână. Fără newsletter, fără înregistrare. Doar articolele.
Release notes pentru corecții de erori: cum le scrii bine
Notele despre corecții merg când intrarea numește simptomul, cine a fost afectat și pasul următor. Rescrieri înainte și după, plus reguli de securitate.
Note de lansare în practică7 min de citit
Cum ceri feedback clienților într-un produs software
Puneți o singură întrebare precisă, imediat după ce utilizatorul a făcut ceva, chiar unde lucrează. Formulări gata de folosit pentru fiecare moment.
Bucla de feedback7 min de citit
Exemple de roadmap de produs: șase formate și cum eșuează
Șase exemple de roadmap de produs: Now/Next/Later, trimestrial, pe teme, pe rezultate, public și de lansări. Cui se potrivește fiecare și cum eșuează.
Bucla de feedback7 min de citit
Procesul de gestionare a lansărilor, în șapte pași
Un proces de gestionare a lansărilor în șapte pași, cu responsabil și criterii de ieșire pentru fiecare, plus metricile DORA și un indicator în plus.
Inginerie8 min de citit
Exemple de release notes pentru fiecare tip de schimbare
Exemple de release notes pentru funcționalitate, corecție, schimbare incompatibilă, securitate, depreciere și notă internă, cu motivul pentru care merg.
Note de lansare în practică7 min de citit
Versionarea API Stripe: cum funcționează și ce poți copia
Versionarea API Stripe fixează fiecare cont pe o versiune datată și lasă orice cerere să o înlocuiască. Cum merge, cât costă și ce poate copia un API mic.
Modificări de API7 min de citit
Cine scrie changelog-ul, și cine ar trebui
Cine scrie changelog-ul? Autoarea PR-ului știe ce s-a schimbat, PM-ul de ce contează. Niciuna singură nu scrie o intrare utilă, iar una îl învechește.
Inginerie5 min de citit
Note de lansare de urgență: scrisul sub presiune de timp
O lansare determinată de un incident are nevoie de note scrise în minute, nu zile, iar procesul obișnuit de redactare presupune timp pe care nu-l aveți.
Note de lansare în practică6 min de citit
Schimbări incompatibile în Protobuf: ce rezistă pe wire
Schimbările incompatibile în Protobuf apar pe wire, nu în URL. Unele schimbări de câmp gRPC sunt gratis, altele rup clienții în tăcere, deși arată la fel.
Modificări de API6 min de citit
Formate de fișier pentru changelog: JSON, YAML sau Markdown
Formatul fișierului de changelog decide dacă poate alimenta o pagină și un widget sau doar e citit. Markdown, JSON și YAML costă lucruri diferite.
Inginerie5 min de citit
Cereri duplicate: combinare fără a pierde vocea originală
Gruparea cererilor duplicate protejează numărătoarea. Combinarea lor neglijentă pierde formularea care făcea una dintre ele utilă, pierderea mai mică.
Bucla de feedback6 min de citit
Deprecierea GraphQL fără un număr de versiune
GraphQL nu are v1 sau v2 în URL. Câmpurile sunt depreciate unul câte unul cu o directivă, pe o schemă comună, ceea ce schimbă ce datorează un changelog.
Modificări de API6 min de citit
Cum scrii un ghid de migrare API
Un ghid de migrare API transformă o schimbare incompatibilă într-o listă de verificare, nu într-o pană. Ce trebuie să conțină și de ce o intrare nu ajunge.
Modificări de API5 min de citit
Un check de changelog pentru GitHub Actions
Un check de changelog în GitHub Actions refuză merge-ul fără intrare, pentru că un pas bazat pe memorie eșuează după un tipar. Și ce strică acel check.
Inginerie5 min de citit
Refuzi o cerere de funcționalitate fără să pierzi clienta
Închiderea buclei înseamnă de obicei să spui cuiva că a fost lansat. Jumătatea grea e să spui nu, într-un fel care nu strică relația cu clienta.
Bucla de feedback5 min de citit
Note de lansare pentru un feature flag: ce să spui, și când
La note de lansare pentru un feature flag, fuzionat și lansat nu mai coincid. Închiderea buclei prea devreme anunță o funcționalitate încă invizibilă.
Bucla de feedback6 min de citit
Când o cerere de funcționalitate e de fapt o eroare
Un tichet de suport care cere o setare nouă poate ascunde o eroare. Eticheta greșită îl trimite la responsabila și la coada greșite, iar eroarea rămâne.
Bucla de feedback5 min de citit
Cum urmărești cererile de funcționalități fără să le pierzi
Urmărirea cererilor de funcționalități eșuează de obicei: nicăieri, sau undeva unde nimeni nu mai revine. Un sistem care rezistă la ambele eșecuri.
Bucla de feedback6 min de citit
Tichete de suport vs. cereri: în ce aveți încredere?
Un tichet de suport și o listă de cereri măsoară lucruri diferite, iar tratarea unui vârf pe unul ca pe celălalt produce priorități greșite.
Bucla de feedback6 min de citit
Tag-uri git, lansări și changelog-ul tău
Un tag git, o lansare, o intrare de changelog: trei înregistrări ale aceluiași eveniment. Dacă le confundați, changelog-ul deviază. Cum se potrivesc.
Inginerie5 min de citit
Note de lansare interne: cine altcineva trebuie să știe
Support-ul și vânzările află de o lansare de obicei de la un client derutat. Notele interne rezolvă asta, într-o formă diferită de cele pentru clienți.
Note de lansare în practică5 min de citit
Changelog-uri de API interne: ce se schimbă
Un changelog de API public are un public pe care nu îl poți contacta. Unul intern are un public la două etaje distanță, iar asta schimbă ce i se cuvine.
Modificări de API6 min de citit
Note de lansare pentru aplicații mobile: ce taie limita
App Store și Play Store dau câteva rânduri vizibile și fără linkuri. Ce funcționează într-un changelog web se rupe la acel buget atât de strâns.
Note de lansare în practică5 min de citit
Changelog-uri de monorepo: unul singur, sau unul pe pachet?
Un monorepo poate avea un changelog pentru tot repo-ul sau unul pe pachet, iar alegerea greșită face lansările fie prea zgomotoase, fie prea dispersate.
Inginerie5 min de citit
Cum anunți o funcționalitate nouă (fără tăcere)
Majoritatea anunțurilor de funcționalități mor într-un canal necitit de două ori. Unde anunți, ce spui primul, și pe cine trebuie să ajungi.
Note de lansare în practică5 min de citit
Release notes enterprise: ce se schimbă pentru un cont
Release notes enterprise pentru un client pe build privat trebuie calibrate pe instanța lui. O calibrare greșită scurge roadmap-ul sau derutează suportul.
Note de lansare în practică5 min de citit
Cum prioritizezi cererile de funcționalități care se adună
Un backlog urmărit lasă deschisă întrebarea grea: ce cerere iese prima. Cadrele care funcționează, unde cedează și ce ascunde numărul brut de voturi.
Bucla de feedback6 min de citit
Semantic versioning și changelog-ul tău
Semantic versioning spune cât de mult poate durea o lansare înainte să citești un cuvânt din changelog. Ce promite fiecare cifră, ce datorează o intrare.
Inginerie5 min de citit
Changelog-uri de webhook: schimbarea necerută
O schimbare de payload la webhook se strică în tăcere, pentru că nimeni n-o poate respinge. Ce o face să rupă compatibilitatea, și cum se versionează.
Modificări de API6 min de citit
Header-ul Sunset al unui API și când să-l trimiți
Header-ul Sunset spune unui client când o versiune încetează să răspundă, spre deosebire de o depreciere. Ce acoperă RFC 8594 și ce aduce un brownout.
Modificări de API5 min de citit
Ce este un changelog și ce ar trebui să conțină?
Un changelog este înregistrarea datată a ceea ce s-a schimbat într-un produs, scrisă pentru cei afectați. Ce intră în el, ce nu, și unde ar trebui să stea.
Note de lansare în practică5 min de citit
Changelog de API: ce publici și cine îl citește
E citit de oameni care decid dacă codul lor va mai funcționa luna viitoare. Ce le datorează fiecare intrare, unde locuiește changelog-ul, cum se abonează.
Modificări de API7 min de citit
Cum construiești o pagină de changelog care se urmărește
Merită construită când cineva revine la ea. Unde locuiește, de ce are nevoie fiecare intrare, fluxuri și markup, și unde se potrivește widget-ul.
Inginerie6 min de citit
Șablonul de e-mail de actualizare produs care se citește
Un șablon în șase blocuri, cele patru tipuri de e-mail care au nevoie de liste diferite, subiecte eficiente, și când e nevoie de consimțământ.
Note de lansare în practică6 min de citit
Cum se depreciază un API fără a pierde dezvoltatorii
Deprecierea e o promisiune cu o dată. Programul, șablonul de notificare, header-ele de răspuns, și pasul care oprește un sunset să devină un incident.
Modificări de API6 min de citit
Cele mai bune practici de versionare API, pentru apelanți
Versionați doar ce rupe compatibilitatea, puneți versiunea unde apelanții o văd, și mențineți-o pe cea veche până la o dată. Patru scheme comparate.
Modificări de API8 min de citit
Schimbări care rup compatibilitatea și cum le lansezi
O schimbare care rupe compatibilitatea e orice pe care un apelant corect n-ar fi supraviețuit. Ce contează, ce nu, cum o prinzi în CI și cum o lansezi.
Modificări de API10 min de citit
Închiderea buclei de feedback din partea changelog-ului
O buclă de feedback se închide când solicitantul află că funcția a fost lansată. Bucla în patru pași, unde se rupe și de ce changelog-ul e locul potrivit.
Bucla de feedback8 min de citit
Șablon de cerere de funcție care devine changelog
O cerere de funcție e utilă doar dacă poate fi regăsită la lansare. Șablonul, etichetele care o direcționează și câmpurile pe care changelog-ul le citește.
Bucla de feedback6 min de citit
Roadmap publică din tracker-ul de issue-uri, trei coloane
O roadmap publică e o promisiune despre viitor. Mențineți-o mică, alimentați-o din issue-uri și mutați fiecare element cu o etichetă pe issue-ul lui.
Bucla de feedback6 min de citit
Automatizarea changelog-ului, și limitele sale
Automatizați colectarea, formatarea și publicarea changelog-ului, dar nu selecția sau formularea. Unde se află linia și ce se întâmplă când se mută.
Inginerie6 min de citit
Changelog vs release notes: care e diferența?
Un changelog e un registru continuu pentru cineva care caută ceva. Release notes sunt un mesaj selectat pentru cineva care decide dacă îl privește.
Note de lansare în practică5 min de citit
De la conventional commits la un changelog
Conventional commits fac un changelog derivabil. Nu-l fac lizibil. Ce oferă convenția, unde se oprește, și cum se umple diferența dintre ele.
Inginerie5 min de citit
Cum se scriu release notes pe care oamenii chiar le citesc
«Corecții de erori și îmbunătățiri de performanță» nu e o release note. Întrebarea la care trebuie să răspundă fiecare intrare, și rescrierea uneia reale.
Note de lansare în practică6 min de citit
Keep a Changelog, implementat cu adevărat
Specificația e o pagină și durează zece minute de citit. Implementarea e locul unde echipele se abat. Ce spune, ce lasă deschis, și unde greșește.
Inginerie5 min de citit
Cele mai bune practici pentru release notes care contează
Majoritatea listelor de bune practici sunt sfaturi de stil. Acestea schimbă ce face cititorul, plus trei practici populare care sunt cult cargo pur.
Note de lansare în practică6 min de citit