Note de lansare pentru un feature flag: ce să spui, și când

Închiderea buclei pe o cerere de funcționalitate presupune un moment clar în care lucrul a fost lansat. Un feature flag elimină acel moment, și tocmai de aceea e greu de ales când publici note de lansare pentru un feature flag. Codul e fuzionat, flag-ul există, iar timp de zile sau săptămâni după aceea funcționalitatea e simultan live în producție și invizibilă pentru aproape oricine ar putea vrea s-o folosească, deseori inclusiv persoana care a cerut-o inițial. Anunțarea prea devreme o face să dea peste o funcționalitate care încă nu e acolo. Anunțarea prea târziu face ca bucla care trebuia să construiască încredere să se citească, în schimb, ca uitată.

De ce rupe un flag secvența obișnuită “lansează, anunță”?

Pentru că împarte un eveniment în cel puțin două: codul care devine live, și flag-ul care se activează pentru un cont anume. Orice proces de închidere a unei bucle de feedback presupune că acestea se întâmplă împreună, ceea ce e adevărat pentru majoritatea lansărilor și fals pentru tot ce se află în spatele unui flag folosit pentru lansare graduală, direcționare sau ca întrerupător de urgență. Închiderea buclei de feedback a clientului descrie anunțarea solicitantei exact în momentul în care o intrare de changelog e aprobată și publicată; pasul acela e scris pentru cazul în care publicarea intrării și utilizabilitatea funcționalității sunt același moment, iar un flag e exact cazul în care nu sunt.

Care e regula reală pentru când să anunți pe cineva?

Anunță când flag-ul e activat pentru contul ei, nu când codul e fuzionat și nu când flag-ul e creat. Această regulă unică acoperă fiecare rând din tabelul de mai sus, pentru că leagă notificarea de singurul fapt care contează cu adevărat pentru solicitantă: dacă poate, chiar acum, să meargă să folosească lucrul respectiv. O notificare legată de fuzionare sau de crearea flag-ului e de fapt un raport de progres inginer, iar cineva care a cerut o funcționalitate nu vrea un raport de progres, vrea să știe când să se uite.

Înseamnă asta că solicitanta are nevoie de acces timpuriu sau special?

Nu neapărat, iar forțarea asta creează propria problemă. Dacă flag-ul e lansat gradual din motive de încărcare sau stabilitate, mutarea unui cont în fața cozii doar pentru a închide o buclă mai repede subminează motivul pentru care lansarea e eșalonată în primul rând. Opțiunile oneste sunt: așteptarea ca contul solicitantei să ajungă natural la lansare și anunțarea ei atunci, sau, dacă urgența justifică asta, activarea deliberată a flag-ului mai devreme pentru ea, ca o decizie reală a cui deține lansarea, nu ca efect secundar al dorinței de a trimite o notificare.

Dar dacă flag-ul e un întrerupător de urgență, nu un mecanism de lansare?

Atunci presupunerea sigură se inversează. Un flag gândit ca să poți dezactiva rapid o funcționalitate, mai degrabă decât să eșalonezi lansarea ei, înseamnă de obicei că funcționalitatea trebuie să fie complet live din momentul creării, iar flag-ul există pentru siguranță, nu pentru secvențiere. În acest caz, anunțarea solicitantei la momentul lansării în producție e corectă, la fel ca la orice lansare fără flag; existența flag-ului e un detaliu operațional care n-ar trebui să schimbe când se închide bucla. Distincția care contează e la ce folosește flag-ul, nu dacă există unul.

Flag-ul schimbă ce ar trebui să spună notele de lansare pentru un feature flag?

Schimbă când se publică intrarea, nu ce conține. O intrare publicată exact în momentul în care flag-ul e activat pentru 100% dintre conturi se citește exact ca o intrare normală de changelog, și așa trebuie; o cititoare care o găsește mai târziu n-are niciun motiv să știe că a existat vreodată un flag implicat. Ce n-ar trebui să facă e să fie publicată în timp ce flag-ul e activat doar pentru un procent mic de lansare, pentru că o intrare publică de changelog trimite pe oricine o citește, inclusiv conturi fără flag, să caute o funcționalitate pe care n-o vor găsi, ceea ce e o versiune mai proastă a aceleiași probleme, la scara întregului produs în loc de scara unei singure solicitante. Această regulă de sincronizare e toată diferența dintre notele de lansare pentru un feature flag și o intrare obișnuită: conținutul e același, doar data publicării se mută. Cum se scriu release notes acoperă disciplina “nicio acțiune necesară” care se aplică și aici: cititoarele trebuie să știe dacă asta le privește, nu doar că există undeva.

E-mailurile de actualizare a produsului ar trebui să trateze diferit o funcționalitate cu flag?

Da, mai ales prin amânare, nu prin rescriere. Șablonul de e-mail de actualizare a produsului acoperă notificările țintite față de rezumatele largi; o funcționalitate cu flag e un caz în care momentul unei notificări țintite trebuie verificat față de starea proprie a flag-ului destinatarei înainte de a fi trimisă, ceva ce un rezumat larg nu poate face ușor deloc, ceea ce e încă un motiv pentru care un rezumat e canalul greșit pentru orice se află încă la mijlocul lansării.

FAQ

Ar trebui să i se spună unei solicitante că funcționalitatea ei “vine în curând” odată ce flag-ul există dar nu e activat încă pentru ea? Doar dacă există o dată reală și apropiată atașată, și chiar și atunci cu măsură. Un “vine în curând” fără dată se citește, după suficient timp, exact ca tăcerea, și creează o a doua promisiune care trebuie de asemenea urmărită și respectată.

Cine decide când un flag e suficient de avansat pentru a închide bucla? Oricine deține lansarea, nu oricine deține notificarea. Cea care deține lansarea știe dacă “100% dintre conturi” e iminent sau încă la săptămâni distanță; legarea pasului de închidere a buclei de starea ei, în loc de o dată fixă în calendar, menține notificarea onestă.

O funcționalitate din spatele unui flag permanent (niciodată eliminat complet) primește vreodată o intrare publică de changelog? Da, odată ce atinge orice înseamnă “disponibilitate generală” pentru acel produs, chiar dacă flag-ul în sine rămâne în cod pentru totdeauna din motive operaționale. Intrarea de changelog e despre disponibilitatea pentru cititoare, nu despre detaliul de implementare al modului în care acea disponibilitate e realizată.

Dar dacă flag-ul e eliminat și funcționalitatea e ucisă în loc să fie lansată? Acela e un refuz, nu o notificare de lansare, și merită aceeași grijă ca orice alt refuz. Cum refuzi o cerere de funcționalitate acoperă ce ar trebui să spună acel mesaj; închiderea onestă a buclei înseamnă uneori închiderea ei cu un nu.

Notele de lansare pentru un feature flag au nevoie de un șablon separat față de o intrare normală? Niciun șablon nou, doar un pas de verificare înainte de publicare: verificați starea flag-ului pentru contul care a cerut, nu doar că a fost fuzionat codul, și țineți intrarea în așteptare până trece acea verificare. Tot restul despre intrare, formularea, lungimea, disciplina FAQ, rămâne la fel ca orice altă notă de lansare.

Afirmațiile tehnice din acest articol nu au fost verificate independent. Dacă ceva nu e corect, spune-ne și vom corecta.

Pe changeloop: Documentație pentru dezvoltatori, Comparație instrumente changelog