Când vine vorba de livrarea scrumului, oamenii se așteaptă de obicei la o execuție de lansare după încheierea unui sprint. Aceasta înseamnă imediat după o prezentare demonstrativă de succes către client.
Dar mereu m-am întrebat cum ar putea fi aceasta o așteptare atât de automată. Mai ales dacă luați în considerare următoarele activități posibile care trebuie să aibă loc înainte sau alături.
- Dezvoltați și finalizați toate poveștile din sprint. Unele ar putea fi finalizate mai devreme, dar de cele mai multe ori, poveștile sunt finalizate chiar înainte de sfârșitul sprintului. Poate chiar și după prezentarea demo, să fie deschisă aici.
- Efectuați toate testele programate asupra conținutului de sprint pentru a vă asigura că codul care urmează să fie lansat este gata de producție.
- Reveniți din urmă cu erorile descoperite și remediați-le la timp înainte de lansarea.
- Asigurați-vă că canalul de implementare este actualizat cu cel mai recent conținut și că canalul în sine este fiabil de executat.
- Rulați pipeline în toate mediile relevante pentru a le aduce în cea mai recentă stare din perspectiva codului, precum și a datelor.
- Pregătiți note de lansare și comunicați cu clientul impactul lansării și ce anume se va schimba ulterior.
- Dacă este relevant, sincronizați-vă cu alte echipe scrum paralele pentru a vă asigura că conținutul dependent va fi lansat simultan. Nu trebuie să lipsească nimic pentru a vă asigura că conținutul lansării va funcționa conform așteptărilor.
- Pe lângă toate acestea, treceți prin toate ceremoniile scrum. Nu numai legate de sprintul curent, ci și de cele vizate pentru următorul sprint (de exemplu, sesiuni de rafinare a poveștilor).
Acum imaginați-vă că sprintul are două săptămâni.
Activitățile de eliberare în sine necesită timp și oamenii pentru a le finaliza. Dar nu poate dura prea mult. Imediat după ultima zi a sprintului vine direct prima zi a următorului sprint, iar cercul va începe din nou.
Mai pare atât de automată așteptarea eliberării după fiecare sprint?
Cuprins
Eliberați Procesarea conținutului
Dacă toate procesele din sprint sunt automatizate, există posibilitatea de a „apăsa declanșatorul” și de a instala cea mai recentă versiune de cod în producție la sfârșitul fiecărui sprint. Problema este că nu am experimentat niciodată o stare atât de perfectă a echipei scrum.
Dacă de fapt este cazul în unele afaceri private la scară mică, chiar le invidiez. Dar realitatea în lumea corporativă este că o echipă scrum nu va atinge acel nivel de maturitate. Dimpotrivă, procesele de lansare sunt de obicei conectate cu activități consumatoare de timp care ajung la majoritatea sprintului următor, afectând acel sprint din punct de vedere al conținutului și al tuturor valorilor. Eliberarea este doar un act stresant prin care nimeni din echipă nu este fericit să treacă.
Așa că am fost după ce am descoperit următorul cel mai bun scenariu pentru a face față lansărilor.
Concluzia a fost să facem în fiecare secundă sprintul Release Sprint. Iată ce înseamnă.
Versiune de cod separată pentru următoarea ediție
Este vorba despre gestionarea ramurilor separate în depozitul GIT. Există multe moduri de a aborda aceeași problemă și toate pot avea succes. Dar în scopul acestui articol, voi păstra lucrurile simple pentru a demonstra abordarea și impactul acesteia.
Pentru a avea un impact cât mai scăzut posibil asupra activităților de dezvoltare în curs, este important să separați conținutul pentru următoarea ediție într-o ramură separată. Să-i spunem Release Branch. Prin aceasta se vor rezolva următoarele:
- Echipa de dezvoltare poate continua activitățile și se poate îmbina în noile povești ale filialei principale fără întreruperi.
- Nu există niciun risc ca conținutul lansării să fie afectat de modificări neașteptate ale codului din partea echipei Scrum.
- Activitățile de testare pot fi executate într-un spațiu izolat. Aici vor fi introduse doar modificările necesare pentru rezolvarea testării.
- Deoarece canalul de lansare va implementa în producție numai conținutul din filiala de lansare, avem un proces clar și control deplin asupra conținutului care urmează să fie lansat. Nu se poate întâmpla ca o comitere neașteptată în ramura Git să spargă codul deja testat.
Așa că păstrați conținutul următoarei versiuni deoparte și lăsați-l să se încheie într-o stare stabilă, gata de lansare.
Programează lansările astfel încât să funcționeze în mod repetat
Am renunțat la ambiția de a face lansarea după ce fiecare sprint a fost finalizat. Era foarte clar că nu ar avea nicio șansă să funcționeze. Cel puțin nu cu efecte secundare precum:
- influențând următorul conținut de dezvoltare de sprint,
- neputând stabiliza conținutul lansării,
- atingerea tuturor activităților de testare necesare etc.
Deci, scopul a fost să execute lansarea până la sfârșitul fiecărei secunde de sprint. Asta ar implica următoarele:
- O lansare va conține întotdeauna povești din ultimele două sprinturi deja terminate. Deoarece lansarea este efectuată în cadrul curentului (sprint activ), acest conținut de sprint nu este încă inclus în ediție.
- Există un timp întreg de un singur sprint pentru ca activitățile de testare necesare și remedierea erorilor să fie finalizate.
- Proprietarul lansării are suficient timp pentru a strânge informații relevante pentru lansare (cazuri de testare, note de lansare etc.) cu sprintul non-lansare. În acest fel, ei pot funcționa practic de sine stătătoare și pot menține restul echipei de dezvoltare să lucreze la noi povești.
- În caz de descoperire a erorilor, proprietarul versiunii se poate conecta rapid cu dezvoltatorul concret pentru a remedia problema și a reveni la conținutul curent de sprint. Deci, ar trebui să existe întotdeauna un procent de timp alocat din capacitatea echipei de a sprijini această remediere a erorilor. Cât de mult se poate descoperi în timp.
Este clar că utilizatorii nu vor primi cel mai recent conținut de sprint în cea mai recentă versiune. Dar în timp, acest lucru va deveni irelevant. Oricum, vor primi două sprinturi de conținut cu fiecare lansare următoare, după fiecare sprint al doilea.
Acesta pare un compromis bun între satisfacția cu livrarea rapidă și menținerea pasului cu activitățile scrum fără perturbări semnificative.
Executați implementarea lansării
Când activitățile de testare, de remediere a erorilor și de pregătire a conductei sunt finalizate cu succes, este un proces destul de simplu de a executa conducta de producție și de a finaliza lansarea în producție.
Deoarece este implementat dintr-o ramură independentă, aceasta poate fi practic o activitate neobservată și invizibilă. Nimeni nu trebuie să știe. Dacă acesta este cazul, este cea mai bună implementare posibilă a implementării lansării.
O condiție prealabilă pentru aceasta este să fi creat o conductă DevOps automată solidă. Nu este folosit doar pentru implementarea în mediul de producție, ci și în toate celelalte medii de nivel inferior. Aceasta poate include dezvoltarea, sandbox, test, asigurarea calității, mediu de performanță etc. Acesta va fi un singur clic pentru a implementa toate soluțiile pentru fiecare mediu.
Eliberarea nu ar trebui să fie un punct de durere sau stres. Sau un coșmar de care toată lumea se teme și continuă să se pregătească pentru acea zi timp de o săptămână. Nu – în schimb, dacă nimeni nu observă deloc acest lucru, acesta este cel mai bun semn al unei lansări de succes.
Îmbinați înapoi filiala de lansare în filiala de dezvoltare
Ramura de lansare conține acum un conținut special care nu există în ramura obișnuită de dezvoltare continuă. Este legat de toate corecțiile care au fost implementate în perioada de testare. Acest conținut trebuie să fie îmbinat înapoi în ramura de dezvoltare pentru a se asigura că remediile vor rămâne acolo chiar și după următoarea lansare.
În acel moment, cea mai recentă filială de lansare servește ca un cod de producție de urgență gata de reimplementare. Dacă o problemă urgentă cu prioritate ridicată trebuie rezolvată la scurt timp după implementarea producției, poate folosi această ramură. Este simplu să luați acest cod și să implementați remedierea în interior. Aceasta este încă copia exactă a codului de producție actual, fără niciun conținut nou nelansat.
În cele din urmă, odată ce începe noua perioadă de testare, ramura de lansare anterioară poate fi ștearsă și înlocuită cu una nouă. Cel nou este din nou creat ca o copie din ramura actuală de dezvoltare.
Stabiliți lansări regulate
Și acum îl avem 😀—un proces solid pentru abordarea lansării. Singurul lucru care lipsește este angajamentul de a-l menține regulat. În acest caz, după fiecare secundă de sprint.
Păstrând-o în mod regulat, am pregătit terenul pentru a face mai ușor de realizat, în principal pentru că:
- Dacă lansarea are loc după un timp nu prea lung, nu există atât de mult conținut nou de instalat în producție. Creșterea este mică și considerată stabilă.
- Acum atât de mult conținut nou înseamnă că nu există o mulțime de activități de testare și crearea de cazuri de testare. Mai puține comunicări, apeluri de acord și colaborare cu părțile interesate despre ceea ce trebuie revalidat. De asemenea, vor fi de acord că nu a trecut atât de mult de la ultima lansare. Deci, se pune mai puțină importanță acestei acțiuni.
- Echipa se va obișnui cu acest ciclu; în timp, va fi o parte firească a echipei.
- Ca efect secundar, mediile de dezvoltare și testare primesc adesea date reîmprospătate. Acest lucru este oricum necesar pentru fiecare nou ciclu de testare. Deci nu va fi doar o altă activitate programată de făcut. Mai degrabă, o acțiune care face deja parte din procesul stabilit. Această schimbare de perspectivă are atât de multă influență asupra atmosferei echipei. Nu s-ar crede asta.
Concluzie
Acest capitol încheie postările mele anterioare despre tema ciclului de viață scrum. De asemenea, este vorba despre ceea ce s-a dovedit a funcționa în viața reală.
Adesea, echipele încep modul agil și fac multe lucruri greșit. Apoi evoluează, în cele din urmă, și încep să facă lucrurile diferit. Această serie i-ar putea ajuta pe unii dintre ei să facă această schimbare mai rapid.
Nici această abordare de lansare nu este singura viabilă și nici nu este fără probleme. Acestea vor mai exista, iar echipele trebuie să se ocupe de ele. Apoi îmbunătățiți ceea ce este posibil și uitați ceea ce nu are sens.
Dar din câte știu, această abordare, deși simplă, a dovedit că schimbarea este posibilă. De la sprinturi haotice, imprevizibile, la livrare mai stabilă, cu lansări regulate pe care te poți baza și pe care te poți planifica. Și nu necesită o metodologie specială, extrem de complicată – doar reguli simple și dorința de a urma planul.