Ghid: Gestionarea lansării software-ului pentru echipe mici

Formalizarea procesului de management al lansărilor (dacă există)

În unele configurații de echipă, în special în cele care se găsesc în startup-uri, nu există DevOps, nici ingineri de infrastructură, care să ofere suport la lansarea unei noi versiuni a produsului.

Mai mult, spre deosebire de marile companii birocratice cu procese formale definite, echipa CTO sau șeful de dezvoltare software dintr-un startup nu este adesea conștientă de complexitatea procesului de gestionare a lansării de software; câțiva dezvoltatori din companie pot fi conștienți de detaliile complexe ale procesului, dar nu toată lumea. Dacă aceste cunoștințe nu sunt documentate în detaliu , cred că ar putea duce la confuzie.

În acest articol, voi încerca să ofer câteva sfaturi despre cum să formalizezi procesul de lansare, în special din punctul de vedere al dezvoltatorului.

Introduceți Lista de verificare pentru lansarea software-ului

S-ar putea să fiți familiarizați cu ideea unei liste de verificare pentru unele operațiuni, conform Manifestului Listei de verificare, o carte de Atul Gawande. Cred că un proces formal de lansare (ca multe alte sarcini din lumea dezvoltării software) oferă dezvoltatorilor posibilitatea de a implementa acest protocol. O listă de verificare a procesului de lansare ar trebui păstrată într-un document comun, de preferință sub forma unui wiki colaborativ sau a unei foi de calcul pe Google Drive.

Prin partajarea acestui document vital cu echipa și prin acordarea permisiunilor de editare, fiecare membru are acces la procesul de lansare definit oficial. Acest lucru le permite să înțeleagă cum funcționează procesul. În plus, în urma discuțiilor cu alți membri ai echipei, dă putere echipei să-și îmbunătățească din când în când. Acest lucru ar trebui să aducă transparență și să permită întregii echipe să aibă acces în timp real la ceea ce se întâmplă în timpul lansării, ce pași au fost parcurși și de către cine.

Privind această foaie de calcul, părțile interesate pot decide între „GO” și „NU GO”, în funcție de rezultatul pașilor. De exemplu, dacă un test de stres nu merge bine într-un mediu de testare, în funcție de eveniment, managerul de proiect ar putea decide să anuleze lansarea de producție.

Pași sugerați de utilizat ca fundație

În această secțiune, voi propune câțiva pași pe care îi puteți folosi pentru a vă crea propria listă de verificare pentru procesul de lansare. Unii dintre acești pași nu sunt deloc obligatorii . Fiecare aplicație este diferită și fiecare organizație funcționează într-un mod diferit, așa că nu ezitați să vă adaptați și să faceți modificări care se vor potrivi mai bine în fluxul dvs. de lucru.

1. Creați o ramură de lansare

Probabil că sunteți familiarizat cu conceptul de Git Workflow sau cu ideea de ramuri de lansare, subiect care a fost explicat într-o postare anterioară pe blog.

În mod ideal, ar trebui să aveți cel puțin trei ramuri:

• master : aceasta ar trebui să reflecte starea actuală a ceea ce este în mediul de producție. Fiecare nou commit pe master ar trebui să cuprindă doar o nouă ediție.
• dezvolta : această ramură ar trebui să conțină caracteristicile viitoare finalizate (și testate). Este obișnuit să creați o ramură separată pentru fiecare caracteristică și apoi să o îmbinați pentru a se dezvolta când caracteristica este gata.
• lansare : ramurile de lansare sunt o colecție de comite-uri care sunt gata să fie trimise în producție, plus câteva remedieri suplimentare de erori minore legate de lansare.

Observați că ramurile de lansare ar trebui eliminate odată ce lansarea este finalizată, prin urmare aceste ramuri sunt create și distruse tot timpul, spre deosebire de master sau develop , care sunt întotdeauna aceleași.

Pentru a crea o nouă ramură de lansare , din ramura de dezvoltare din terminalul git, tastați:

$ git checkout -b release/xyz

Este convenabil să folosiți o convenție de denumire, cum ar fi cea definită mai sus, înlocuind xyz cu numărul versiunii major.minor.patch în funcție de nevoile dvs. (este o politică pe care ar trebui să o definiți în cadrul echipei și să o respectați).

Este important să spunem, de asemenea, că, dacă codificați unele remedieri de erori în ramura de lansare, nu ar trebui să uitați să le îmbinați înapoi pentru a dezvolta . Scopul principal al ramurii de lansare este de a avea o previzualizare instantanee a modului în care ar trebui să se comporte aplicația după ce intră în producție.

2. Bump Version

Următorul pas ar fi să ridicați (modificați sau măriți) numărul versiunii pe ramura de lansare .

Ar trebui să deschideți AndroidManifest.xml / package.json / pom.xml / sau oriunde este stocată versiunea aplicației în proiectul dvs. (YMMV), să actualizați numărul versiunii și apoi să efectuați modificările în ramura ediției curente.

Este important să actualizați numărul versiunii din două motive.

În primul rând, puteți urmări și mapa caracteristicile care au fost introduse în fiecare versiune și, în al doilea rând, veți fi conștienți de versiunea pe care o folosesc în cazul în care trebuie să depaneze unele probleme sau să vă contacteze pentru asistență. Dacă construiți o aplicație mobilă, numărul versiunii pe care o actualizați în acest pas este de obicei afișat la nivelul utilizatorului, în secțiunea Despre sau în Google Play sau Apple App Store . Acest pas este, de asemenea, o bună oportunitate de a actualiza în funcție de mediu. -fișierele de configurare (deși aș sugera să le păstrați într-un depozit separat), cum ar fi să faceți ramificația către baza de date de producție sau orice alte modificări necesare în procesul de construire.

În cele din urmă, se recomandă să împingeți ramura de lansare la origine, astfel încât să fie disponibilă pentru ceilalți dezvoltatori:

$ git push -u origin release/xyz

3a. Îmbinați ramura de lansare pentru a stăpâni și etichetați-o

Doar ramura master ar trebui să fie implementată pentru producție, prin urmare, în acest pas, trebuie să îmbinăm ramura de lansare în master .

 $ git checkout master $ git merge --no-ff release/xyz $ git push

Indicatorul --no-ff este opțional, totuși, utilizarea sa este recomandată pentru a forța crearea unui nou obiect de comitere, chiar dacă îmbinarea poate fi finalizată folosind tehnica de avansare rapidă.

Apoi, este timpul să etichetați lansarea pe ramura principală :

$ git tag -a xyz -m 'description of new version, features or fixes included'

Etichetele sunt utile deoarece persistați acest punct specific din istorie în depozitul git și puteți reveni mai târziu pentru a recrea o ramură separată dintr-o anumită etichetă.

3b. Utilizați o cerere de extragere pentru a îmbina ramura de lansare

O altă alternativă folosită des este utilizarea unei cereri de extragere pentru a îmbina ramura de lansare în master .

Există numeroase avantaje ale acestei abordări. Este creat un nou spațiu pentru colaborare, pe care echipa îl poate folosi pentru a discuta diverse probleme legate de lansare. Acest punct este un moment bun pentru a adăuga o poartă suplimentară pentru încorporarea unui proces de revizuire a codului, având în același timp mai mulți ochi pentru a monitoriza codul care va fi introdus și pentru a discuta eventualele modificări.

Unele instrumente care vă permit să implementați solicitări de extragere în fluxurile dvs. de lucru sunt GitHub, Bitbucket și GitLab (solicitare de îmbinare așa cum o numesc ei pe ultimul). Cu aceste instrumente, nu tastați manual comenzile git, în schimb, utilizați o interfață web pentru a seta ramura sursă ( release ) și ramura destinație ( master ), apoi adăugați unul sau mai mulți recenzenți, toți care vor să poată scrie comentarii inline cu privire la aceste noi modificări, să sugereze îmbunătățiri și așa mai departe.

După ce toți recenzenții aprobă cererea de extragere, puteți îmbina automat modificările în master apăsând un buton de pe interfața de utilizare.

4. Implementați Master în mediul de producție

Este o practică bună, în această etapă, ca un tester din echipa ta să facă un test de fum (acest lucru ar putea fi definit într-o listă de verificare separată) înainte de a implementa aplicația. O sugestie bună este să implementați ramura principală într-un mediu de testare separat. Testerul poate efectua apoi câteva acțiuni de bază pentru a se asigura că nimic nu a mers prost după îmbinare la cea mai recentă versiune. Cum se efectuează un test de fum este în afara domeniului acestui articol, dar puteți găsi o mulțime de materiale pe web despre acesta. Rezultatul testului de fum poate fi integrat în lista de verificare/foaia de calcul pentru eliberare, documentând orice a mers prost.

În acest moment, sunteți gata să implementați modificările și să le puneți în aplicare. Continuați și implementați ramura principală . Acest pas va depinde de stiva de infrastructură pe care o utilizați. Ar putea implica conectarea la instanța dvs. Amazon EC2 pentru a vă încărca aplicația sau împingerea către o telecomandă Heroku sau conectarea prin ssh la VPS-ul dvs. pentru a copia noua versiune sau orice alt proces.

După ce aplicația este încărcată, asigurați-vă că a fost implementată cu succes și că funcționează conform așteptărilor.

5. Îmbinați înapoi în Develop And Delete Release Branch

Acum lansarea este aproape finalizată, veți dori să fuzionați ramura de lansare în develop , să actualizați numărul versiunii pe acesta din urmă și să transferați toate remediile de erori făcute în ramura principală de dezvoltare:

 $ git checkout develop $ git merge release/xyz

Acum este timpul să eliminați ramura de lansare :

$ git branch -d release/xyz

6. Generarea jurnalului de modificări

Ar trebui să existe un fișier la rădăcina proiectului dvs. numit CHANGELOG.md (sau un echivalent) unde ar trebui să adăugați o nouă intrare ori de câte ori există o nouă ediție pentru a documenta tot ceea ce este inclus în acesta, cum ar fi remedieri de erori, caracteristici noi, probleme cunoscute și orice alte informații relevante sub formă de note de lansare. Acest lucru este cu adevărat util pentru utilizatori și colaboratori pentru a vedea ce modificări au fost făcute între fiecare lansare (sau versiune) a proiectului.

Intrarea din jurnalul de modificări include data, numărul versiunii și câteva note despre lansare. Înregistrările trebuie păstrate în ordine cronologică inversă. Iată un șablon simplu pe care l-am folosit pe care îl puteți adapta la proiectul dvs.:

 <app's name or component released> <version xyz> | <date> <developer's name in charge of release> | <developer's email> Features: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Bugs fixed: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Enhancements: * <ticket/issue number>: <ticket/issue summary> (<link to issue tracker>) * ... Optional: known issues plus other release notes.

În plus, acest pas poate fi complet automatizat fie prin codificarea unui script de bază care traversează jurnalul git și generează automat intrarea în jurnalul de modificări, fie prin utilizarea unui instrument care face același lucru, cum ar fi:

• Github Changelog Generator, de la skywinder,
• ReadmeGen de fojuth
• github-changes, de lalitkapoor

Rețineți, totuși, că gradul de automatizare pe care îl obțineți este direct proporțional cu strictețea formatului mesajului dvs. de confirmare. Cred că este întotdeauna o bună practică să convini cu echipa asupra unui format specific pentru mesajele de confirmare. Urmând instrucțiunile cu privire la stilul mesajelor de confirmare, acestea vor fi mai ușor de analizat și, prin urmare, mai probabil că veți putea automatiza generarea jurnalului de modificări.

7. Comunicați cu părțile interesate

Aici ați face de obicei unele dintre următoarele:

• Informați echipa printr-un instrument intern de mesagerie (de exemplu: Slack) că o nouă versiune a fost finalizată. Recomand să creați un canal nou (adică: #lansări ) cu scopul exclusiv de a comunica evenimente legate de lansare. Este ușor să adăugați cârlige într-un canal Slack pentru a posta un mesaj după ce a fost întreprinsă o acțiune.
• Alternativ, trimiteți un e-mail părților interesate cu un link către jurnalul de modificări sau fișierul jurnalului de modificări atașat.
• Scrieți o postare pe blog (dacă aveți un blog pentru aplicația sau produsul dvs.) sau un tweet.

Mai multe acțiuni pot fi întreprinse în funcție de natura organizației dvs. Important este să nu uitați să comunicați că este disponibilă o nouă versiune a produsului dumneavoastră.

8. Grooming The Issue Tracker

După ce o lansare este executată, probabil că va trebui să actualizați starea unora dintre biletele dvs. pentru a ține evidența remediărilor de erori sau a caracteristicilor, în prezent în producție. În general, acest lucru implică schimbarea unor etichete (pentru proiecte mici folosesc o etichetă de lansare în așteptare , pe care o elimin după ce lansarea este finalizată).

Dacă utilizați repere pentru fiecare versiune nouă, probabil că va trebui să le actualizați starea sau să le marcați ca finalizate. Unele instrumente de urmărire a problemelor vă permit chiar să planificați lansarea și să o aliniați cu sprinturile, să urmăriți dacă o eroare blochează o lansare și alte informații utile.

Totul depinde de modul în care utilizați instrumentul. Vreau pur și simplu să subliniez că sarcina de a actualiza informațiile din instrumentul de urmărire a problemelor ar trebui inclusă în lista de verificare a versiunii.

Despre automatizarea procesului de lansare

Cititorul s-ar putea să fi observat că, în afară de pasul de jurnal de modificări descris mai sus, mulți dintre pașii menționați mai sus pot fi și automatizați.

Abilitatea de a automatiza unele părți ale procesului de lansare este un câștig uriaș și economisește mult timp. Vă sugerez să creați scripturi sau să aflați cum să automatizați pașii individuali și apoi să lucrați către un obiectiv de livrare continuă. Livrarea continuă poate reduce riscul, poate reduce costurile și poate reduce timpul pe care dezvoltatorii trebuie să-l petreacă în gestionarea lansării. În consecință, veți putea elibera mai des și veți fi mai productiv în ceea ce privește orele alocate pentru dezvoltare.

Sfântul Graal al companiilor DevOps este de a putea lansa o nouă versiune apăsând un buton (sau rulând o comandă) care ar declanșa procesul de lansare automat, sau chiar mai bine, un sistem care ar lansa o nouă versiune a software-ului dvs. ora desemnată. Desigur, acest lucru este dificil de realizat, deoarece trebuie să automatizați o mare parte din procesul de testare, dar nu este imposibil.

Îmbrățișarea celor mai bune practici

În această secțiune, voi descrie câteva practici recomandate pe care le-am considerat convenabile, fie pentru a face procesul de lansare mai ușor, fie pentru a lua măsuri de siguranță în cazul în care ceva nu merge bine.

Găsiți ziua cea mai potrivită pentru a realiza lansarea

De obicei, lansez aplicații la care lucrez joia, între prânz și închiderea activității.

Dacă lucrați de luni până vineri, nu este o idee bună să lansați vineri. Dacă ceva se defectează după lansare, nu veți avea timp să îl reparați până luni (cu excepția cazului în care doriți să lucrați în weekend). De aceea este mai convenabil să faci lansări joi, pentru că ai la dispoziție vineri să monitorizezi noua versiune după implementare, să remediezi orice probleme sau să faci un rollback.

Un alt lucru important de menționat dacă gestionați o aplicație web este să cunoașteți fusul orar în care se află majoritatea utilizatorilor dvs. Ar trebui să programați eliberarea într-o perioadă de trafic redus pentru a minimiza daunele potențiale în cazul în care ceva nu reușește. Uneori, acest lucru poate fi dificil atunci când baza dvs. de utilizatori este răspândită în întreaga lume, dar oricum, ar trebui să faceți câteva cercetări și să decideți cel mai bun moment.

Faceți o copie de rezervă a bazei de date înainte de o nouă lansare

Dacă nu aveți programate copii de rezervă periodice ale bazei de date, vă sugerez insistent să adăugați un pas în procesul de lansare pentru a efectua o copie de rezervă înainte de a începe lansarea.

Lansări în etape

Te-ai întrebat vreodată de ce, când un editor anunță că a lansat o nouă funcție, durează zile sau chiar săptămâni pentru ca această funcție să fie disponibilă pe telefonul tău? Asta pentru că multe companii folosesc lansări în etape.

Facebook face asta de mult timp. Testează o nouă caracteristică pe cinci sau 10% dintre utilizatorii săi, crescând-o treptat până când ajung la 100% din baza de utilizatori. În timpul etapei de lansare, va trebui să analizați cu atenție feedbackul utilizatorilor și rapoartele de blocare. Cu aceste informații, puteți amâna lansarea sau puteți remedia erorile înainte ca acestea să afecteze fiecare utilizator.

Există un instrument drăguț pe Consola pentru dezvoltatori Android care implementează lansări în etape pentru aplicațiile dvs. Android.

Integrare continuă

Integrarea continuă este o practică care merită îmbrățișată din mai multe motive. În primul rând, vă permite să detectați greșelile din timp, crescând rata versiunilor de succes. În al doilea rând, este primul pas logic înainte de implementarea livrării continue și a automatizării complete, așa cum a fost descris anterior.

Martin Fowler este un mare susținător al integrării continue. El descrie o cantitate imensă de beneficii care pot fi adăugate procesului tău de eliberare atunci când folosești această practică. Acesta este un subiect amplu și există multe cărți și postări pe blog despre el și îl menționez aici pentru că cred că vă va oferi mult mai multă încredere în operațiunile dvs. Printre numeroasele avantaje ale utilizării CI, veți găsi: risc redus, vizibilitate crescută pentru a fi conștient de ceea ce funcționează și ce nu, detectarea mai devreme a erorilor, frecvența crescută a implementărilor și multe altele.

Punctul de plecare pentru implementarea CI este configurarea unui „server de integrare continuă”; Câteva instrumente frumoase de încercat sunt: ​​CruiseControl, Bamboo, Jenkins și Travis.

Exitlude: Totul se va rezolva

Agresiv, apărăm cu toții rolul pe care îl jucăm Din păcate, vin vremurile să te trimită pe drumul tău Am văzut totul, focuri de încredere, inundații fulgerătoare de durere Nu contează cu adevărat, nu-ți face griji, va totul merge bine

Exitlude, The Killers

În concluzie, aș spune că este foarte important să aveți un proces de lansare bine definit pentru aplicația dvs., indiferent de complexitatea acesteia, baza de utilizatori sau cât de mică este organizația dvs.

Dacă nu, vă sugerez să începeți să vă gândiți la câțiva pași de bază, să folosiți acest ghid și altele asemănătoare și să faceți brainstorming cu echipa dvs. pentru a veni cu o primă schiță. Încercați-l la următoarea versiune, apoi repetați. În cele din urmă, vei ajunge să-ți construiești propriul proces de lansare.

După aceea, începeți să vă gândiți la cum să automatizați părți ale procesului . Gândiți-vă la domeniile care pot fi îmbunătățite. Explorați modalități de reducere a timpului de lansare prin încorporarea unor mici optimizări. Automatizarea ar trebui să fie scopul tău final; totuși, nu planifica asta de la început, altfel vei eșua încercând un salt atât de mare. Ca în cazul oricărui proces, este mai bine să îl îmbunătățiți treptat.

Aveți alte trucuri sau instrucțiuni pe care le utilizați pentru a lansa versiuni noi ale aplicației dvs.? Dacă da, anunțați-mă. Nu provin din lumea DevOps, sunt doar un dezvoltator care se întâmplă să fie destul de organizat și structurat, dar, în comparație cu mulți veterani, sunt încă novice în acest sens, așa că nu ezitați să comentați sau să mă contactați dacă aveți ceva de adaugat.