Ce este un flux de lucru bazat pe lansare?

Aici vom discuta cum puteți crea un flux de lucru bazat pe lansare utilizând GitHub.

Ce este un flux de lucru bazat pe lansare?

Un flux de lucru bazat pe lansare este un set de modele și politici care se concentrează pe eliberarea de software. Deși această noțiune poate părea un obiectiv evident pentru o echipă de dezvoltare, valoarea acestei perspective este mai nuanțată. În această unitate vom discuta despre modul în care se generează trei părți diferite ale ciclului de lansare: gestionarea proiectului, selectarea unei strategii de ramificare și lansarea pentru clienți.

Planificarea lucrului cu panourile de proiect GitHub

Dintr-un set de gândire de planificare, fiind centrat pe lansare înseamnă că problemele sunt împărțite în iterații distincte care produc o versiune nouă. Aceste iterații se numesc adesea sprinturiși sunt legate de timp în perioade aproximativ egale pentru a produce modificări incrementale. Alte echipe preferă să împacheteze versiuni de lansare întregi într-o singură iterație care poate dura câteva luni sau mai mult. În GitHub, aceste iterații sunt gestionate ca proiecte .

Caracteristica dominantă a unui proiect este avizier. Avizierul este planul central de înregistrare pentru iterație și conține toate fișele de care trebuie rezolvate. Un card poate reprezenta o problemă, o solicitare de extragere sau chiar doar o notă generică.

În mod implicit, fiecare fișă începe în coloana De făcut și trece la În curs după ce lucrul începe înainte de a se termina în Terminat. Puteți să particularizați aceste coloane, să adăugați mai multe coloane sau să aplicați automatizare la mișcarea acestor fișe și proprietățile acestora pentru a se potrivi procesului echipei dvs.

Aflați mai multe despre gestionarea forumurilor de proiect.

Starea proiectului cardului este integrată în depozit. De exemplu, glisarea unei fișe din Pentru a face în În curs de își modifică starea și actualizează indicatorul vizual lângă titlul proiectului. Secțiunea verde indică porțiunea de fișe marcate ca Gata, în timp ce violetul este utilizat pentru fișe În curs de. Spațiul rămas reprezintă cantitatea de cărți de vizită care nu au început încă. Pe lângă glisarea fișelor în jurul avizierului, le puteți actualiza din vizualizarea principală.

Atunci când utilizați un panou de proiect, toți participanții direct interesați au o modalitate simplă de a înțelege starea și viteza unui proiect. De asemenea, puteți crea panouri cu domeniu de aplicare pentru utilizatorii individuali sau pentru o colecție de depozite deținute de o organizație.

Aflați mai multe despre urmărirea progresului lucrului cu panourile de proiect.

Urmărirea jaloanelor specifice

Pentru echipe sau, eventual, subseturi de echipe, GitHub oferă urmărire jalon.

Jaloanele sunt similare urmăririi proiectelor, prin faptul că există un accent asupra finalizării prioritizate a problemelor și solicitărilor de tragere. Cu toate acestea, dacă un proiect poate fi focalizat pe procesul echipei, un jalon se concentrează pe produs.

Aflați mai multe despre urmărirea progresului lucrului cu jaloane.

Selectarea unei strategii de ramificare

Depozitele care au mai mulți dezvoltatori care lucrează în paralel au nevoie de o strategie de ramificare bine definită. Stabilirea unei abordări unificate la începutul proiectului salvează confuzia și frustrarea pe măsură ce echipa și scara codebase.

Fluxul GitHub

Pe lângă furnizarea unei platforme pentru dezvoltarea de software de colaborare, GitHub oferă, de asemenea, un flux de lucru predefinit proiectat să optimizeze utilizarea diverselor sale caracteristici. Deși GitHub poate lucra cu aproape orice proces de dezvoltare a software-ului, vă recomandăm să luați în considerare fluxul GitHub dacă echipa dvs. nu s-a stabilit încă pe un proces.

Lucrul cu ramuri de lungă durată

O ramură cu durată lungă de este o ramură Git care nu este ștearsă niciodată. Unele echipe preferă să le evite cu totul în favoarea caracteristicilor scurte și a ramurilor de remediere a erorilor. Pentru aceste echipe, obiectivul oricărui efort este de a produce o solicitare de tragere care îmbină munca lor înapoi în main. Această abordare poate fi eficientă pentru proiecte care nu trebuie niciodată să se uite înapoi, cum ar fi aplicații web principale care nu acceptă o versiune anterioară.

Cu toate acestea, există anumite scenarii în care o ramură pe termen lung servește cele mai bune interese ale unei echipe. Cel mai comun caz pentru o ramură lungă este atunci când un produs are mai multe versiuni care trebuie acceptate pentru o perioadă lungă de timp. Atunci când o echipă trebuie să planifice acest angajament, depozitul trebuie să respecte o convenție standard, cum ar fi release-v1.0, release-v2.0și așa mai departe. Aceste ramuri ar trebui, de asemenea, să fie marcate ca protejate în GitHub, astfel încât accesul la scriere să fie controlat și să nu poată fi șterse accidental.

Teams ar trebui să păstreze în continuare main ca ramură rădăcină și să îmbine ramura lor de lansare se modifică în amonte atât timp cât se încadrează în viitorul proiectului. Când vine timpul, release-v3.0 ar trebui să se bazeze pe main astfel încât serviciile pentru release-v2.0 nu complică depozitul.

Ramuri de servicii cu durată lungă de viață

Să presupunem că s-a îmbinat o remediere a erorilor în ramura release-v2.0, apoi îmbinată din nou în amonte în main. Apoi a fost descoperit mai târziu că această eroare a existat, de asemenea, în ramura release-v1.0 și remedierea necesară pentru a fi backportată pentru clienții care încă utilizează acea versiune. Care este cea mai bună modalitate de a backporta această remediere?

Îmbinarea ramurii main în release-v1.0 nu ar fi o opțiune fezabilă, deoarece ar conține un număr semnificativ de comiteri care nu au fost menite să facă parte din versiunea respectivă. Din același motiv, rebasarea release-v1.0 pe comiterea curentă main nu ar fi o opțiune.

O opțiune alternativă ar fi să reimplementați manual remedierea pe ramura release-v1.0, dar această abordare ar necesita mult lucru și nu scala bine în mai multe versiuni. Totuși, Git oferă o soluție automată pentru această problemă sub forma comenzii sale de cherry-pick.

Ce este comanda Git-pick de cireș?

git cherry-pick este o comandă care vă permite să aplicați anumite comiteri dintr-o ramură în alta. Aceasta pur și simplu iterează comiterile selectate și le aplică la ramura țintă ca noi comiteri. Dacă este necesar, dezvoltatorii pot îmbina conflicte înainte de a finaliza backportul.

Aflați mai multe despre de cireș Git.

Eliberarea către consumatori

Atunci când o versiune de produs este gata de lansare, GitHub simplifică procesul de împachetare și notificare a consumatorilor.

Crearea unei versiuni este la fel de simplă ca completarea formularului:

• Introduceți o etichetă Git de aplicat, care ar trebui să urmeze de versiuni semantice, cum ar fi v1.0.2. GitHub gestionează procesul de creare a etichetei Git pe care o specificați.
• Introduceți un nume pentru lansare. Printre practicile comune se numără:
  • Utilizați un nume descriptiv
  • Utilizarea versiunii Git
  • Utilizați un rezumat concis al modului în care s-a modificat versiunea de la versiunea anterioară
  • Utilizarea unui nume de cod sau a unei expresii aleatoare
• Furnizați note privind versiunea. Puteți automatiza această activitate cu aplicației Release Drafter, care analizează modificările de la versiunea anterioară și include titlurile de solicitare de extragere asociate.
• Dacă doriți să furnizați fișiere ca parte a lansării, cum ar fi programele de instalare predefinite, puteți să le glisați și să le fixați în formular. Nu trebuie să împachetați sursa ca ghidaje GitHub pentru dvs.
• Indicați dacă versiunea este prerelează bifând acea casetă. Acest indiciu îi ajută pe clienți să evite versiunile prerelease dacă doresc.

După ce se publică o lansare, toți cei care urmăresc depozitul primesc o notificare.

Aflați mai multe despre versiunile GitHub.