Dezvoltarea de software în 2020 este un mediu în schimbare rapidă. Devine din ce în ce mai clar pe zi ce trece că, dacă organizațiile noastre doresc să supraviețuiască acestei perioade de incertitudine politică și economică, trebuie să fie capabile să se miște cu viteză și adaptabilitate. Dar cum puteți controla siguranța în viteză? Dacă obiectivul dvs. este să treceți de la un ciclu de livrare de software care a fost construit cu multe garduri de protecție și implementări rare, la o metodologie mai modernă care sprijină capacitatea de reacție prin intermediul unor versiuni frecvente pentru a transmite valoare clienților dvs. cât mai rapid și mai sigur posibil, atunci pe cine puneți să se ocupe de deciziile de gestionare a schimbărilor contează, foarte mult.
În mod tradițional, în multe organizații, aceste decizii sunt luate în mod centralizat de către un manager de schimbări care conduce întâlniri periodice ale consiliului consultativ pentru schimbări (CAB). CAB în sine este o colecție de reprezentanți din diverse funcții din interiorul și din afara IT-ului corporativ, însărcinați cu examinarea schimbărilor propuse și cu asistarea managerului de schimbare în evaluarea, prioritizarea și programarea schimbărilor. Prin concepție, acesta este un grup care nu este implicat direct în conceperea sau implementarea schimbării propuse, motiv pentru care procesul pe care îl desfășoară este cunoscut ca o revizuire „externă”.
Dar, cine ar trebui să fie responsabil? Pentru a sprijini cel mai bine atât viteza și siguranța, cât și impactul asupra afacerii, doriți ca echipele de dezvoltare și clienții dumneavoastră să conducă procesul decizional. Din punct de vedere tehnic, dezvoltatorii dvs. au o idee mai bună despre ce conține o versiune, dacă există interdependențe și dacă a fost testată, decât orice consiliu consultativ pentru schimbări. Din punct de vedere comercial, este timpul să realizăm că clientul este arbitrul final în ceea ce privește ceea ce va funcționa și ceea ce nu va funcționa, nu vreun manager senior și, cu siguranță, nu consiliul dvs. consultativ pentru schimbări.
Un consiliu consultativ pentru schimbări poate fi mai lent, dar cel puțin este mai sigur, nu-i așa?
Consiliul consultativ pentru schimbări (și o mare parte din ceea ce veți găsi în ITIL), ar putea părea modalități rezonabile de a reduce riscul și de a adăuga rigoare, în special în mediile complexe și cu evoluție lentă. Dacă aveți doar o singură șansă la fiecare 30 sau 90 de zile pentru a schimba producția, menținerea lucrurilor în afara versiunilor cu porți de calitate și aprobări de management pare a fi o modalitate bună de a gestiona riscul. Nimeni nu ar discuta faptul că este un proces mai lent (care poate adăuga săptămâni sau luni la timpul dintre momentul în care un dezvoltator scrie codul și punerea în funcțiune a acestuia), dar este mai sigur, nu-i așa?
De fapt, nu. Nu este.
Un studiu de mai mulți ani într-o mare varietate de industrii și medii a constatat că a avea un CAB sau un proces similar de „aprobare externă” a avut rezultate mai proaste decât a nu avea niciun proces de aprobare. Iată ce a avut de spus autorul principal, Dr. Nicole Fosgren, despre rezultate:
Am constatat că aprobările externe au fost corelate negativ cu timpul de execuție, frecvența implementării și timpul de restaurare și nu au avut nicio corelație cu rata de eșec a modificărilor. Pe scurt, aprobarea de către un organism extern (cum ar fi un manager sau un OEC) pur și simplu nu funcționează pentru a crește stabilitatea sistemelor de producție, măsurată prin timpul de restabilire a serviciului și rata de eșec a modificărilor. Cu toate acestea, cu siguranță încetinește lucrurile. Este, de fapt, mai rău decât să nu existe niciun proces de aprobare a modificărilor.
Ce este mai bine decât niciun management al modificărilor?
Dr. Fosgren și echipa sa nu sugerează de fapt să nu aveți niciun proces de aprobare, dar având în vedere cât de prost funcționează CAB-urile în lumea reală, ar trebui să ne gândim din nou la ce fel de proces vă va menține de fapt în siguranță.
Iată un alt citat din studiul Accelerate:
Recomandarea noastră bazată pe aceste rezultate este de a utiliza un proces ușor de aprobare a modificărilor bazat pe revizuirea între egali, cum ar fi programarea în perechi sau revizuirea codului intrateam, combinat cu un pipeline de implementare pentru a detecta și respinge modificările proaste. Acest proces poate fi utilizat pentru toate tipurile de modificări, inclusiv modificări de cod, de infrastructură și de baze de date.
Revizuiri de cod de la egal la egal combinate cu Ce se întâmplă acum?
Când am citit această recomandare în martie 2018, nu am avut nicio problemă în a vizualiza prima jumătate: revizuirile de cod de la egal la egal și demonstrațiile săptămânale ale echipei erau deja norme la BlazeMeter. A doua jumătate? Nu atât de mult! Eram o aplicație SaaS „modernă” de tip cloud-native, dar nu auzisem niciodată de „un pipeline de implementare care să detecteze și să respingă modificările proaste”.
Pentru a gestiona riscurile în timpul lansărilor de atunci, foloseam o combinație de implementări albastre/verzi și lansări canare. Platforma făcea „împingerea”, dar nu și „detectarea” sau „respingerea” – asta depindea de cei mai buni și mai străluciți SRE ai noștri, care verificau manual starea de sănătate a zeci de lucruri înainte de a trece la 100% din utilizatori. Citind „detectarea și respingerea modificărilor nepotrivite” a apărut doar o imagine a unei cutii negre pe o tablă albă etichetată „aici se întâmplă magie”. Flashback-uri la studiile de film din facultate, unde am învățat ce înseamnă „deus ex machina”.
Detectă și respinge: Examples Are Out There If You Look
Multe lucruri se pot schimba în doi ani. De când m-am alăturat Split în calitate de CD Evangelist, l-am urmărit pe Lukas Vermeer descriind modul în care pipeline-ul de implementare al Booking.com poate detecta și inversa o schimbare proastă în decurs de o singură secundă. Am ascultat-o pe Sonali Sheel de la Walmart Labs explicând cum își folosesc platforma Expo pentru a opri o lansare la jumătatea drumului înainte ca aceasta să dăuneze parametrilor lor cheie, ceva ce ei numesc Test to Launch.
Platforma Split Feature Delivery a fost creată de oameni cu viziuni similare asupra managementului modern al schimbării, bazate pe experiențele trăite la LinkedIn, Salesforce.com și Yahoo. Fondatorii au primit sfaturi de la oameni care au abordat complexitatea, viteza și scara unor sisteme similare la Amazon și Microsoft.
Când am auzit despre Split și am descoperit exemplele pe care le comercializau, am sărit pe șansa de a mă alătura lor. Construirea unei astfel de platforme in-house era ceva ce doar câțiva giganți aveau timpul și resursele necesare pentru a aborda. Dacă același tip de expunere fină și de detectare automată a impactului ar fi fost disponibil sub formă de SaaS, atunci livrarea de software bazat pe impact ar fi putut fi deblocată pentru fiecare echipă, nu doar pentru startup-urile unicorn.
Este uimitor, dar nu va funcționa aici
Un lucru amuzant s-a întâmplat de nenumărate ori în timp ce călătoream la conferințe de tehnologie, susținând discuții despre primii pionieri care au construit aceste platforme în casă. Publicul răspundea mai întâi cu uimire și apoi cu resemnare. „Este destul de mișto, dar noi nu suntem Booking.com, LinkedIn ,sau Facebook. Nu putem face asta în mediul nostru”.
În eforturile mele de a fi „neutru față de furnizor”, evitând detaliile specifice ale implementării Split, practic am redesenat acea imagine neclară a unei cutii negre pe care scria „magia se întâmplă aici”.
Și dacă nu ar fi atât de greu?
Dacă nu ați văzut niciodată o platformă care să ofere un control fin al expunerii și un mecanism automatizat riguros de detectare și respingere a schimbărilor proaste din mediul dumneavoastră, nu puteți fi învinuit dacă vă gândiți că este science fiction.
Se pare că sunt doar patru probleme principale de rezolvat aici:
- Decuplați implementarea de lansare, astfel încât codul să poată fi împins până la producție, dar să fie împiedicat de la execuție până când este gata. Acest lucru facilitează adevărata integrare continuă, dimensiuni mici ale loturilor, dezvoltarea incrementală a caracteristicilor și ramificarea prin abstractizare, toate acestea fiind esențiale pentru a reuși o livrare continuă în care fluxul este norma.
- Expuneți selectiv noul cod, începând cu audiențe interne mici și continuând spre exterior. Acest lucru facilitează testarea în producție, dogfooding, programe de acces timpuriu și punerea în loturi a modificărilor pentru clienții cu aversiune la schimbare.
- Ingerați datele privind comportamentul sistemului și al utilizatorilor și aliniați-le cu datele de expunere, indicând cine intră și cine iese din fiecare cohortă de utilizatori. Scopul este de a face ca procesul de atribuire (alinierea „Cine a primit ce?”, cu „Apoi s-a întâmplat acest lucru”) să fie automat și continuu.
- Comparați modelele de măsurători între cei incluși și cei excluși din fiecare cohortă pentru a identifica (și, opțional, alerta asupra) diferențelor semnificative. Este posibil să fi văzut acest tipar înainte în contextul „testării A/B”, care de obicei urmărește impactul schimbărilor asupra unei metrici de conversie, dar aici vorbim despre urmărirea în general a impactului tuturor lucrărilor de inginerie și de a avea o supraveghere permanentă a impactului asupra tuturor metricilor valoroase din punct de vedere organizațional, indiferent dacă impactul asupra acestor metrici este așteptat sau nu.
Livrare progresivă: O fundație ușor de stabilit
Decuplarea implementării de lansare și expunerea selectivă a noului cod devin cunoscute sub numele de livrare progresivă, un termen inventat de analistul RedMonk James Governor. Mai mulți furnizori comerciali de stegulețe de caracteristici oferă aceste capabilități din fabrică și se conturează un consens conform căruia stegulețele de caracteristici s-au alăturat listei de instrumente pentru dezvoltatori care au mai mult sens să fie cumpărate decât construite și întreținute intern.
Semnalizatoarele de caracteristici sunt o bază esențială pentru realizarea fluxului, dar prin ele însele nu accelerează detectarea impactului. Majoritatea implementărilor de indicatori de caracteristici facilitează fluxul, dar nu fac nimic pentru a indica dacă totul este în regulă sau dacă obțineți rezultate semnificative.
Head’s Up: Data Scientists Don’t Scale
Inglobarea comportamentului sistemului și al utilizatorilor și alinierea automată a acestuia cu cohortele expuse este rară printre toate sistemele interne, cu excepția celor mai sofisticate. Majoritatea echipelor care încearcă această practică fac multă muncă manuală și ad-hoc în domeniul științei datelor. Deoarece sunt constrânse de resursele umane mai degrabă decât de capacitatea de calcul, ele sunt forțate să aleagă când și unde să acorde atenție.
Încărcarea cognitivă nu este prietenul tău atunci când țintești fluxul, așa că designul Split nici măcar nu cere echipelor să aleagă ce evenimente să asocieze cu fiecare lansare de steaguri de caracteristici; toate evenimentele ingerate, odată legate de parametrii organizaționali, sunt atribuite în mod continuu cohortelor de activare și dezactivare a fiecărei lansări, fără nicio intervenție. Split ușurează, de asemenea, munca de identificare și ingerare a datelor de eveniment prin integrări cu Segment, Sentry, mParticle și Google Analytics.
Semper Fi for Continuous Delivery Pipelines
Compararea modelelor de măsurători între cei incluși și cei neincluși în fiecare cohortă într-un mod riguros pentru a determina în mod automat diferențele semnificative este chiar mai rară în sălbăticie decât atribuirea. Aceasta este exact problema pe care modulele Split’s Monitor și Experimentation o rezolvă. Monitor se concentrează pe identificarea și alertarea cu privire la impactul asupra metricilor pe măsură ce o lansare este în curs de desfășurare (cunoscută și sub numele de „limitarea razei de explozie a incidentelor”), în timp ce Experimentation, la fel ca testarea A/B, urmărește să ofere o sursă continuă de date imparțiale, care nu este constrânsă de disponibilitatea unui analist, pentru a indica dacă fiecare caracteristică a obținut sau nu impactul dorit.
Better Together: Revizuirea inter pares, livrarea progresivă și elaborarea automată a sensurilor
De ce ne străduim să obținem fluxul? Nu este vorba de randament. Este vorba despre rezultate. Ne străduim pentru flux astfel încât să putem itera bucla de feedback a ideii -> implementare -> observare cu mai puțină fricțiune în mai puțin timp. Fie că o numiți „dezvoltare orientată spre impact” sau „dezvoltare orientată spre client”, această abordare de a ne mișca mai repede cu o mai mare (și mai rapidă) conștientizare a rezultatelor merge mult dincolo de „conducta de implementare pentru a detecta și respinge schimbările proaste” pe care echipa DORA ne-a recomandat să o combinăm cu practicile de evaluare inter pares. Da, putem detecta și respinge în mod automat schimbările proaste, dar, mai important, putem construi un proces repetabil pentru triangularea către rezultate de afaceri semnificative.
Aflați mai multe despre realizarea managementului schimbării și a fluxului, împreună, în cadrul livrării continue
- Vizionați un videoclip de patru minute despre definiția livrării continue pentru a vedea de ce dimensiunea mică a loturilor este esențială pentru realizarea unui flux consistent.
- Veziți un videoclip în profunzime cu Craig Sebenik (LinkedIn, Crunchbase, Matterport) despre beneficiile trecerii la dezvoltarea bazată pe trunk.
Căutați sfaturi de la mai multe echipe care livrează zilnic în producție în cartea electronică O’Reilly, Continuous Delivery in the Wild
Cercetați mai mult conținut excelent despre obținerea de rezultate semnificative cu livrarea de caracteristici la scară? Marcați blogul Split, verificați-ne pe YouTube sau urmăriți-ne pe Twitter @splitsoftware.
.