NĂ«se kompania juaj sapo po implementon DevOps ose mjete CI/CD, mund t'ju vyshk pĂ«r t'u njohur me gabimet mĂ« tĂ« zakonshme, nĂ« mĂ«nyrĂ« qĂ« tĂ« mos i pĂ«rsĂ«ritni ato dhe tĂ« mos hidhni hapa tĂ« gabuar.Â
Ekipa përktheu artikullin .
Mosgatishmëria për të ndryshuar kulturën dhe proceset
Nëse e shikoni diagramin ciklik , do të shihni se në praktikat DevOps testimi është një punë e vazhdueshme, një pjesë themelore e çdo deployment-i të veçantë.
Diagrami ciklik i pafund i DevOps
Testimi dhe sigurimi i cilësisë gjatë zhvillimit dhe shpërndarjes janë një pjesë e obliguar e gjithçkaje që bëjnë zhvilluesit. Kjo kërkon një ndërrim të mendësisë 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 ndodh lehtë, duhet të jeni të gatshëm për këtë.
Mungesa e feedback-ut
Efektiviteti i DevOps varet nga feedback-u i vazhdueshëm. Përmirësimi i vazhdueshëm është i pamundur nëse nuk ka hapësirë për bashkëpunim dhe komunikim.
Kompani qĂ« nuk organizojnĂ« takime retrospektive e kanĂ« tĂ« vĂ«shtirĂ« tĂ« implementojnĂ« njĂ« kulturĂ« tĂ« vazhdueshme feedback-u nĂ« CI/CD. Takimet retrospektive mbahen nĂ« pĂ«rfundim tĂ« çdo iteracioni, ku pjesĂ«marrĂ«sit e grupit diskutojnĂ« se çfarĂ« shkoi mirĂ« dhe çfarĂ« jo. Takimet retrospektive janĂ« themeli i Scrum/Agile, por ato janĂ« gjithashtu tĂ« nevojshme edhe pĂ«r DevOps.Â
Kjo është për shkak se takimet retrospektive përforcojnë zakonin e shkëmbimit të feedback-ut dhe mendimeve. Një nga momentet më të rëndësishme në fillim është organizimi i takimeve retrospektive përsëritëse, në mënyrë që ato të bëhen të qarta dhe të zakonshme për gjithë ekipin.
Kur diskutohet për cilësinë e softuerit, të gjithë anëtarët e ekipit kanë përgjegjësi për ruajtjen e saj. Për shembull, zhvilluesit mund të shkruajnë teste moduli, si dhe të krijojnë kodin me mendimin për testueshmërinë, duke ndihmuar në uljen e rreziqeve që nga fillimi.
Një nga mënyrat më të thjeshta për të reflektuar ndryshimin e përceptimeve për testimin është të quajmë testuesit jo QA, por testues të softuerit ose inxhinierë të cilësisë. Ky ndryshim mund të duket shumë i thjeshtë ose madje budalla. Por, nëse dikush quhet "specialist i sigurisë së cilësisë së softuerit", kjo krijon një keqkuptim mbi atë se kush është përgjegjës për cilësinë e produktit. Në praktikën Agile, CI/CD dhe DevOps, të gjithë janë përgjegjës për cilësinë e softuerit.
Një tjetër moment i rëndësishëm është kuptimi se çfarë do të thotë cilësia për të gjithë ekipin dhe për çdo anëtar të tij, organizatën dhe palët e interesuara.
Keqkuptimi i përfundimtarisë së fazës
NĂ«se cilĂ«sia Ă«shtĂ« njĂ« proces vazhdueshĂ«m dhe i pĂ«rbashkĂ«t, duhet njĂ« kuptim i pĂ«rbashkĂ«t i pĂ«rfundimtarisĂ« sĂ« fazĂ«s. Si mund ta kuptojmĂ« se njĂ« fazĂ« ka pĂ«rfunduar? ĂfarĂ« ndodh kur njĂ« fazĂ« shĂ«nohet si e pĂ«rfunduar nĂ« tabelĂ«n Trello ose nĂ« ndonjĂ« tabelĂ« kanban tjetĂ«r?
Përcaktimi i përfundimit të një faze (DoD) është një mjet i fuqishëm në kontekstin e CD DevOps/CI. Ai ndihmon në kuptimin më të mirë të standardeve të cilësisë së asaj që dhe si e ndërtuon ekipi.
Ekipi zhvillues duhet të vendosë se çfarë do të thotë "Gati". Ata duhet të ule dhe të përgatisin një listë karakteristikash që duhet të plotësohen në çdo fazë që të konsiderohet i përfunduar.
DoD e bën procesin më transparent dhe lehtëson zbatimin e CI/CD, nëse është e qartë për të gjithë anëtarët e ekipit dhe e kanë miratuar së bashku.
Mungesa e objektivave realiste dhe të qarta
Ky Ă«shtĂ« njĂ« nga kĂ«shillat mĂ« tĂ« cituara, por e meriton tĂ« pĂ«rsĂ«ritet. PĂ«r suksesin e çdo nisme serioze, duke pĂ«rfshirĂ« zbatimin e CI/CD ose DevOps, Ă«shtĂ« e nevojshme tĂ« vendosen objektiva realista dhe tĂ« matet performanca nĂ« raport me ato. ĂfarĂ« po pĂ«rpiqeni tĂ« arrini me CI/CD? A lejon tĂ« lĂ«sh releases mĂ« shpejt me cilĂ«si mĂ« tĂ« mirĂ«?
Cdo objektiv i vendosur duhet të jetë jo vetëm transparent dhe realist, por edhe në përputhje me aktivitetet aktuale të kompanisë. Për shembull, sa shpesh kanë nevojë klientët tuaj për riparime të reja apo versione? Nuk ka nevojë të tejngarkoni proceset dhe të lësh releases më shpejt nëse nuk ka përfitime shtesë për përdoruesit.
Për më tepër, nuk është gjithmonë e nevojshme që ju të implementoni edhe CD-në ashtu si CI-në. Për shembull, kompanitë me një shkallë të lartë rregullimi, si bankat dhe klinikat mjekësore, mund të funksionojnë vetëm me CI.
CI është një pikë e mirë fillestare për çdo kompani që po implementon DevOps. Me implementimin e saj, qasjet në ofrimin e software-it ndahen ndjeshëm. Pasi CI të jetë mësuar, mund të mendoni për përmirësimin e procesit tërësor, rritjen e shpejtësisë së lancimit dhe ndryshime të tjera.
Për shumë organizata, një CI është e mjaftueshme, dhe CD duhet të implementohet vetëm nëse sjell përfitime të tjera.
Mungesa e paneleve të përshtatshme të monitorimit dhe metrikeve
Sapo të keni vendosur qëllimet, ekipi i zhvilluesve mund të krijojë një panel monitorimi për matjen e KPI-ve. Para zhvillimit të tij, është e dobishme 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 drejtësia e lartë mund të jetë e interesuar për shpejtësinë e djegies së specialistëve.
Disa ekipe gjithashtu përdorin për të vlerësuar statusin e CI/CD panele të kontrollit me tregues të kuq, të verdhë dhe të gjelbër, për të kuptuar nëse po e bëjnë gjithçka siç duhet ose nëse ka ndodhur një gabim. E kuqja do të thotë se duhet të kushtohet vëmendje asaj që po ndodh.
Megjithatë, nëse panele informacioni nuk janë të standardizuara, ato mund të jenë të ngatërruara. Analizoni cilat të dhëna i nevojiten të gjithëve dhe më pas 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 ose numra.
Mungesa e testeve manuale
Automatizimi i testimit vendos bazat pĂ«r njĂ« konvej CI/CD tĂ« mirĂ«. Por testimi automatizuar nĂ« çdo fazĂ« nuk do tĂ« thotĂ« qĂ« nuk duhet tĂ« kryhen teste manuale.Â
Për të ndërtuar një konvej CI/CD efikas, janë të nevojshme edhe testet manuale. Do të ketë gjithmonë disa aspekte të testimit që kërkojnë analizë nga një njeri.
Vlen të mendoni për integrimin e përpjekjeve të testimit manual në konvej. Pasi të jetë përfunduar testimi manual i disa rasteve të testimit, mund të kaloni në fazën e shpërndarjes.
Mos u përpiqni të përmirësoni provat
Një kanal efektiv CI/CD kërkon qasje në mjetet e duhura, qofshin ato menaxhimi i testimit ose integrimi dhe monitorimi i vazhdueshëm.
Krijimi i njĂ« kulture tĂ« fortĂ«, tĂ« orientuar drejt cilĂ«sisĂ« Ă«shtĂ« e fokusuar nĂ« , monitorimin e ndĂ«rveprimit me klientĂ«t pas implementimit dhe ndjekjen e pĂ«rmirĂ«simeve.Â
KĂ«tu janĂ« disa kĂ«shilla praktike qĂ« mund tâi realizoni lehtĂ«sisht:
- Sigurohuni që provat të jenë të thjeshta për t'u shkruar dhe mjaft fleksibile për t'u mos thyer gjatë ristrukturimit të kodit.
- Ekipet e zhvilluesve duhet tĂ« pĂ«rfshihen nĂ« procesin e testimit â tĂ« shohin listĂ«n e çështjeve dhe kĂ«rkesave nga pĂ«rdoruesit qĂ« janĂ« tĂ« rĂ«ndĂ«sishme pĂ«r t'u verifikuar gjatĂ« kanaleve CI.
- Mund të mos keni mbulimin e plotë të provave, por gjithmonë kujdesuni që rrjedhat që janë të rëndësishme për UX dhe ndërveprimin me klientët të testohen.
Në fund, por jo më pak e rëndësishme
Kalimi në CI/CD zakonisht niset nga poshtë lart, por, në fund të fundit, kjo është një transformim që kërkon përfshirjen e menaxhmentit, investimin në kohë dhe burime nga ana e kompanisë. Pasall CI/CD është një grup aftësish, procese, mjete dhe një rifreskim kulturor; të tillë ndryshime mund të zbatohen vetëm në një mënyrë sistematike.
ĂfarĂ« tjetĂ«r tĂ« lexoni nĂ« kĂ«tĂ« temĂ«:
- .
- .
- .
Burimi: habr.com
