Menu

Dimensional Data

Noutați

Care sunt cele mai populare instrumente pentru testarea automatizării?

Sencha

Utilizarea instrumentelor de testare automatizată este o modalitate perfectă de a verifica produsul dvs. Majoritatea organizațiilor fac acest lucru des pentru a se asigura că produsele lor ating cerințele standard pentru aceasta. Anumite resurse sunt folosite pentru a efectua testarea unui produs, cunoscute sub numele de instrumente de testare automatizată . Majoritatea oamenilor care doresc să aibă succes în domeniul software-ului se asigură întotdeauna că își dezvoltă produsele și își mențin standardul. La fel cum s-a schimbat tehnologia de-a lungul anilor, testarea s-a schimbat și ele. În anii anteriori, testarea produselor se face manual, dar acum, testarea nu se face doar manual, ci are mai multă dezvoltare. Organizațiile folosesc testarea automată pentru a-și reduce volumul de muncă și pentru a se asigura că obțin rezultate corecte și precise cu testarea. Care sunt cele mai populare instrumente pentru testarea automatizării pentru a sprijini organizațiile în această problemă? Ulterior, vom discuta despre cele mai populare instrumente de testare a automatizării. Totuși, înainte de a face asta, trebuie să știm ce este testarea automată. Ce este testarea automată? Testarea automată este atunci când cineva testează produse software pentru a ști dacă îndeplinește standardul cerut. Pentru realizarea acestui proces sunt folosite instrumente automate de testare de la Sencha . Nu este nevoie de interferența umană cu procesul [1]. Când efectuați testarea automată, vă ajută să comparați rezultatele așteptate și cele reale. Acest lucru vă face să știți dacă produsul este un succes sau un eșec. Un alt aspect despre testarea automată este; că ajută la simplificarea testelor. O poți face oricând în orice perioadă dorești. Importanța testării automate? O echipă cu multe produse de dezvoltat cu siguranță nu va avea mult timp pentru a testa produsele manual. Testarea automatizării îi ajută să economisească timp. Testarea automată vă ajută, de asemenea, să vă asigurați că sunteți eficient cu testarea produselor prin acuratețe, făcând ca produsele dvs. să obțină un rezultat mai bun. Testarea manuală a unui produs vă poate face să vă obosiți și să testați un produs din când în când. Dar cu testarea automată, vă puteți testa produsele în mod regulat. Testarea automată vă ajută echipa să-și dezvolte încrederea. Acest lucru face ca produsele dezvoltate de ei să fie pregătite pentru piață. De asemenea, permite echipei dvs. să își orienteze atenția către alte proiecte neterminate. Ce este un instrument de testare a automatizării? Un instrument de testare a automatizării este un instrument pe care îl puteți utiliza pentru a efectua teste pentru produsele dvs. software. Sunt instrumente care înlocuiesc interferența umană cu tehnici de automatizare. Acestea pot funcționa pe diverse platforme mobile, web și desktop. Există tipuri de instrumente automate de testare [2] și sunt; Instrumente open-source Instrumente non-producție Instrumente desktop Instrumente fără cod Instrumente web Instrumente mobile Instrumente de producție Unelte hibride Care sunt cele mai populare instrumente pentru testarea automatizării? Există instrumente pe care clienții le-au evaluat pentru utilizare excelentă și voi împărtăși câteva dintre aceste instrumente populare aici. Sunt; LambdaTest este un instrument care este foarte potrivit atunci când vine vorba de testarea aplicațiilor web și desktop-urilor. Este un instrument bazat pe cloud pe care îl puteți utiliza pentru a efectua teste automate pe cadre precum telefoanele mobile și browserele. LambdaTest este un instrument care vă ajută să reduceți timpul alocat testării prin accelerarea procesului și, de asemenea, vă poate […]

Read More

GitLab prelungește expirarea cheii de semnare a pachetului Omnibus cu un an

Noutați

GitLab folosește o cheie GPG pentru a semna toate pachetele Omnibus create în conductele CI pentru a se asigura că pachetele nu au fost modificate. Această cheie este separată de cheia de semnare a metadatelor din depozit utilizată de managerii de pachete și de cheia de semnare GPG pentru GitLab Runner. Cheia de semnare a pachetului Omnibus este setat să expire la 1 iulie 2022 și va fi prelungită pentru a expira în schimb la 1 iulie 2023. De ce prelungim termenul? Expirarea cheii de semnare a pachetului Omnibus este prelungită în fiecare an pentru a respecta politicile de securitate GitLab și pentru a limita expunerea în cazul în care cheia devine compromisă. Expirarea cheii este extinsă în loc să se rotească la o nouă cheie, pentru a fi mai puțin perturbatoare pentru utilizatorii care verifică verificarea integrității pachetului înainte de a instala pachetul. Ce trebuie sa fac? Singura acțiune care trebuie luată este să vă actualizați copia cheii de semnare a pachetului dacă validați semnăturile de pe pachetele Omnibus pe care le distribuie GitLab. Cheia de semnare a pachetului nu este cheia care semnează metadatele din depozit utilizate de managerii de pachete ale sistemului de operare, cum ar fi apt sau yum. Dacă nu verificați în mod specific semnăturile pachetelor sau ați configurat managerul de pachete pentru a verifica semnăturile pachetelor, nu este necesară nicio acțiune din partea dvs. pentru a continua instalarea pachetelor Omnibus. Mai multe informații privind verificarea semnăturilor pachetului sunt disponibile în documentația Omnibus. Dacă trebuie doar să reîmprospătați o copie a cheii publice, atunci o puteți găsi pe oricare dintre serverele de chei GPG căutând support@gitlab.com sau folosind ID-ul DBEF 8977 4DDB 9EB3 7D9F C3A0 3CFC F9BA F27E AB47. Alternativ, îl puteți descărca direct de pe packages.gitlab.com folosind adresa URL: https://packages.gitlab.com/gitlab/gitlab-ce/gpgkey/gitlab-gitlab-ce-3D645A26AB9FBD22.pub.gpg Ce fac dacă mai am probleme? Deschideți o problemă îninstrumentul de urmărire a problemelor omnibus-gitlab . Înscrieți-vă pentru buletinul informativ de două ori lunar al GitLab

Read More

Viitorul IDE-ului web GitLab

Noutați

În aprilie 2018, GitLab 10.7 a introdus Web IDE în lume și a adus un editor încântător de fișiere multiple în centrul experienței GitLab. Scopul nostru a fost să facilităm contribuția oricui și tuturor, indiferent de experiența lor de dezvoltare. De la introducerea sa, zeci de milioane de comitări au fost făcute din Web IDE și am adăugat funcții precum Live Preview și Interactive Web Terminals pentru a îmbunătăți experiența. Acum, suntem încântați să împărtășim câteva schimbări majore pe care le avem pregătite pentru Web IDE în următoarele etape. Ce face un IDE? De-a lungul anilor, am învățat multe despre cum folosiți cu toții IDE-ul web. L-am comparat cu Editorul nostru web din vizualizarea depozitului. Am vorbit deopotrivă cu dezvoltatori, designeri, manageri de produs și scriitori tehnici. Aproape universal, auzim că IDE-ul web este excelent pentru mici modificări: o schimbare rapidă a unui fișier de configurare, o actualizare a unui fișier Markdown sau o remediere a greșelii într-o solicitare de îmbinare. Aceste modificări ușoare reprezintă marea majoritate a utilizării Web IDE. Și pentru acele cazuri de utilizare, este super convenabil și intuitiv. Dar pentru a crește și pentru a câștiga cu adevărat porecla „IDE”, ce ne lipsește? Ce îi împiedică pe dezvoltatori să facă schimbări mai complexe în IDE-ul web? Ce putem face pentru a crește experiența? Auzim despre funcții și funcționalități lipsă, cum ar fi un panou de fișiere pliabil, care acceptă acțiuni contextuale și trage și plasează sau o integrare mai strânsă cu solicitările de îmbinare . Am învățat că nu există nicio funcție unică care să fie un deal-breaker pentru majoritatea dezvoltatorilor; este suma totală a multor mici lacune în experiența utilizatorului. Web IDE este construit pe baza fantasticului proiect open source, Monaco . Ceea ce a făcut din Monaco o alegere excelentă ca fundație a Web IDE este, de asemenea, ceea ce face mai dificilă abordarea tuturor acestor preocupări în mod holist. Monaco este doar asta: o fundație. Trebuie să implementăm noi înșine toate aceste fluxuri de lucru și caracteristici. Între timp, un alt proiect open source a fost concentrat pe laser pe furnizarea unui IDE adorabil deasupra Monaco. Introduceți codul VS Este posibil să fi auzit de Visual Studio Code sau VS Code. Având cota sa dominantă de piață , sunt șanse destul de mari să îl folosiți ca editor de cod principal. După cum se întâmplă, nucleul VS Code este, de asemenea, open source sub licența MIT. Deși proiectul de bază nu este un înlocuitor perfect pentru Web IDE, inginerul nostru de front-end, Paul Slaughter , a vrut să vadă dacă îl putem rula în GitLab. Se pare că putem: În acest videoclip, Paul Slaughter, inginer FE al personalului, îl prezintă pe Eric Schurter, manager senior de produs, prin demonstrația conceptului VS Code Web IDE. Consultați părțile a doua , trei și patru pentru o privire mai atentă asupra extensiilor, performanței și personalizării. După cum puteți vedea în videoclipurile de mai sus, Paul a reușit să construiască o dovadă a conceptului care aduce experiența de editare VS Code în interfața de utilizare GitLab, rulând în întregime în browser. Nu este nevoie de infrastructură suplimentară. În continuare, ne-am pus întrebarea: Dorim să investim în continuare în implementarea de caracteristici personalizate pentru IDE-ul web care oferă, în cele din urmă, aceeași valoare ca cele deja disponibile […]

Read More

3 chei ale succesului pentru operațiunile de produs

Noutați

Este oficial. Operațiunile cu produse sunt un lucru. O căutare rapidă pe Google va scoate o listă lungă de articole care laude tot ceea ce operațiunile de produs au de oferit, de la eficientizarea managerilor de produs până la colectarea și sinteza datelor. Când m-am ocupat pentru prima dată de operațiunile de produs la GitLab , nu existau prea multe definiții sau îndrumări pe acest subiect. Am înțeles ce înseamnă operațiunile de produs, deoarece „făceam asta” ca parte inseparabilă a rolurilor mele de management de produs și de lider de produs de câțiva ani. Dar nu am avut niciodată ocazia să mă concentrez doar pe operațiunile cu produse. Oricât de entuziasmat eram, eram și nervos. GitLab accelera spre o IPO și atât echipa de management al produsului, cât și produsul se aflau în modul de hiper creștere. Și, pentru început, echipele multifuncționale, de la distanță, erau în mișcare, sincronizate și asincrone, zi și noapte, pe tot globul. Așadar, am luat legătura cu colegii care și-au început deja călătoria operațiunilor de produs și am valorificat perspectiva, progresul și învățările pe care le-au împărtășit cu generozitate. Și, făcând asta, mi-am dat seama că toată lumea o făcea puțin diferit. Acum, doi ani și jumătate mai târziu, operațiunile cu produse sunt un lucru la GitLab. Și cea mai frecventă întrebare pe care o primesc de la colegii care mă adresează este: Cum pot configura operațiunile de produs pentru succes în organizația mea? Pentru a răspunde la această întrebare, voi presupune că toți dorim să fim conduși de produs și centrați pe client, iar „succesul” ar fi operațiunile de produs care ne ajută să ajungem acolo. Voi presupune, de asemenea, că suntem de acord cu sentimentul care a evoluat, definind responsabilitatea operațiunilor de produs pentru a se încadra în aceste domenii de bază: instrumente, date, experimentare, strategie și consilier de încredere. Deși nu există o singură formulă, voi împărtăși trei chei care au deschis ușile pentru ca operațiunile cu produse să aibă un impact și să crească cu GitLab. 1. Împuternicește operațiunile cu produse ca funcție proprie, cu un loc egal, alături de alte funcții care generează valoare La GitLab, desfășurăm operațiuni de produs ca o funcție independentă sub umbrela produsului. Linia directă de responsabilitate față de șeful tuturor produselor asigură că operațiunile de produs au conștientizarea, alinierea și responsabilitatea față de nevoile macro ale produsului și ale afacerii. Acest lucru permite, de asemenea, operațiunilor cu produse să mențină o viziune largă și imparțială, precum și nivelul corect de influență, pentru a dezvolta strategii/tactici care să servească produsul și afacerea fără favor față de niciun grup anume. Acest articol din Silicon Valley Product Group de Marty Cagan oferă un context mai util cu privire la motivul acestei abordări. 2. Faceți din operațiunile cu produse o operațiune mai întâi de oameni Înainte ca operațiunile cu produse să poată oferi eficiențe și instrumente care sunt utile pentru produs și afacere, operațiunile cu produse trebuie să înțeleagă toți clienții săi interni. În primul an, operațiunile de produs au luat formă la GitLab, o mare parte din energia mea s-a concentrat pe construirea de relații, nu numai cu membrii echipei de produs, ci și în întreaga organizație. A deveni un consilier de încredere înseamnă mai mult decât furnizarea de date, este vorba despre a simți durerea și de […]

Read More

Când căutarea simplității creează complexitate în conductele CI bazate pe containere

Noutați

Într-un club de carte GitLab, am citit recent „ Legile simplității ”, o carte grozavă pe un subiect care m-a fascinat profund de mulți ani. Cartea conține un acronim care exprimă abordările de generare a simplității: SHE, care înseamnă „shrink, hide, inbody”. Aceste trei abordări pentru generarea simplității au toate un atribut comun: toate creează iluzii – nu eliminări. Am văzut această iluzie repetându-se în multe, multe tărâmuri de urmărire de mulți ani. Chiar și în limbajul uman, dezvoltarea vocabularului, jargonul și acronimele încapsulează pur și simplu lumi de complexitate care încă există, dar pot fi mai ușor de făcut referire într-o formă compactă care realizează SHE în lumea conceptelor. Orice iluzie are o limită sau o cortină unde în fața cortinei complexitatea poate fi rezolvată urmând reguli simple, dar, în spatele cortinei, complexitatea trebuie gestionată de un manager de scenă. De exemplu, când spectacolul de magie creează spectrul tăierii oamenilor în jumătate, ceea ce pare a fi o simplă cutie este de fapt un instrument extrem de elaborat. Nu numai asta, dar procesul de fabricație pentru o cutie simplă reală și pentru cutia de ferăstrău sunt semnificativ diferite în ceea ce privește complexitatea. Producerea complexității și rezultatul acesteia sunt, în esență, compromisul pentru ceea ce ar fi complexitatea din lumea reală de a tăia oamenii în jumătate și de a-i face să se vindece și să se ridice nevătămați imediat după. Pentru a aduce acest lucru în domeniul abilităților tehnice, luați în considerare că atunci când utilizați o componentă terță parte sau API pentru a adăuga funcționalitate, trebuie doar să cunoașteți parametrii pentru a obține rezultatul dorit. Persoanele care întrețin acea componentă sau API-ul trebuie să cunoască nivelul de detaliu al mecanicii cuantice despre cum să efectueze acea lucrare într-un mod fiabil și complet. Containerele Docker sunt un mecanism pentru încorporarea complexității și sunt utilizate în aplicații scalate și în CI bazat pe container. Când un inginer de automatizare CI/CD folosește CI bazat pe container, este posibil să facă lucrurile mai complexe și mai scumpe atunci când încearcă să facă exact invers. În esență, această postare este preocupată de modul în care se poate întâmpla ca urmărirea unei lumi mai simple prin containere să se transforme într-un antimodel – o inversare a rezultatelor dorite – de multe ori, fără ca noi să observăm că inversarea ne afectează productivitatea. Închisoarea unei paradigme este într-adevăr sigură. A doua lege a dinamicii complexității De-a lungul anilor, am ajuns să cred că căutarea reducerii complexității are caracteristici similare celei de-a doua lege a termodinamicii . Rezultatul net al unei schimbări între masă și energie are ca rezultat aceeași cantitate netă de masă și energie, dar raportul și forma lor s-au schimbat. În ceea ce voi inventa „A doua lege a dinamicii complexității”, complexitatea este în mod similar „conservată”, este doar reformată. Dacă complexitatea nu este eliminată prin simplificarea eforturilor, îi reducem impactul într-un domeniu dat prin schimbarea raportului dintre complexitate și simplitate pe fiecare parte a uneia sau mai multor perdele. Dar, din păcate, complexitatea nu a murit, doar s-a ascuns și acum este provocarea de management a altcuiva. Este important să nu te gândești la asta ca la o înșelăciune. Nu există nicio îndoială că ascunderea complexității are potențialul de câștiguri masive de eficiență atunci când lumea din spatele mecanismelor de ascundere […]

Read More

Lingo: un cadru de microlimbi Go pentru construirea de limbaje specifice domeniului

Noutați

Limbile specifice domeniului (DSL) sunt limbi mici, concentrate, cu un domeniu îngust de aplicabilitate. DSL-urile sunt adaptate pentru domeniul lor țintă, astfel încât experții în domeniu să poată oficializa idei pe baza cunoștințelor și a experienței lor. Acest lucru face ca DSL-urile să fie instrumente puternice care pot fi utilizate în scopul creșterii eficienței programatorului, fiind mai expresive în domeniul lor țintă, în comparație cu limbajele de uz general și prin furnizarea de concepte pentru a reduce sarcina cognitivă a utilizatorilor lor. Luați în considerare problema însumării soldurilor diferitelor conturi bancare într-un fișier CSV. Un exemplu de fișier CSV este furnizat în exemplul de mai jos, unde prima coloană conține numele titularului de cont, iar a doua coloană conține soldul contului. name, balance Lisa, 100.30 Bert, 241.41 Maria, 151.13 Puteți rezolva problema însumării soldurilor folosind un limbaj de uz general, cum ar fi Ruby , ca în fragmentul de cod de mai jos. În afară de faptul că codul de mai jos nu este foarte robust, conține o mulțime de boilerplate care sunt irelevante pentru problema în cauză, adică însumarea soldurilor contului. #!/usr/bin/env ruby exit ( 1 ) if ARGV . empty? || ! File . exist? ( ARGV [ 0 ]) sum = 0 File . foreach ( ARGV [ 0 ]). each_with_index do | line , idx | next if idx == 0 sum += Float ( line . split ( ‘,’ )[ 1 ]) end puts sum . round ( 2 ) Mai jos este un exemplu de script AWK care rezolvă aceeași problemă. AWK este un DSL care a fost special conceput pentru a rezolva problemele legate de procesarea textului. #!/usr/bin/awk -f BEGIN { FS = “,” }{ sum += $2 } END { print sum } Programul Ruby are o dimensiune de 208 de caractere, în timp ce programul AWK are o dimensiune de 56. Programul AWK este de aproximativ 4 ori mai mic decât omologul său Ruby. În plus, implementarea AWK este mai robustă, fiind mai puțin predispusă la erori care pot apărea în fișierul CSV (de exemplu, linii noi goale, câmpuri de date formatate greșit). Diferența semnificativă în ceea ce privește dimensiunea ilustrează faptul că DSL-urile, fiind mai concentrate pe rezolvarea unor probleme specifice, își pot face utilizatorii mai productivi, scutindu-i de sarcina de a scrie cod standard și îngustând focalizarea limbajului asupra problemei în cauză. Unele DSL-uri populare pe care majoritatea dezvoltatorilor de software le folosesc în mod regulat includ expresii regulate pentru potrivirea modelelor, AWK pentru transformarea textului sau limbajul standard de interogare pentru interacțiunea cu bazele de date. Provocări la proiectarea limbilor specifice domeniului Crearea de prototipuri, proiectarea și evoluția DSL-urilor este un proces provocator. Din experiența noastră, acesta este un ciclu explorator în care prototipați în mod constant ideile, le încorporați în limbaj, le încercați în realitate, colectați feedback și îmbunătățiți DSL-ul pe baza feedback-ului. Atunci când proiectați un DSL, există multe componente care trebuie implementate și evoluate. La un nivel foarte înalt există două componente principale: lexer/parserul de limbă și procesorul de limbaj. Lexer/parser-ul este componenta care acceptă intrarea conform definiției limbii, care este de obicei specificată prin intermediul unei gramatici a limbii. Faza de analizare/lexare produce un arbore de sintaxă care este apoi transmis procesorului de limbaj. Un procesor de limbaj evaluează arborele de sintaxă. În exemplul […]

Read More

Modul în care ceea ce am învățat la KubeCon EU 2022 va avea impact asupra foilor noastre de parcurs pentru produse

Noutați

După doi ani de doar evenimente virtuale KubeCon, echipa de produse GitLab a fost încântată să participe și să se întâlnească cu colegi, parteneri și multe altele din industria noastră la KubeCon EU 2022, care a avut loc în Valencia, Spania. Am fost prezenți cu patru lideri de produse, un dezvoltator de software și un cercetător UX. Această postare rezumă principalele noastre concluzii de la conferință, o experiență care ne va afecta foile de parcurs. Vom discuta următoarele subiecte: Platforme interne și GitOps Managementul secretelor Integrarea infrastructurii WebAssembly aka WASM Au existat 32 de tipuri de subiecte și mai multe evenimente de 0 zile la KubeCon. Multe discuții s-au concentrat pe câteva instrumente. Multe proiecte Cloud Native Computing Foundation ( CNCF ) au avut întâlniri ale comunității în aceste zile. Unele discuții au fost date IRL, iar altele au fost difuzate virtual cu întrebări și răspunsuri în direct. Au fost o varietate de subiecte și abordări. Au existat multe discuții și despre diferitele aspecte ale managementului clusterelor. Cu toate acestea, am lăsat acest subiect în mod intenționat, deoarece la GitLab dorim să ne concentrăm pe dezvoltatorii de software și să oferim o platformă DevOps care să le susțină munca. Managementul clusterelor este la un pas de această focalizare. Totuși, am observat câteva modele remarcabile, așa cum sunt evidențiate de cele patru elemente ale listei noastre. Ești invitat! Alăturați-vă nouă pe 23 iunie pentru evenimentul de lansare a GitLab 15 cu guruul DevOps Gene Kim și câțiva lideri GitLab. Vă vor arăta ce văd pentru viitorul DevOps și The One DevOps Platform. Platforme interne și GitOps Companiile doresc ca dezvoltatorii lor să se concentreze pe activitatea lor de bază. Ei creează platforme interne pentru a ascunde complexitatea operațiunilor din Zilele 0-2 de inginerii lor software și permit în continuare mișcarea „deplasare la stânga” a DevOps. Aceste platforme presupun adesea sudarea mai multor scule. Multe discuții au prezentat modul în care echipa sau compania respectivă și-a abordat problema platformei și ce instrumente au folosit, și de multe ori se putea simți transpirația de 18 luni a unei întregi echipe de platformă care încearcă să găsească o soluție. Aceste platforme folosesc fie un model bazat pe push-sau pull-ul pentru implementări. Nu apare nicio abordare unică din cauza aplicațiilor vechi și a cerințelor diferite. Deși există o definiție a GitOps oferită de inițiativa OpenGitOps , mai mulți prezentatori și-au oferit propriile definiții, inclusiv a implementărilor bazate pe pull. Am desfășurat un sondaj la scară largă legat de secrete la KubeCon și am aflat că utilizatorii ar dori ajutor cu fluxul de lucru Pipeline Authoring . Pe lângă cablarea instrumentelor, industria încă caută o abordare unificată a multi-chiriei (s-ar putea să nu existe una), iar uneori integrarea proceselor de securitate pare prea dificilă. Cum ne afectează acest lucru foaia de parcurs? Există mult potențial în construirea unei platforme folosită ca punct de plecare pentru platformele interne. Imaginați-vă un „instrument” care scurtează timpul necesar pentru a crea o platformă internă la zile sau săptămâni în loc de un an întreg. Aceasta este viziunea GitLab a platformei The One DevOps. Drept urmare, nu planificăm nicio schimbare în direcția noastră. Vom continua să investim în direcția de implementare recent începută pentru a oferi toate elementele de bază ale unei platforme într-un singur instrument și căutăm deja în mod […]

Read More

Terraform ca parte a lanțului de aprovizionare cu software, Partea 1 – Module și furnizori

Noutați

Când vorbim despre securitatea Terraform, există multe resurse care acoperă aspectele de securitate ale infrastructurii din jurul anumitor configurații Terraform. Privind securitatea Terraform în sine și lucrurile care ar putea merge prost atunci când îl rulează, totuși, au o acoperire foarte mică până acum. Unele lucrări publicate anterior de care sunt la curent includ: „Furnizorii și modulele Terraform utilizate în configurația dvs. Terraform vor avea acces deplin la variabilele și starea Terraform dintr-un spațiu de lucru. Terraform Cloud nu poate împiedica furnizorii și modulele rău intenționați să exfiltreze aceste date sensibile. Vă recomandăm să utilizați numai module și furnizori de încredere în configurația dvs. Terraform. .” Postarea pe blog pe care o citiți este prima parte a unei serii de trei părți care examinează aspectele lanțului de aprovizionare ale Terraform și își propune să analizeze modulele și furnizorii Terraform rău intenționați. Voi oferi, de asemenea, recomandări cu privire la securizarea procesului de rulare a Terraform împotriva modulelor și furnizorilor deveniți necinstiți. Următoarele două bloguri din serie se vor baza pe aceste descoperiri și vor acoperi subiecte și vulnerabilități mai aprofundate. Securitatea furnizorului Furnizorii din Terraform sunt binare executabile, deci dacă un furnizor devine rău intenționat, cu siguranță este „game over”, în sensul că poate face orice permite sistemul de operare gazdă pe care rulează. Furnizorii trebuie să aibă o semnătură care este validată de Terraform la instalarea Furnizorului. Versiunea 0.14 Terraform creează un fișier de blocare a dependenței care înregistrează sumele de verificare ale furnizorilor utilizați în două formate diferite. sume de control zh și h1 Primul format , zh , este pur și simplu un hash SHA256 al fișierului zip care conține un furnizor pentru o anumită combinație de platformă OS/hardware. Hash-ul h1 este așa-numitul „ dirhash ” al directorului furnizorului. Deci, dacă ne uităm la următorul fișier de blocare .terraform.lock.hcl , putem observa cele două tipuri diferite de hashe-uri: # This file is maintained automatically by “terraform init”. # Manual edits may be lost in future updates. provider “registry.terraform.io/hashicorp/aws” { version = “4.11.0” hashes = [ “h1:JTgGUEVVuuv82X0ePjDM73f+ZM+NfLwb/GGNAOM0CdE=”, “zh:3e4634f4babcef402160ffb97f9f37e3e781313ceb7b7858fe4b7fc0e2e33e99”, “zh:3ff647aa88e71419480e3f51a4b40e3b0e2d66482bea97c0b4e75f37aa5ad1f1”, “zh:4680d16fbb85663034dc3677b402e9e78ab1d4040dd80603052817a96ec08911”, “zh:5190d03f43f7ad56dae0a7f0441a0f5b2590f42f6e07a724fe11dd50c42a12e4”, “zh:622426fcdbb927e7c198fe4b890a01a5aa312e462cd82ae1e302186eeac1d071”, “zh:9b12af85486a96aedd8d7984b0ff811a4b42e3d88dad1a3fb4c0b580d04fa425”, “zh:b0b766a835c79f8dd58b93d25df8f37749f33cca2297ac088d402d718baddd9c”, “zh:b293cf26a02992b2167ed3f63711dc01221c4a5e2984b6c7c0c04a6155ab0526”, “zh:ca8e1f5c58fc838edb5fe7528aec3f2fcbaeabf808add0f401aee5073b61f17f”, “zh:e0d2ad2767c0134841d52394d180f8f3315c238949c8d11be39a214630e8d50e”, “zh:ece0d11c35a8537b662287e00af4d27a27eb9558353b133674af90ec11c818d3”, “zh:f7e1cd07ae883d3be01942dc2b0d516b9736a74e6037287ab19f616725c8f7e8”, ] } Intrările zh pot fi găsite și în versiunea v.4.11.0 a furnizorului în fișierul SHA256SUMS . Pentru a înțelege intrarea unică h1 dirhash, trebuie să aruncăm o privire la directorul furnizorului. În proiectul nostru Terraform este construit astfel: $ ls .terraform/providers/registry.terraform.io/hashicorp/aws/4.11.0/linux_amd64/ terraform-provider-aws_v4.11.0_x5 $ cd .terraform/providers/registry.terraform.io/hashicorp/aws/4.11.0/linux_amd64/ $ sha256sum terraform-provider-aws_v4.11.0_x5 34c03613d15861d492c2d826c251580c58de232be6e50066cb0a0bb8c87b48de terraform-provider-aws_v4.11.0_x5 $ sha256sum terraform-provider-aws_v4.11.0_x5 > /tmp/dirhash $ sha256sum /tmp/dirhash 253806504555baebfcd97d1e3e30ccef77fe64cf8d7cbc1bfc618d00e33409d1 /tmp/dirhash $ echo 253806504555baebfcd97d1e3e30ccef77fe64cf8d7cbc1bfc618d00e33409d1 | ruby -rbase64 -e ‘puts Base64.encode64 [STDIN.read.chomp].pack(“H*”)’ JTgGUEVVuuv82X0ePjDM73f+ZM+NfLwb/GGNAOM0CdE= dirhash -ul, numit h1 în fișierul de blocare, este creat dintr-o listă alfabetică de nume de sha256sum filename . Odată ce această listă este sumată din nou, sha256sum rezultat este luat în reprezentare binară și apoi convertit în Base64. Din perspectiva unui atacator, partea interesantă a fișierului de blocare este că poate conține mai multe hash-uri zh și h1 pentru fiecare furnizor. De asemenea, este de remarcat faptul că aceste două tipuri nu trebuie să aibă nicio relație. Dacă modificăm conținutul unui furnizor descărcat pe disc, putem pur și simplu să plasăm hash-ul h1 corespunzător lângă orice alt h1 din fișierul de blocare. Deoarece pot exista mai multe intrări, nu am întrerupe nicio instalare legitimă și am permite doar să listăm un director de furnizor modificat pe […]

Read More

Trei moduri în care schimbările actuale de paradigmă în tehnologie modelează viitorul industriei

Noutați

Gemenii digitali , bazați pe tehnologii 4IR, sunt un factor esențial pentru Web3 în industrie. Acestea sunt deja utilizate cu diferite niveluri de completitate în multe industrii pentru a ajuta organizațiile să înțeleagă fluxurile de sistem, să anticipeze nevoile de întreținere, să reducă costurile operaționale și să sporească eficiența generală. „În mod ideal, doriți ca Web3 să vă revoluționeze fluxurile de lucru end-to-end, la nivel general, pentru fiecare persoană din organizația dumneavoastră. Dar cred că este mai degrabă cazul că vom găsi puncte de tracțiune, unde cineva poate începe în ciuda vântului în contra cu care ne confruntăm.” – Matt Fleckenstein, director senior, management de produs, Microsoft Mesh, Microsoft Fiind un lider al inovației, Vancouver Airport Authority (YVR) a dorit să se reinventeze ca o poartă pentru învățare, inovare și mișcare de idei noi în industriile dincolo de aviație. Rezultatul a fost un geamăn digital al terminalului și aerodromului său de pe Sea Island. Geamănul digital al facilităților YVR ajută la rezolvarea provocărilor precum instruirea, optimizarea, testarea, evaluarea impactului asupra mediului și planificarea pentru viitor – toate în timp ce permit aeroportului să funcționeze fără întrerupere. Conceput cu o mentalitate „în primul rând”, geamănul digital YVR oferă beneficii semnificative angajaților aeroportului, precum și comunității în general.

Read More

Unity și .NET, ce urmează?

Noutați

Suportul .NET Standard 2.1 în Unity 2021 LTS ne permite să începem să modernizăm runtime-ul Unity în mai multe moduri. În prezent lucrăm la două îmbunătățiri. Îmbunătățirea modelului de programare async/wait . Async/wait este o abordare fundamentală de programare pentru scrierea codului de joc care trebuie să aștepte finalizarea unei operațiuni asincrone fără a bloca bucla principală a motorului. În 2011, înainte ca async/wait să fie obișnuit în .NET, Unity a introdus operații asincrone cu coroutine bazate pe iterator, dar această abordare este incompatibilă cu async/wait și poate fi mai puțin eficientă. Între timp, .NET Standard 2.1 a îmbunătățit suportul pentru async/wait în C# și .NET odată cu introducerea unei gestionări mai eficiente a operațiunilor asincrone/wait prin ValueTask și permițând propriul sistem asemănător sarcinii prin AsyncMethodBuilder. Acum putem profita de aceste îmbunătățiri, așa că lucrăm la activarea utilizării asincrone/așteptării cu operațiunile asincrone existente în Unity (cum ar fi așteptarea următorului cadru sau așteptarea finalizării UnityWebRequest). În primul pas, îmbunătățim suportul pentru anularea sarcinilor asincrone în așteptare atunci când un MonoBehavior este distrus sau când ieșim din modul Play utilizând jetoane de anulare . De asemenea, am lucrat îndeaproape cu cei mai mari contributori ai comunității, cum ar fi autorul UniTask , pentru a ne asigura că vor putea folosi aceste noi funcționalități. Reducerea alocărilor de memorie și a copiilor prin utilizarea Span. Deoarece Unity este un motor C++ cu un strat de scripting C#, există multe schimburi de date între cei doi. Acest lucru poate fi ineficient, deoarece adesea necesită fie copierea datelor înainte și înapoi, fie alocarea de noi obiecte gestionate. Span a fost introdus în C# 7.2 pentru a îmbunătăți astfel de scenarii și este disponibil implicit în .NET Standard 2.1. În ultimii ani, este posibil să fi auzit sau citit despre multe îmbunătățiri semnificative ale performanței aduse .NET Runtime datorită Span (consultați detaliile îmbunătățirilor în .NET Core 2.1 , .NET Core 3.0 , .NET 6 , .NET 6 ) . Dorim să profităm de utilizarea sa în Unity, deoarece aceasta va ajuta la reducerea alocărilor și, în consecință, Garbage Collection se întrerupe, îmbunătățind în același timp performanța generală a multor API-uri.

Read More

Abonează-te la noutăți

Primiți noutăți și oferte despre SDLC tools

Close Menu