Versiunea 13.4 a fost lansată cu stocarea HashiCorp pentru variabile CI, agent Kubernetes și centru de securitate, precum și funcții comutabile în Starter
La GitLab, ne gândim mereu la modul în care putem ajuta utilizatorii să reducă riscurile, să îmbunătățim eficiența și să îmbunătățim viteza de livrare pe platforma ta preferată. Luna aceasta am adăugat o mulțime de funcții noi utile care extind capacitățile de securitate, reduc numărul de vulnerabilități, măresc eficiența, simplifică lucrul cu GitLab și vă ajută echipa să ofere funcții și mai rapid. Sperăm că veți găsi utile principalele caracteristici ale versiunii, precum și 53 de alte funcții noi, adăugat în această versiune.
Caracteristici avansate de securitate
Încercăm să adăugăm mai multe funcții noi la GitLab DevSecOps în fiecare lună, iar această versiune nu face excepție. în cadrul asamblarii și desfășurării. În plus, organizațiile care doresc să accepte separarea responsabilităților de implementare a codului pot acum . Acest rol corespunde și vă va permite să confirmați cererile de îmbinare (în localizarea rusă a GitLab „cereri de îmbinare”) și să implementați codul în medii protejate, fără a oferi acces pentru a schimba codul în sine.
O altă modalitate de a reduce riscurile este să folosești noi . Echipele de operațiuni pot implementa clustere Kubernetes din GitLab fără a fi nevoite să-și expună clusterul la întregul internet. De asemenea, introducem suport pentru controlul automat al versiunilor pentru noile fișiere de stare Terraform cu pentru a sprijini conformitatea și ușurința depanării. În cele din urmă, tabloul de bord de securitate al instanței a devenit cu rapoarte de vulnerabilitate și setări de securitate.
Lucru mai convenabil și mai eficient cu GitLab
Ne-am îmbunătățit căutarea globală pentru a include , permițându-vă să navigați cu ușurință la cele mai recente bilete, grupuri, proiecte, setări și subiecte de ajutor. Suntem încântați să anunțăm că GitLab Pages pentru a redirecționa pagini și directoare individuale în cadrul site-ului, ceea ce va permite utilizatorilor să își implementeze site-urile mai eficient. Și pentru cei care ar dori să primească informații extinse despre implementare, această versiune permite !
Contribuții open source
Suntem prezenti pe care l-am adăugat . Semnele privind acoperirea testului unitar a codului modificat oferă dezvoltatorilor o idee clară despre acoperirea codului în timpul revizuirii; aceste informații ajută la accelerarea recenziilor și la reducerea timpului pentru fuzionarea și implementarea codului nou. Și noi, de asemenea și planifică .
Și acesta este doar începutul!
Ca întotdeauna, există prea puțin spațiu în prezentarea generală, dar există o mulțime de caracteristici interesante în versiunea 13.4. Iată încă câteva:
- .
Dacă vrei să știi dinainte ce te așteaptă în următor eliberează, aruncă o privire .
.
luna aceasta -
Fabio a contribuit semnificativ в - o caracteristică care a fost așteptată de foarte mult timp în comunitatea GitLab. Aceasta este o contribuție cu adevărat importantă cu schimbări non-triviale care au necesitat colaborarea constantă cu membrii echipei GitLab și au afectat multe domenii ale proiectului, cum ar fi UX, front-end și back-end.
Principalele caracteristici ale versiunii GitLab 13.4
Utilizați cheile HashiCorp Vault în joburile CI
(PREMIUM, ULTIMATE, ARGINT, AUR)
În versiunea 12.10, GitLab a introdus capacitatea de a primi și transfera chei la joburi CI folosind gestionarea de joburi GitLab (GitLab runner). Acum ne extindem , adăugând o nouă sintaxă secrets la dosar .gitlab-ci.yml. Acest lucru va facilita configurarea și utilizarea depozitului HashiCorp cu GitLab.
и .
Vă prezentăm agentul GitLab Kubernetes
(PREMIUM, ULTIMATE)
Integrarea GitLab cu Kubernetes a făcut de mult posibilă implementarea în clustere Kubernetes fără a fi nevoie de configurare manuală. Mulți utilizatori le-a plăcut ușurința în utilizare a acestui pachet, în timp ce alții au întâmpinat unele dificultăți. Pentru integrarea curentă, clusterul dumneavoastră trebuie să fie accesibil de pe Internet pentru ca GitLab să îl acceseze. Pentru multe organizații, acest lucru nu este posibil deoarece restricționează accesul la clustere din motive de securitate, conformitate sau reglementări. Pentru a ocoli aceste restricții, utilizatorii trebuiau să-și construiască instrumentele pe deasupra GitLab, altfel nu ar putea folosi această funcție.
Astăzi vă prezentăm agentul GitLab Kubernetes, o nouă modalitate de implementare în clustere Kubernetes. Agentul rulează în interiorul clusterului dvs., deci nu trebuie să îl expuneți întregului Internet. Agentul coordonează implementarea solicitând noi modificări de la GitLab, mai degrabă decât GitLab să împingă actualizări către cluster. Indiferent de metoda GitOps pe care o utilizați, GitLab vă acoperă.
Vă rugăm să rețineți că aceasta este prima lansare a agentului. Actualul nostru obiectiv pentru GitLab Kubernetes Agent este de a configura și gestiona implementările prin cod. Unele funcții de integrare Kubernetes existente, cum ar fi plăcile de implementare și aplicațiile gestionate GitLab, nu sunt încă acceptate. că aceste capabilități vor fi adăugate agentului în versiunile viitoare, precum și noi integrări axate pe securitate și conformitate.
и .
Oferiți utilizatorilor permisiuni de implementare fără acces la cod
(PREMIUM, ULTIMATE, ARGINT, AUR)
Anterior, sistemul de permisiuni GitLab a făcut dificilă împărțirea corectă a responsabilităților în cadrul echipei dvs. între cei responsabili pentru dezvoltare și cei responsabili pentru implementare. Odată cu lansarea GitLab 13.4, puteți acorda permisiunea de a aproba cererile de îmbinare pentru implementare, precum și de a implementa efectiv codul persoanelor care nu scriu codul, fără a le acorda drepturi de acces pentru întreținere (în localizarea rusă a „menținătorului” GitLab). ).
и .
Centru de securitate
(ULTIMATE, GOLD)
Anterior, gestionarea vulnerabilităților la nivel de instanță era limitată atât în ceea ce privește funcționalitatea, cât și flexibilitatea. Interfața era o singură pagină care combină detalii despre vulnerabilități, grafice de valori și setări. Nu există prea mult spațiu pentru a dezvolta aceste funcții sau a utiliza alte funcții de securitate.
Am făcut schimbări fundamentale în modul în care gestionăm securitatea și transparența în GitLab. Panoul de securitate al instanței a fost transformat într-un întreg centru de securitate. Cea mai mare schimbare este introducerea unei noi structuri de meniu: în loc de o singură pagină, acum vedeți separat tabloul de bord de securitate, raportul de vulnerabilitate și secțiunea de setări. Deși funcționalitatea nu s-a schimbat, împărțirea în părți va permite îmbunătățiri ale acestei secțiuni, care altfel ar fi dificile. Acest lucru stabilește, de asemenea, scena pentru adăugarea altor capabilități legate de securitate în viitor.
Secțiunea dedicată Raport de vulnerabilitate are acum mai mult spațiu pentru a afișa detalii importante. Iată care sunt vulnerabilitățile care se află în prezent pe lista de vulnerabilități a proiectului. Mutarea widget-urilor cu valori de vulnerabilitate într-o secțiune separată creează un panou de control de securitate convenabil. Acum este o pânză pentru vizualizări viitoare, nu doar pentru gestionarea vulnerabilităților, ci și pentru orice măsurători legate de securitate. În cele din urmă, o zonă separată de setări creează un spațiu comun pentru toate setările de securitate la nivel de instanță, nu doar pentru gestionarea vulnerabilităților.
и .
Funcțiile comutabile sunt acum în GitLab Starter
(STARTER, PREMIUM, ULTIMATE, BRONZ, ARGINT, AUR)
GitLab 11.4 a fost lansat . În 12.2 am introdus strategii pentru ei и , iar în 13.1 au adăugat и pentru medii diferite.
La începutul acestui an, GitLab și-a luat un angajament în sursă deschisă. În această ediție, am finalizat migrarea funcțiilor comutabile către planul Starter și vom continua să le migrăm către Core din . Suntem încântați să aducem această funcție pentru mai mulți utilizatori și dorim să aflăm cum o utilizați.
и .
Navigare rapidă din bara de căutare
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Uneori, când navigați prin GitLab, doriți să mergeți direct la un anumit proiect, mai degrabă decât la pagina cu rezultatele căutării.
Folosind bara de căutare globală, puteți naviga rapid la cele mai recente bilete, grupuri, proiecte, setări și subiecte de ajutor. Puteți folosi chiar și o tastă rapidă /pentru a muta cursorul în bara de căutare pentru a naviga GitLab și mai eficient!
и .
Se afișează acoperirea codului în diferențele dintre cererile de îmbinare
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Când examinați o solicitare de îmbinare, poate fi dificil să determinați dacă codul modificat este acoperit de testele unitare. În schimb, evaluatorii se pot baza pe acoperirea generală și pot solicita ca aceasta să fie mărită înainte de a aproba o solicitare de fuziune. Acest lucru poate duce la o abordare întâmplătoare a scrierii testelor, care de fapt nu va îmbunătăți calitatea codului sau acoperirea testelor.
Acum, când vizualizați o diferență de solicitare de îmbinare, veți vedea o afișare vizuală a acoperirii codului. Noile mărci vă vor permite să înțelegeți rapid dacă codul modificat este acoperit de un test unitar, ceea ce va ajuta la accelerarea revizuirii codului și a timpului de îmbinare și implementare a codului nou.
mulțumesc și Siemens pentru această caracteristică!
и .
Mai multe medii și proiecte în panoul Medii
(PREMIUM, ULTIMATE, ARGINT, AUR)
De la lansarea GitLab 12.5 folosind ai putea monitoriza starea mediului, dar nu mai mult de șapte medii în trei proiecte. Am îmbunătățit acest panou în versiunea 13.4 prin paginarea acestuia pentru a vă ajuta să vă mențineți și să vă gestionați mediile la scară. Acum puteți vedea mai multe medii în mai multe proiecte.
и .
GitLab preia controlul asupra furnizorului GitLab Terraform
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Recent noi și planifică . În ultima lună, am acceptat 21 de solicitări de îmbinare și am închis 31 de bilete, inclusiv unele erori de lungă durată și funcții lipsă, cum ar fi ... Poti în documentația Terraform.
и .
Fuzzing testarea API cu specificațiile OpenAPI sau fișierul HAR
(ULTIMATE, GOLD)
Testarea fuzzing API este o modalitate excelentă de a găsi erori și vulnerabilități în aplicațiile dvs. web și API-urile pe care alte scanere și metode de testare le-ar putea rata.
Testarea fuzzing API în GitLab vă permite să oferiți sau aplicația dvs. și apoi generează automat date de intrare aleatorii concepute pentru a testa cazurile marginale și pentru a găsi erori. Rezultatele sunt vizibile imediat în conducta dvs.
Aceasta este prima noastră lansare de testare fuzz API și ne-ar plăcea să auzim ce părere aveți. Avem mai multe în stoc pentru testarea fuzz , pe care ne vom baza pe lansarea acestei caracteristici.
и .
Previzualizează noile grafice în panoul de valori
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Anterior, crearea unui grafic în tabloul de bord pentru metrici din GitLab nu era o sarcină ușoară. După ce ați creat valoarea în fișierul YAML din tabloul de bord, ați făcut modificări master, fără a putea verifica dacă graficul nou creat funcționează exact așa cum aveți nevoie. Începând cu această ediție, puteți previzualiza modificările pe măsură ce creați graficul, având o idee despre rezultat înainte de a trimite modificările în fișierul YAML tablou de bord.
и .
Date privind acoperirea codului prin teste pentru toate proiectele grupului
(PREMIUM, ULTIMATE, ARGINT, AUR)
Când gestionați un număr mare de proiecte în GitLab, aveți nevoie de o singură sursă de informații despre modul în care acoperirea codului se schimbă în timp în toate proiectele. Anterior, afișarea acestor informații necesita o muncă manuală obositoare și consumatoare de timp: trebuia să descărcați datele de acoperire a codului din fiecare proiect și să le combinați într-un tabel.
În versiunea 13.4, a devenit posibilă asamblarea ușor și rapidă .csv fișier cu toate datele privind acoperirea codului pentru toate proiectele grupului sau pentru o selecție de proiecte. Această caracteristică este MVC, va fi urmată de capacitatea .
и .
Suport pentru noi limbi pentru testarea fuzz completă
(ULTIMATE, GOLD)
Această versiune introduce suport pentru mai multe limbi noi pentru testarea fuzz care vizează o acoperire completă.
Acum puteți evalua capabilitățile complete ale testării fuzzing în aplicațiile Java, Rust și Swift și puteți găsi erori și vulnerabilități pe care alte scanere și metode de testare le pot rata.
и .
Alerte pe pagina principală a mediului
(PREMIUM, ULTIMATE, ARGINT, AUR)
Pagina Medii arată starea generală a mediilor dvs. În această versiune am îmbunătățit această pagină prin adăugarea de afișare a alertelor. Alertele declanșate împreună cu starea mediilor dvs. vă vor ajuta să luați rapid măsuri pentru a corecta situațiile care apar.
и .
Conductele imbricate pot rula acum propriile conducte imbricate
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Prin utilizarea conductelor imbricate, acum este posibil să rulați conducte noi în interiorul conductelor secundare. Nivelul suplimentar de adâncime poate fi util dacă aveți nevoie de flexibilitate pentru a genera un număr variabil de conducte.
Anterior, când se folosea conducte imbricate, fiecare conductă secundară necesita ca un job de declanșare să fie definit manual în conducta părinte. Acum puteți crea conducte imbricate care vor lansa în mod dinamic orice număr de conducte imbricate noi. De exemplu, dacă aveți un monorepository, puteți genera în mod dinamic primul subpipeline, care va crea în sine numărul necesar de noi conducte pe baza modificărilor din ramură.
и .
Navigare îmbunătățită între conductele părinte și imbricate
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Anterior, navigarea între conductele părinte și imbricate nu era foarte convenabilă - aveai nevoie de multe clicuri pentru a ajunge la conducta dorită. De asemenea, nu a fost ușor să ne dăm seama care lucrare a început conducta. Acum va fi mult mai ușor să vedeți conexiunile dintre conductele părinte și imbricate.
и .
Joburile cu matrice paralelă arată variabile relevante în titlul postului
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Dacă ai folosit , poate ați observat că a fost dificil să determinați ce variabilă matrice a fost folosită pentru un anumit loc de muncă, deoarece numele jobului arătau ca matrix 1/4. În versiunea 13.4, veți vedea valorile variabilelor relevante care au fost utilizate în acel job în loc de numele generic al jobului. De exemplu, dacă scopul tău este să depanezi arhitectura x86, atunci jobul va fi apelat matrix: debug x86.
и .
Alte îmbunătățiri în GitLab 13.4
Conectarea unui cont Atlassian
(CORE, STARTER, PREMIUM, ULTIMATE)
Utilizatorii GitLab vor putea acum să își conecteze conturile GitLab la contul Atlassian Cloud. Acest lucru vă va permite să vă conectați la GitLab cu acreditările Atlassian și, de asemenea, va pune bazele îmbunătățirilor viitoare ale integrării. si cu alte produse din linia Atlassian.
и .
Exportarea unei liste cu toate comitările de îmbinare
(ULTIMATE, GOLD)
Organizațiile axate pe conformitate au nevoie de o modalitate de a le arăta auditorilor o viziune holistică asupra componentelor asociate cu orice schimbare dată în producție. În GitLab, asta înseamnă să colectezi totul într-un singur loc: solicitări de îmbinare, bilete, conducte, scanări de securitate și alte date de comitere. Până acum, fie trebuia să le colectați manual în GitLab, fie să configurați instrumentele pentru a colecta informațiile, ceea ce nu era foarte eficient.
Acum puteți colecta și exporta în mod programatic aceste date pentru a îndeplini cerințele de audit sau pentru a efectua alte analize. Pentru a exporta o listă a tuturor comitărilor de îmbinare pentru grupul curent, trebuie să accesați și faceți clic pe butonul Lista tuturor comitărilor de îmbinare. Fișierul rezultat va conține toate comiterile cererii de îmbinare, autorul acestora, ID-ul cererii de îmbinare asociate, grupul, proiectul, confirmatorii și alte informații.
и .
Listați și gestionați jetoanele de acces personale prin API
(ULTIMATE, GOLD)
Gestionarea accesului la spațiul de nume GitLab este o parte importantă a eforturilor de conformitate. De la principiile celui mai mic privilegiu până la dezactivarea accesului temporizat, pot exista mai multe cerințe asociate cu jetoanele de acces personale în GitLab. Pentru a facilita menținerea și gestionarea tuturor acestor acreditări de utilizator în spațiul dvs. de nume, am oferit posibilitatea de a enumera toate indicativele de acces personale și, opțional, prin API.
Aceste îmbunătățiri aduse API-ului GitLab permit utilizatorilor să enumere și să-și revoce propriile jetoane de acces personale, iar administratorilor să enumere și să revoce jetoanele utilizatorilor. Acum va fi mai ușor pentru administratori să vadă cine are acces la spațiul lor de nume, să ia decizii de acces pe baza datelor utilizatorului și să revoce jetoanele de acces personale care ar fi putut fi compromise sau care nu se încadrează în politicile companiei de gestionare a accesului.
и .
Problemele conexe și alte caracteristici sunt acum în GitLab Core
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Acum câteva luni am anunțat un plan pentru . Lucrând pentru a ne îndeplini această promisiune, am făcut-o , и (în localizarea rusă a „tabloului de discuții”) GitLab disponibil în planul Core. Acest lucru se aplică numai relațiilor „legate la”; relațiile „blocate” și „blocate” rămân în planurile plătite.
и .
Afișarea numelui ramurului de origine în bara laterală a cererii de îmbinare
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Când revizuiți modificările de cod, discuțiile și comiterile de solicitare de îmbinare, este adesea de dorit să faceți o verificare locală a sucursalei pentru o revizuire mai profundă. Cu toate acestea, găsirea numelui firului devine din ce în ce mai dificilă pe măsură ce se adaugă mai mult conținut la descrierea cererii de îmbinare și trebuie să derulați mai jos în pagină.
Am adăugat numele sucursalei în bara laterală a cererii de îmbinare, făcându-l accesibil în orice moment și eliminând nevoia de a derula întreaga pagină. La fel ca linkul către cererea de îmbinare, secțiunea de ramură sursă conține un buton convenabil de „copiere”.
mulțumesc pentru contribuția ta uriașă la dezvoltarea acestei funcții!
и .
Indicarea prezenței fișierelor restrânse în diferențele de solicitare de îmbinare
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Solicitările de îmbinare care adaugă modificări la mai multe fișiere restrâng uneori diferențele fișierelor mari pentru a îmbunătăți performanța de redare. Când se întâmplă acest lucru, este posibil să omiteți accidental un fișier în timpul examinării, în special în cererile de îmbinare cu un număr mare de fișiere. Începând cu versiunea 13.4, solicitările de îmbinare vor semnala diferențele care conțin fișiere îndoite, astfel încât să nu ratați aceste fișiere în timpul examinării codului. Pentru o claritate și mai mare, intenționăm să adăugăm evidențiere acestor fișiere într-o versiune viitoare. Rămâneți pe fază pentru actualizări despre .
и .
Avertisment despre prezența fișierelor restrânse în diferența unei cereri de îmbinare
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
În secțiunea diferențe cereri de îmbinare, fișierele mari sunt restrânse pentru a îmbunătăți performanța. Cu toate acestea, la examinarea codului, unele fișiere pot fi pierdute atunci când examinatorul parcurge lista de fișiere, deoarece toate fișierele mari sunt restrânse.
Am adăugat un avertisment vizibil în partea de sus a paginii de diferenciare a cererii de îmbinare pentru a informa utilizatorii că există un fișier îmbinat în această secțiune. În acest fel, nu veți pierde nicio modificare adusă cererii de îmbinare în timpul examinării.
и .
Recuperarea automată a depozitului cluster Gitaly
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Anterior, când nodul primar al unui cluster Gitaly a fost offline, depozitele de pe acel nod erau marcate ca doar pentru citire. Acest lucru a prevenit pierderea datelor în situațiile în care au existat modificări pe nod care nu au fost încă replicate. Când nodul a revenit online, GitLab nu a fost restaurat automat, iar administratorii au trebuit să înceapă manual procesul de sincronizare sau să accepte pierderea datelor. Alte situații, cum ar fi eșecul unui job de replicare pe un nod secundar, pot avea ca rezultat, de asemenea, depozite învechite sau numai în citire. În acest caz, depozitul a rămas învechit până a avut loc următoarea operațiune de scriere, care ar porni jobul de replicare.
Pentru a rezolva această problemă acum programează un job de replicare când detectează un depozit învechit pe un nod și cea mai recentă versiune a depozitului pe altul. Această lucrare de replicare menține depozitul actualizat în mod automat, eliminând nevoia de a restaura manual datele. Recuperarea automată asigură, de asemenea, că nodurile secundare sunt actualizate rapid dacă un job de replicare eșuează, mai degrabă decât să aștepte următoarea operație de scriere. Deoarece multe clustere Gilaly stochează un număr mare de depozite, acest lucru reduce semnificativ timpul pe care administratorii și inginerii de fiabilitate îl petrec recuperând datele după o eroare.
În plus, repararea automată începe replicarea depozitelor pe orice nod Gitaly nou adăugat la cluster, eliminând munca manuală la adăugarea de noduri noi.
и .
Marcați o sarcină de făcut ca finalizată pe pagina de proiectare
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Comunicarea eficientă în GitLab se bazează pe liste de activități. Dacă ești menționat într-un comentariu, este esențial să poți sări la o sarcină și fie să începi să faci ceva, fie să o marchezi ca finalizată. De asemenea, este important să vă puteți atribui o sarcină atunci când trebuie să lucrați la ceva sau să reveniți la el mai târziu.
Anterior, nu puteai să adăugați sarcini sau să le marcați ca finalizate atunci când lucrați cu design. Acest lucru a perturbat serios eficiența comunicării între echipele de produse, deoarece activitățile de făcut sunt un element critic al fluxului de lucru GitLab.
În versiunea 13.4, design-urile ajung din urmă cu comentariile biletelor în utilizarea sarcinilor, ceea ce face ca lucrul cu acestea să fie mai consistent și mai eficient.
и .
Ghid de depanare îmbunătățit pentru CI/CD
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Am îmbunătățit ghidul de depanare pentru GitLab CI/CD cu mai multe informații despre problemele frecvente pe care le puteți întâlni. Sperăm că documentația îmbunătățită va fi o resursă valoroasă pentru a vă ajuta să începeți și să rulați GitLab CI/CD rapid și ușor.
и .
Solicitările de îmbinare nu mai ies din coada de îmbinare
(PREMIUM, ULTIMATE, ARGINT, AUR)
Anterior, solicitările de îmbinare puteau ieși din coada de îmbinare accidental din cauza comentariilor târzii. Dacă o solicitare de îmbinare era deja în coadă și cineva a adăugat un comentariu la ea care a creat o nouă discuție nerezolvată, cererea de îmbinare a fost considerată neeligibilă pentru o îmbinare și ar ieși din coadă. Acum, după ce o solicitare de îmbinare este adăugată la coada de îmbinare, pot fi adăugate comentarii noi fără teama de a întrerupe procesul de îmbinare.
и .
Afișarea valorii de acoperire a codului pentru un job într-o solicitare de îmbinare
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Dezvoltatorii ar trebui să poată vedea valoarea de acoperire a codului după finalizarea conductei - chiar și în scenarii complexe, cum ar fi rularea unei conducte cu mai multe joburi care trebuie analizate pentru a calcula valoarea de acoperire. Anterior, widgetul de solicitare de îmbinare arăta doar media acestor valori, ceea ce însemna că trebuia să navigați la pagina de job și înapoi la cererea de îmbinare pentru a obține valori intermediare de acoperire. Pentru a vă economisi timp și acești pași suplimentari, am făcut ca widgetul să afișeze valoarea medie a acoperirii, modificările acesteia între ramurile țintă și sursă și un sfat explicativ care arată valoarea acoperirii pentru fiecare job pe baza căreia a fost calculată media.
и .
Eliminarea pachetelor din registrul de pachete la vizualizarea unui grup
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Registrul de pachete GitLab este un loc pentru stocarea și distribuirea pachetelor în diferite formate. Când aveți o mulțime de pachete în proiect sau grup, trebuie să identificați rapid pachetele neutilizate și să le eliminați pentru a împiedica oamenii să le descarce. Puteți elimina pachetele din registry prin sau prin interfața de utilizator din registrul pachetelor. Cu toate acestea, până acum nu ați putut elimina pachetele când vizualizați un grup prin interfața de utilizare. Ca urmare, a trebuit să eliminați pachetele inutile pe bază de proiect, ceea ce a fost ineficient.
Acum puteți elimina pachete atunci când vizualizați registrul de pachete al unui grup. Pur și simplu accesați pagina de registru de pachete a grupului, filtrați pachetele după nume și eliminați-le pe cele de care nu aveți nevoie.
и .
Scalarea pachetelor Conan la nivel de proiect
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Puteți folosi depozitul Conan din GitLab pentru a publica și a distribui dependențe C/C++. Cu toate acestea, anterior pachetele puteau scala doar la nivelul instanței, deoarece numele pachetului Conan putea avea maximum 51 de caractere. Dacă doriți să publicați un pachet dintr-un subgrup, de exemplu gitlab-org/ci-cd/package-stage/feature-testing/conan, era aproape imposibil de făcut.
Acum puteți scala pachetele Conan până la nivelul de proiect, facilitând publicarea și distribuirea dependențelor proiectelor dvs.
и .
Suport pentru noi manageri de pachete și limbi pentru scanarea dependențelor
(ULTIMATE, GOLD)
Suntem încântați să adăugăm în lista noastră scanări de dependență pentru proiecte de cod C, C++, C# și .Net care utilizează NuGet 4.9+ sau manageri de pachete Conan . Acum puteți activa scanarea dependențelor ca parte a etapei Securizate pentru a verifica vulnerabilitățile cunoscute în dependențe adăugate prin managerii de pachete. Vulnerabilitățile găsite vor fi afișate în cererea dvs. de îmbinare împreună cu nivelul lor de severitate, astfel încât să știți înainte de a executa îmbinarea ce riscuri implică noua dependență. De asemenea, vă puteți configura proiectul pentru a solicita pentru dependențe cu vulnerabilități cu niveluri de severitate critice (critice), ridicate (ridicate) sau necunoscute (necunoscute).
и .
Notificări când se schimbă setarea cererii de îmbinare la „Îmbinare când conducta se finalizează cu succes”
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Anterior, când setați setările cererii de îmbinare Îmbinați când conducta se termină (Merge When Pipeline Succeeds, MWPS) nu a fost trimisă nicio notificare prin e-mail. A trebuit să verificați manual starea sau să așteptați o notificare de îmbinare. Cu această versiune, suntem încântați să prezentăm contribuțiile utilizatorilor , care a rezolvat această problemă prin adăugarea de notificări automate pentru toți cei abonați la o solicitare de îmbinare atunci când un examinator modifică setarea de îmbinare la MWPS.
и .
Crearea clusterelor EKS cu o versiune de Kubernetes specificată de utilizator
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Utilizatorii GitLab pot alege acum versiunea de Kubernetes care va fi furnizată de EKS; puteți alege între versiunile 1.14–1.17.
и .
Crearea incidentelor ca tipuri de bilete
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Nu orice problemă care apare declanșează imediat alerte: utilizatorii raportează întreruperi, iar membrii echipei investighează problemele de performanță. Incidentele sunt acum un tip de bilet, astfel încât echipele dvs. le pot crea rapid ca parte a fluxului lor normal de lucru. Clic Sarcina noua de oriunde în GitLab și pe teren Tip selecta Incident.
и .
Menționarea alertelor GitLab în Markdown
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Am îmbunătățit alertele GitLab adăugând un nou tip de mențiune special pentru acestea în GitLab Markdown, facilitând partajarea și menționarea alertelor. Utilizare ^alert#1234pentru a menționa alerta în orice câmp Markdown: în incidente, bilete sau solicitări de îmbinare. Acest lucru vă va ajuta, de asemenea, să identificați locurile de muncă care sunt create mai degrabă din alerte decât din bilete sau solicitări de îmbinare.
и .
Vizualizarea încărcării alertelor în funcție de incident
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Descrierea alertei conține informații esențiale pentru depanare și recuperare, iar aceste informații ar trebui să fie ușor accesibile, astfel încât să nu fie nevoie să comutați instrumente sau file în timp ce lucrați pentru a rezolva un incident. Incidentele create din alerte afișează descrierea completă a alertei în filă Detalii de alertă.
Căutare avansată cu 75% mai rapidă
(STARTER, PREMIUM, ULTIMATE, BRONZ, ARGINT, AUR)
GitLab, ca o singură aplicație, are capacitatea unică de a descoperi rapid conținutul în întregul flux de lucru DevOps. În GitLab 13.4, căutarea avansată returnează rezultate cu 75% mai rapid , ca pe GitLab.com.
и .
Vizualizarea proiectelor șterse pentru administratori
(CORE, STARTER, PREMIUM, ULTIMATE)
A existat o opțiune de a amâna ștergerea proiectului . Cu toate acestea, anterior nu era posibil să vedeți toate proiectele care așteptau ștergerea într-un singur loc. Administratorii de instanțe de utilizator GitLab pot vizualiza acum toate proiectele de ștergere în așteptare într-un singur loc, împreună cu butoane pentru a restaura cu ușurință acele proiecte.
Această caracteristică oferă administratorilor un control mai mare asupra ștergerii proiectelor prin colectarea tuturor informațiilor relevante într-un singur loc și oferind posibilitatea de a anula acțiunile de ștergere nedorite.
mulțumesc pentru această caracteristică!
и .
S-a adăugat suport pentru regulile de push de grup în API
(STARTER, PREMIUM, ULTIMATE, BRONZ, ARGINT, AUR)
Anterior, regulile de push de grup puteau fi configurate doar vizitând fiecare grup individual prin interfața de utilizare GitLab și aplicând acele reguli. Acum puteți gestiona aceste reguli printr-un API pentru a vă sprijini instrumentele personalizate și automatizarea GitLab.
и .
Revocarea jetoanelor de acces personale pentru stocarea de acreditări autogestionată
(FINAL)
Oferă administratorilor informațiile de care au nevoie pentru a gestiona acreditările de utilizator pentru instanța lor GitLab. Deoarece organizațiile axate pe conformitate variază în ceea ce privește strictețea politicilor lor de gestionare a acreditărilor, am adăugat un buton care permite administratorilor să revoce opțional jetonul de acces personal (PAT) al unui utilizator. Administratorii pot acum revoca cu ușurință PAT-urile potențial compromise. Această caracteristică este utilă pentru organizațiile care doresc opțiuni de conformitate mai flexibile pentru a minimiza întreruperile utilizatorilor lor.
и .
Fișier de configurare pentru editorul de site static
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
În GitLab 13.4, introducem o nouă modalitate de a personaliza editorul de site static. Deși fișierul de configurare nu salvează și nu primește nicio setare în această versiune, punem bazele pentru personalizarea viitoare a comportamentului editorului. În versiunile viitoare vom adăuga fișierului .gitlab/static-site-editor.yml parametrii de instalare pe care , suprascriind setările de sintaxă Markdown și alte setări ale editorului.
и .
Editarea părții introductive a unui fișier folosind un editor de site static
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Front matter este o modalitate flexibilă și convenabilă de a defini variabilele de pagină în fișierele de date pentru procesare de către generatorul de site static. Este folosit de obicei pentru a seta titlul paginii, șablonul de aspect sau autorul, dar poate fi folosit pentru a transmite generatorului orice tip de metadate atunci când redarea paginii în HTML. Inclusă în partea de sus a fiecărui fișier de date, partea introductivă este de obicei formatată ca YAML sau JSON și necesită o sintaxă consecventă și precisă. Utilizatorii care nu sunt familiarizați cu anumite reguli de sintaxă pot introduce din greșeală un marcaj nevalid, care, la rândul său, poate cauza probleme de formatare sau chiar erori de compilare.
Modul de editare WYSIWYG al editorului de site static elimină deja introducerea din editor pentru a preveni aceste erori de formatare. Cu toate acestea, acest lucru vă împiedică să modificați valorile stocate în această parte fără a reveni la editare în modul sursă. În GitLab 13.4, puteți accesa orice câmp și puteți edita valoarea acestuia într-o interfață familiară bazată pe formulare. Când butonul este apăsat Setări (setări cont) se va deschide un panou care arată un câmp de formular pentru fiecare cheie definită la început. Câmpurile sunt populate cu valoarea curentă, iar editarea oricăruia dintre ele este la fel de simplă ca și introducerea acesteia în formularul web. Editarea introducerii în acest fel evită sintaxa complexă și vă oferă control complet asupra conținutului, asigurând în același timp că rezultatul final este formatat în mod consecvent.
и .
GitLab pentru Jira și DVCS Connector este acum în Core
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Pentru utilizatorii Jira de pe GitLab: и vă permit să afișați informații despre comenzile GitLab și solicitările de îmbinare direct în Jira. În combinație cu integrarea noastră Jira încorporată, vă puteți deplasa cu ușurință între cele două aplicații în timp ce lucrați.
Aceste funcții erau disponibile anterior numai în planul nostru Premium, dar acum sunt disponibile pentru toți utilizatorii!
и .
Votul majoritar pentru tranzacțiile cluster Gitaly (beta)
(CORE, STARTER, PREMIUM, ULTIMATE)
Un cluster Gitaly vă permite să replicați depozitele Git în mai multe noduri Gitaly „calde”. Acest lucru mărește toleranța la defecțiuni prin eliminarea punctelor individuale de defecțiune. , introdus în GitLab 13.3, determină difuzarea modificărilor către toate nodurile Gitaly din cluster, dar numai nodurile Gitaly care votează în acord cu nodul primar salvează modificările pe disc. Dacă toate nodurile de replică nu sunt de acord, o singură copie a modificării va fi stocată pe disc, creând un singur punct de eșec până la finalizarea replicării asincrone.
Votul majoritar îmbunătățește toleranța la erori prin necesitatea acordului majorității nodurilor (nu a tuturor) înainte de a salva modificările pe disc. Dacă această caracteristică de comutare este activată, scrierea ar trebui să aibă succes pe mai multe noduri. Nodurile divergente sunt sincronizate automat folosind replicarea asincronă de la acele noduri care au format un cvorum.
и .
Suport de schemă personalizată pentru validarea JSON în Web IDE
(PREMIUM, ULTIMATE, ARGINT, AUR)
Proiectele în care oamenii scriu configurații în JSON sau YAML sunt adesea predispuse la probleme, deoarece este ușor să faci o greșeală de tipar și să spargi ceva. Este posibil să scrieți instrumente de inspecție pentru a detecta aceste probleme în conducta CI, dar utilizarea unui fișier de schemă JSON poate fi utilă pentru a furniza documentație și indicii.
Participanții la proiect pot defini în depozitul lor calea către o schemă personalizată într-un fișier .gitlab/.gitlab-webide.yml, care specifică schema și calea către fișierele care urmează să fie verificate. Când încărcați un anumit fișier în Web IDE, veți vedea feedback și validare suplimentară pentru a vă ajuta să creați fișierul.
и .
Limita de ramificare a graficului aciclic direcționat (DAG) a crescut la 50
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Dacă utilizați benzi transportoare (Grafic aciclic direcționat (DAG)), este posibil să descoperiți că există o limită de 10 locuri de muncă pe care o poate specifica în needs:, prea aspru. În 13.4, limita implicită a fost mărită de la 10 la 50 pentru a permite rețele mai complexe de relații între joburile din conductele dvs.
Dacă sunteți administrator al unei instanțe GitLab personalizate, puteți crește această limită și mai mult prin configurarea unei funcții de comutare, deși nu oferim suport oficial pentru aceasta.
и .
Comportament îmbunătățit needs pentru sarcinile ratate
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
În unele cazuri, o lucrare ratată într-o conductă poate fi considerată incorect reușită pentru dependențele specificate în needs, ceea ce a determinat rularea lucrărilor ulterioare, ceea ce nu ar fi trebuit să se întâmple. Acest comportament a fost remediat în versiunea 13.4 și needs acum gestionează corect cazurile de sarcini ratate.
и .
Fixați ultimul artefact al misiunii pentru a preveni ștergerea acestuia
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
GitLab blochează acum automat ultima lucrare reușită și artefact pipeline pe orice ramură activă, cerere de îmbinare sau etichetă pentru a preveni ștergerea acesteia după expirare. Devine mai ușor să stabiliți reguli de expirare mai agresive pentru a curăța artefactele vechi. Acest lucru ajută la reducerea consumului de spațiu pe disc și vă asigură că aveți întotdeauna o copie a celui mai recent artefact din conductă.
и .
Ghid CI/CD pentru optimizarea conductelor
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Optimizarea conductei CI/CD poate îmbunătăți viteza de livrare și poate economisi bani. Ne-am îmbunătățit documentația pentru a include un ghid rapid pentru a profita la maximum de optimizarea conductelor.
и .
Raport de testare sortat după starea testului
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
este o modalitate ușoară de a vedea rezultatele tuturor testelor dintr-o conductă. Cu toate acestea, cu un număr mare de teste, găsirea testelor nereușite poate dura mult timp. Alte probleme care pot face ca raportul să fie dificil de utilizat includ dificultatea de a derula prin ieșirile de urmărire lungă și rotunjirea timpului la zero pentru testele care rulează în mai puțin de 1 secundă. Acum, în mod implicit, atunci când sortează un raport de testare, mai întâi plasează testele eșuate la începutul raportului, apoi sortează testele după durată. Acest lucru face mai ușor să găsiți erori și teste lungi. În plus, duratele testelor sunt afișate acum în milisecunde sau secunde, ceea ce le face mult mai rapid de citit, iar problemele anterioare de defilare au fost, de asemenea, rezolvate.
и .
Limitări ale dimensiunii fișierelor încărcate în registrul pachetelor
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Există acum limite privind dimensiunea fișierelor pachet care pot fi încărcate în registrul de pachete GitLab. Au fost adăugate restricții pentru a optimiza performanța registrului pachetelor și pentru a preveni abuzul. Limitele variază în funcție de formatul pachetului. Pentru GitLab.com, dimensiunile maxime ale fișierelor sunt:
- Conan: 250 MB
- Maven: 3 GB
- NPM: 300 MB
- NuGet: 250 MB
- PyPI: 3 GB
Pentru instanțe GitLab personalizate, valorile implicite sunt aceleași. Cu toate acestea, administratorul poate actualiza restricțiile folosind .
и .
Utilizați CI_JOB_TOKEN pentru a publica pachete PyPI
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Puteți utiliza depozitul GitLab PyPI pentru a crea, publica și partaja pachete Python împreună cu codul sursă și conductele CI/CD. Cu toate acestea, anterior nu puteați să vă autentificați în depozit folosind o variabilă de mediu predefinită CI_JOB_TOKEN. Ca urmare, a trebuit să vă folosiți acreditările personale pentru a actualiza depozitul PyPI sau este posibil să fi decis să nu utilizați deloc depozitul.
Acum este mai ușor să utilizați GitLab CI/CD pentru a publica și instala pachete PyPI utilizând o variabilă de mediu predefinită CI_JOB_TOKEN.
и .
Profile de scanare DAST la cerere
(ULTIMATE, GOLD)
Pentru scanarea DAST la cerere, asta a fost , au fost adăugate profiluri de scaner DAST. Acestea extind capacitățile de configurare ale acestor scanări, permițându-vă să creați rapid mai multe profiluri pentru a acoperi mai multe tipuri de scanare. În 13.4, profilul crawlerului include în mod nativ o setare de expirare a crawlerului care stabilește cât timp ar trebui să ruleze crawler-ul DAST în timp ce încearcă să descopere toate paginile unui site accesat cu crawlere. Profilul include, de asemenea, o setare de expirare a site-ului țintă pentru a seta cât timp ar trebui să aștepte crawler-ul pentru ca un site să devină accesibil înainte de a anula accesarea cu crawlere, dacă site-ul nu răspunde cu un cod de stare 200 sau 300. Pe măsură ce continuăm să îmbunătățim Această funcție va fi adăugat la profilul scanerului în versiunile viitoare; vor fi adăugați parametri de configurare suplimentari.
и .
Un simplu fișier de configurare de redirecționare pentru GitLab Pages
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Dacă utilizați GitLab Pages și doriți să gestionați mai bine modificările URL, este posibil să fi observat că gestionarea redirecționărilor pe site-ul dvs. GitLab Pages nu a fost posibilă. GitLab vă permite acum să configurați reguli pentru a redirecționa o adresă URL la alta pentru site-ul dvs. Pages, adăugând un fișier de configurare în depozit. Această caracteristică este posibilă datorită contribuției lui Kevin Barnett (), Eric Eastwood al nostru () și echipele GitLab. Mulțumesc tuturor pentru contribuție.
и .
Starea Terraform gestionată de GitLab
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Accesul la versiunile anterioare ale stării Terraform este necesar atât pentru conformitate, cât și pentru depanare, dacă este necesar. Suport pentru versiunea stării Terraform gestionat de GitLab este oferit începând cu GitLab 13.4. Versiunea este activată automat pentru noile fișiere de stare Terraform. Fișierele de stare Terraform existente vor fi într-o ediție ulterioară.
и .
Detalii importante privind notificarea incidentului
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Când procesați incidente, trebuie să puteți determina cu ușurință cât timp a fost deschisă o alertă și de câte ori a fost declanșat evenimentul. Aceste detalii sunt adesea esențiale pentru a determina impactul asupra clientului și ceea ce ar trebui să abordeze mai întâi echipa ta. În noul panou Detalii incidente, afișăm ora de începere a alertei, numărul de evenimente și un link către alerta inițială. Aceste informații sunt disponibile pentru incidentele care sunt generate din alerte.
и .
Setarea și editarea parametrului de severitate a incidentului
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Dimensiunea Gravitatea incidentului permite respondenților și părților interesate să determine impactul unei întreruperi, precum și metoda și urgența răspunsului. Pe măsură ce echipa dvs. împărtășește rezultatele în timpul rezolvării și recuperării incidentelor, poate modifica această setare. Acum puteți edita gravitatea unui incident în bara laterală din dreapta a paginii Detalii incidente, iar gravitatea este afișată în lista de incidente.
и .
Crearea, editarea și ștergerea regulilor de securitate a rețelei de containere
(ULTIMATE, GOLD)
Această îmbunătățire a Editorului de reguli de securitate pentru rețea de containere permite utilizatorilor să creeze, să editeze și să șteargă cu ușurință regulile lor direct din interfața de utilizator GitLab. Caracteristicile editorului includ .yaml pentru utilizatorii experimentați și un editor de reguli cu o interfață intuitivă pentru cei care cunosc regulile rețelei. Puteți găsi noi opțiuni de gestionare a regulilor în secțiune Securitate și conformitate > Gestionarea amenințărilor > Reguli (Securitate și conformitate > Gestionarea amenințărilor > Politici).
и .
Suport pentru stocarea blob Azure
(CORE, STARTER, PREMIUM, ULTIMATE, GRATUIT, BRONZ, ARGINT, AUR)
Atât GitLab, cât și GitLab Runner acceptă acum , facilitând rularea serviciilor GitLab pe Azure.
Instanțele GitLab acceptă Azure pentru toate tipurile de depozite de obiecte, inclusiv fișiere LFS, artefacte CI și . Pentru a configura stocarea Azure Blob, urmați instrucțiunile de instalare sau .
Procesoarele de joburi GitLab acceptă și Azure pentru stocare . Spațiul de stocare Azure poate fi configurat folosind secțiunea .
и .
Pachete Omnibus ARM64 pentru Ubuntu și OpenSUSE
(CORE, STARTER, PREMIUM, ULTIMATE)
Ca răspuns la cererea tot mai mare de suport pentru rularea GitLab pe arhitectura ARM pe 64 de biți, suntem încântați să anunțăm disponibilitatea pachetului oficial ARM64 Ubuntu 20.04 Omnibus. Mulțumiri uriașe lui Zitai Chen și Guillaume Gardet pentru contribuțiile uriașe pe care le-au adus - cererile lor de fuziune au jucat un rol cheie în acest sens!
Pentru a descărca și instala pachetul pentru Ubuntu 20.04, accesați pagina noastră și selectați Ubuntu.
и .
Suport de autentificare cu carduri inteligente pentru diagrama GitLab Helm
(PREMIUM, ULTIMATE)
Cardurile inteligente, cum ar fi cardurile de acces comun (CAC), pot fi acum utilizate pentru a se autentifica la o instanță GitLab implementată prin diagrama Helm. Cardurile inteligente sunt autentificate pe o bază de date locală folosind certificate X.509. Prin aceasta, suportul pentru carduri inteligente cu graficul Helm este acum în conformitate cu suportul pentru carduri inteligente disponibil în implementările Omnibus.
и .
Notele de lansare detaliate și instrucțiunile de actualizare/instalare pot fi citite în postarea originală în limba engleză: .
Lucram la traducerea din engleză , , и .
Sursa: www.habr.com