NĂ«se kompania juaj sapo po implementon DevOps ose mjetet CI/CD, mund tĂ« jetĂ« e dobishme tĂ« njiheni me gabimet mĂ« tĂ« zakonshme, nĂ« mĂ«nyrĂ« qĂ« tĂ« mos i pĂ«rsĂ«risni ato dhe tĂ« mos hidhni hapin nĂ« lloje gabimesh tĂ« tjerĂ«ve.Â
Ekipa përktheu artikullin .
Mungesa e gatishmërisë për të ndryshuar kulturën dhe proceset
Nëse e shikoni diagramin ciklik , mund të shihni se në praktikat DevOps testi është një punë e vazhdueshme, një pjesë themelore e çdo implementimi të veçantë.
Diagrami ciklik i pafund i DevOps
Testimi dhe sigurimi i cilësisë në procesin e zhvillimit dhe shpërndarjes janë një pjesë e detyrueshme e të gjitha atyre që bëjnë zhvilluesit. Kjo kërkon një ndryshim në mendim, për të përfshirë testimin në çdo detyrë.
Testimi bëhet një pjesë e punës së përditshme të çdo anëtari të ekipit. Kalimi në testim të vazhdueshëm nuk kalon lehtë, duhet të jeni të gatshëm për këtë.
Mungesa e feedback-ut
Efiçenca e DevOps varet nga feedback-u i vazhdueshëm. Përmirësimi i vazhdueshëm është i pamundur nëse nuk ka një hapësirë për bashkëpunim dhe komunikim.
Kompani qĂ« nuk organizojnĂ« takime retrospektivĂ« kanĂ« vĂ«shtirĂ«si nĂ« tĂ« implementuar njĂ« kulturĂ« tĂ« feedback-ut tĂ« vazhdueshĂ«m nĂ« CI/CD. Takimet retrospektivĂ« organizohen nĂ« fund tĂ« çdo iteracioni, ku anĂ«tarĂ«t e grupit diskutojnĂ« se çfarĂ« shkoi mirĂ« dhe çfarĂ« keq. Takimet retrospektivĂ« janĂ« themeli i Scrum/Agile, por janĂ« gjithashtu tĂ« nevojshme pĂ«r DevOps.Â
Kjo lidhet me faktin se takimet retrospektivë u japin zakonin të ndajnë feedback dhe mendime. Një nga pikat më të rëndësishme në fillim është organizimi i takimeve retrospektivë të përsëritura, në mënyrë që ato të bëhen të qarta dhe të zakonshme për të gjithë ekipin.
Kur bëhet fjalë për cilësinë e softuerit, të gjithë anëtarët e ekipit janë përgjegjës për mbajtjen e saj. Për shembull, zhvilluesit mund të shkruajnë teste modulare dhe gjithashtu të shkruajnë kod duke marrë parasysh testueshmërinë, duke ndihmuar në uljen e rreziqeve qysh në fillim.
Një nga mënyrat e thjeshta për të reflektuar ndryshimin e përceptimeve mbi testimin është të quhet testuesit jo QA, por testues të softuerit ose inxhinierë të cilësisë. Ky ndryshim mund të duket shumë i thjeshtë ose madje i paarsyeshëm. Por nëse dikush quhet "specialist i sigurimit të cilësisë së softuerit", kjo jep një përfundim të gabuar për atë se kush është përgjegjës për cilësinë e produktit. Në praktikat Agile, CI/CD dhe DevOps, të gjithë janë përgjegjës për cilësinë e software-it.
Një aspekt tjetër i rëndësishëm është të kuptosh se çfarë do të thotë cilësia për të gjithë ekipin dhe çdo anëtar të tij, organizatën, dhe palët e interesuara.
Kuptimi i gabuar i përfundimtarisë së fazës
NĂ«se cilĂ«sia Ă«shtĂ« njĂ« proces i vazhdueshĂ«m dhe i pĂ«rbashkĂ«t, duhet njĂ« kuptim i pĂ«rbashkĂ«t i pĂ«rfundimtarisĂ« sĂ« fazĂ«s. Si mund ta kuptoni se njĂ« fazĂ« ka pĂ«rfunduar? ĂfarĂ« ndodh kur njĂ« fazĂ« Ă«shtĂ« shĂ«nuar si e pĂ«rfunduar nĂ« njĂ« tabelĂ« Trello ose ndonjĂ« tabelĂ« tjetĂ«r Kanban?
Përkufizimi i fazës së përfunduar (DoD) është një mjet i fuqishëm në kontekstin e CD DevOps/CI. Ai ndihmon për të kuptuar më mirë standardet e cilësisë së asaj që dhe si e ndërton ekipi.
Ekipi zhvillues duhet të vendosë se çfarë do të thotë "Gati". Ata duhet të ulen dhe të hartojnë një listë karakteristikash që duhet të përmbushen në çdo fazë, që të mund të konsiderohet e përfunduar.
DoD e bën procesin më transparent dhe lehtëson zbatimin e CI/CD, nëse është e kuptueshme për të gjithë pjesëmarrësit e ekipit dhe e pajtuar gjithashtu.
Mungesa e objektivave realiste dhe të definuara qartë
Ky Ă«shtĂ« njĂ« nga kĂ«shillat mĂ« tĂ« cituara, por ia vlen tĂ« pĂ«rsĂ«ritet. PĂ«r suksesin e çdo nisma tĂ« rĂ«ndĂ«sishme, duke pĂ«rfshirĂ« zbatimin e CI/CD ose DevOps, Ă«shtĂ« e nevojshme tĂ« pĂ«rcaktoni objektiva realistĂ« dhe tĂ« matni performancĂ«n nĂ« raport me ta. ĂfarĂ« po pĂ«rpiqeni tĂ« arrini me CI/CD? A lejon kjo tĂ« lĂ«shoni versionet mĂ« shpejt me cilĂ«si mĂ« tĂ« mirĂ«?
Ădo objektiv i vendosur duhet tĂ« jetĂ« jo vetĂ«m transparent dhe realist, por gjithashtu tĂ« pĂ«rputhet me aktivitetet aktuale tĂ« kompanisĂ«. PĂ«r shembull, sa shpesh kanĂ« nevojĂ« klientĂ«t tuaj pĂ«r rregullime ose versione tĂ« reja? Nuk ka nevojĂ« tĂ« ngarkoni proceset dhe tĂ« lĂ«shoni versione mĂ« shpejt, nĂ«se nuk ka pĂ«rfitime tĂ« tjera pĂ«r pĂ«rdoruesit.
Për më tepër, nuk është gjithmonë e nevojshme të zbatoni si CD ashtu edhe CI. Për shembull, kompanitë me një shkallë të lartë rregullimi, siç janë bankat dhe klinikat mjekësore, mund të punojnë vetëm me CI.
CI është një pikë e mirë fillestare për çdo kompani që po implementon DevOps. Me zbatimin e tij, qasjet ndaj shpërndarjes së softuerit në kompani ndryshojnë ndjeshëm. Pasi të jetë zotëruar CI, mund të mendohet për përmirësimin e të gjithë procesit, rritjen e shpejtësisë së lëshimeve dhe ndryshime të tjera.
Për shumë organizata, më mjafton një CI, dhe CD duhet të zbatohet vetëm nëse sillte një përfitim shtesë.
Mungesa e paneleve për monitorim dhe metrikash të përshtatshme
Sapo të keni vendosur qëllimet, ekipi i zhvilluesve mund të krijojë një panel për të matur KPI-të. Para se ta zhvilloni, është e drejtë të bëni një vlerësim të parametrave që do të monitorohen.
Raportet dhe aplikacionet e ndryshme janë të dobishme për anëtarë të ndryshëm të ekipit. Scrum-masterat janë më të interesuar për statusin dhe mbulimin. Ndërsa drejtuesit e lartë mund të jenë të interesuar për shpejtësinë e djegies së specialistëve.
Disa ekipe gjithashtu përdorin tabela për vlerësimin e statusit CI/CD me tregues të kuq, të verdhë dhe të green, për të kuptuar nëse po bëjnë gjithçka siç duhet ose nëse ka ndodhur ndonjë gabim. E kuqa do të thotë se duhet të kushtoni vëmendje asaj që po ndodh.
Megjithatë, nëse panelet e informacionit nuk janë standardizuar, ato mund të çojnë në konfuzion. Analizoni se cilat të dhëna i nevojiten të gjithëve, pastaj krijoni një përshkrim të standardizuar të asaj që ato nënkuptojnë. Mësoni se çfarë ka më shumë kuptim për palët e interesuara: grafika, teksti apo numra.
Mungesa e testeve manuale
Automatizimi i testeve vendos bazĂ«n pĂ«r njĂ« krijim tĂ« mirĂ« CI/CD. Por testimi automatizuar nĂ« tĂ« gjitha fazat nuk do tĂ« thotĂ« se nuk duhet tĂ« kryhen teste manuale.Â
Për të ndërtuar një linjë efikase CI/CD, nevojiten edhe teste manuale. Do të ketë gjithmonë disa aspekte të testimit që kërkojnë analizë nga një njeri.
Ka vlerë të mendoni për integrimin e përpjekjeve të testimit manual në linjë. Pasi testimi manual i disa shembujve të testit të jetë përfunduar, mund të kaloni në fazën e shpërndarjes.
Mos u përpiqni të përmirësoni testet
Një pipeline efektiv CI/CD kërkon qasje në mjetet e duhura, qoftë menaxhimi i testimit apo integrimi dhe monitorimi i vazhdueshëm.
Krijimi i njĂ« kulture tĂ« fortĂ«, tĂ« orientuar drejt cilĂ«sisĂ« synon , monitorimin e ndĂ«rveprimit me klientĂ«t pas shpĂ«rndarjes dhe ndjekjen e pĂ«rmirĂ«simeve.Â
Ja disa këshilla praktike që mund t'i realizoni lehtësisht:
- Sigurohuni që testet të jenë të thjeshta për t'u shkruar dhe mjaft fleksibël që të mos dështojnë gjatë refaktorimit të kodit.
- Ekipet e zhvilluesve duhet të përfshihen në procesin e testimit - të shohin listën e problemeve dhe kërkesave nga përdoruesit që janë të rëndësishme për t'u verifikuar gjatë pipeline-ve CI.
- Mund të mos keni mbulim të plotë me teste, por gjithmonë sigurohuni që rrjedhat që janë të rëndësishme për UX dhe ndërveprimin me klientët janë testuar.
Pika e fundit, por jo më pak e rëndësishme
Kalimi në CI/CD zakonisht niset nga poshtë lart, por përfundimisht, kjo është një transformim që kërkon angazhimin e menaxhimit, investim kohor dhe burimesh nga ana e kompanisë. Sepse CI/CD përfshin një grup aftësish, procese, mjete dhe një ristrukturim kulturor që mund të realizohen vetëm në mënyrë sistematike.
ĂfarĂ« tjetĂ«r tĂ« lexoni mbi kĂ«tĂ« temĂ«:
- .
- .
- .
Burimi: habr.com
