Një herë ne furnizuam një sistem elektronik të menaxhimit të dokumenteve për një klient në një objekt. Dhe pastaj në një objekt tjetër. Dhe një tjetër. Dhe në të katërtin dhe në të pestën. U morëm aq shumë sa arritëm në 10 objekte të shpërndara. Doli fuqishëm... veçanërisht kur arritëm të dorëzonim ndryshimet. Si pjesë e dorëzimit në qarkun e prodhimit, 5 skenarë të sistemit të testimit kërkonin përfundimisht 10 orë dhe 6-7 punonjës. Kostot e tilla na detyruan të bëjmë dërgesa sa më rrallë. Pas tre vitesh funksionimi, ne nuk duruam dot dhe vendosëm ta shijonim projektin me një majë DevOps.
Tani i gjithë testimi bëhet në 3 orë, dhe 3 persona marrin pjesë në të: një inxhinier dhe dy testues. Përmirësimet shprehen qartë në shifra dhe çojnë në një reduktim të TTM-së shumë të dashur. Në përvojën tonë, ka shumë më tepër klientë që mund të përfitojnë nga DevOps sesa ata që madje dinë për të. Prandaj, për të sjellë DevOps më afër njerëzve, ne kemi zhvilluar një konstruktor të thjeshtë, për të cilin do të flasim më në detaje në këtë postim.
Tani le t'ju tregojmë më në detaje. Një kompani energjetike po vendos një sistem të menaxhimit të dokumenteve teknike në 10 objekte të mëdha. Nuk është e lehtë të lundrosh në projekte të kësaj shkalle pa DevOps, sepse një pjesë e madhe e punës manuale e vonon shumë punën dhe gjithashtu ul cilësinë - e gjithë puna manuale është e mbushur me gabime. Nga ana tjetër, ka projekte ku ka vetëm një instalim, por gjithçka duhet të funksionojë automatikisht, vazhdimisht dhe pa dështim - për shembull, të njëjtat sisteme të rrjedhës së dokumenteve në organizata të mëdha monolite. Përndryshe, dikush do të bëjë cilësimet me dorë, do të harrojë udhëzimet e vendosjes - dhe si rezultat, në prodhim cilësimet do të humbasin dhe gjithçka do të shembet.
Zakonisht ne punojmë me klientin përmes një kontrate dhe në këtë rast interesat tona ndryshojnë pak. Konsumatori e shikon projektin në mënyrë rigoroze brenda buxhetit dhe specifikimeve teknike. Mund të jetë e vështirë t'i shpjegosh atij përfitimet e praktikave të ndryshme të DevOps që nuk përfshihen në specifikimet teknike. Po nëse ai është i interesuar për lëshime të shpejta me vlerë të shtuar biznesi, ose në ndërtimin e një tubacioni automatizimi?
Mjerisht, kur punoni me një kosto të para-miratuar, ky interes nuk gjendet gjithmonë. Në praktikën tonë, ka pasur një rast kur na është dashur të marrim zhvillimin e një kontraktori të paskrupullt dhe të pakujdesshëm. Ishte e tmerrshme: nuk kishte kode burimore të përditësuara, baza e kodit të të njëjtit sistem ishte e ndryshme në instalime të ndryshme, dokumentacioni mungonte pjesërisht dhe pjesërisht me cilësi të tmerrshme. Sigurisht, klienti nuk kishte kontroll mbi kodin burimor, montimin, lëshimet, etj.
Deri më tani, jo të gjithë e dinë për DevOps, por sapo flasim për avantazhet e tij, për kursimet reale të burimeve, sytë e të gjithë klientëve ndizen. Pra, numri i kërkesave që përfshijnë DevOps po rritet me kalimin e kohës. Këtu, për të folur me lehtësi të njëjtën gjuhë me klientët, duhet të lidhim shpejt problemet e biznesit dhe praktikat e DevOps që do të ndihmojnë në ndërtimin e një tubacioni të përshtatshëm zhvillimi.
Pra, ne kemi një sërë problemesh nga njëra anë, kemi njohuri, praktika dhe mjete DevOps nga ana tjetër. Pse të mos e ndani përvojën me të gjithë?
Krijimi i një konstruktori DevOps
Agile ka manifestin e vet. ITIL ka metodologjinë e vet. DevOps është më pak me fat - nuk ka fituar ende shabllone dhe standarde. Edhe pse të përcaktojë maturimin e kompanive bazuar në një vlerësim të zhvillimit të tyre dhe praktikave operacionale.
Për fat të mirë, kompania e njohur Gartner në vitin 2014 dhe analizoi praktikat kryesore të DevOps dhe marrëdhëniet midis tyre. Bazuar në këtë, unë lëshova një infografik:
Ne e morëm atë si bazë për tonën . Secila nga katër fushat ka një grup mjetesh - ne i mblodhëm ato në një bazë të dhënash, identifikuam ato më të njohurat, identifikuam pikat e integrimit dhe mekanizmat e përshtatshëm optimizimi. Në total doli 36 praktika dhe 115 mjete, një e katërta e të cilave janë me burim të hapur ose softuer të lirë. Më pas, do të flasim për atë që kemi arritur në secilën fushë dhe, si shembull, për mënyrën se si u zbatua kjo në projektin për krijimin e menaxhimit të dokumenteve teknike, me të cilin filluam postimin.
proceset
Në projektin famëkeq EDMS, sistemi i menaxhimit të dokumentacionit teknik u vendos sipas të njëjtës skemë në secilin prej 10 objekteve. Instalimi përfshin 4 serverë: serverin e bazës së të dhënave, serverin e aplikacionit, indeksimin e tekstit të plotë dhe menaxhimin e përmbajtjes. Në instalim, ato funksionojnë brenda një nyje të vetme dhe janë të vendosura në qendrën e të dhënave në objekte. Të gjitha objektet ndryshojnë pak në infrastrukturë, por kjo nuk ndërhyn në ndërveprimin global.
Së pari, sipas praktikave të DevOps, ne automatizuam infrastrukturën në nivel lokal, më pas sollëm dorëzimin në qarkun e testimit dhe më pas në produktin e klientit. Çdo proces u përpunua hap pas hapi. Cilësimet e mjedisit janë të fiksuara në sistemin e kodit burimor, duke marrë parasysh se cili komplet i shpërndarjes është përpiluar për përditësimin automatik. Në rast të ndryshimeve të konfigurimit, inxhinierët thjesht duhet të bëjnë ndryshimet e duhura në sistemin e kontrollit të versionit - dhe më pas përditësimi automatik do të bëhet pa probleme.
Falë kësaj qasjeje, procesi i testimit është thjeshtuar shumë. Më parë, projekti kishte testues që nuk bënin gjë tjetër veçse përditësonin manualisht stendat. Tani ata thjesht vijnë, shohin që gjithçka po funksionon dhe bëjnë gjëra më të dobishme. Çdo përditësim testohet automatikisht - nga niveli i sipërfaqes deri te automatizimi i skenarit të biznesit. Rezultatet janë postuar si raporte të veçanta në TestRail.
Культура
Eksperimentimi i vazhdueshëm shpjegohet më së miri përmes shembullit të projektimit të testit. Testimi i një sistemi që nuk ekziston ende është punë krijuese. Kur shkruani një plan testimi, duhet të kuptoni se si të testoni saktë dhe cilat degë të ndiqni. Dhe gjithashtu gjeni një ekuilibër midis kohës dhe buxhetit për të përcaktuar numrin optimal të kontrolleve. Është e rëndësishme të zgjidhni saktësisht testet e nevojshme, të mendoni se si përdoruesi do të ndërveprojë me sistemin, të marrë parasysh mjedisin dhe faktorët e mundshëm të jashtëm. Është e pamundur të bëhet pa eksperimente të vazhdueshme.
Tani për kulturën e ndërveprimit. Më parë, kishte dy anët e kundërta - inxhinierët dhe zhvilluesit. Zhvilluesit thanë: “Nuk na intereson se si do të lansohet. Ju jeni inxhinierë, jeni të zgjuar, sigurohuni që të funksionojë pa dështime". Inxhinierët u përgjigjën: “Ju zhvilluesit jeni shumë të pakujdesshëm. Le të jemi më të kujdesshëm dhe do t'i luajmë më rrallë publikimet tuaja. Sepse sa herë që na jepni një kod që rrjedh, nuk është e qartë për ne se si të ndërveprojmë.”. Kjo është një çështje ndërveprimi kulturor që është strukturuar ndryshe nga perspektiva e DevOps. Këtu, si inxhinierët ashtu edhe zhvilluesit janë pjesë e një ekipi të vetëm që është i fokusuar në ndryshimin e vazhdueshëm, por në të njëjtën kohë softuer të besueshëm.
Brenda të njëjtit ekip, specialistët janë të vendosur të ndihmojnë njëri-tjetrin. Ashtu siç ishte më parë? Për shembull, po përgatiteshin disa udhëzime të trasha vendosjeje, rreth 50 faqe. Inxhinieri e lexoi, nuk kuptoi diçka, mallkoi dhe i kërkoi zhvilluesit në orën tre të mëngjesit të komentonte. Zhvilluesi komentoi dhe gjithashtu mallkoi - në fund, askush nuk ishte i lumtur. Plus, natyrisht, kishte disa gabime, sepse nuk mund të mbani mend gjithçka në udhëzime. Dhe tani inxhinieri, së bashku me zhvilluesin, po shkruajnë një skenar për vendosjen e automatizuar të infrastrukturës së softuerit të aplikacionit. Dhe ata flasin me njëri-tjetrin praktikisht në të njëjtën gjuhë.
Njerëz
Madhësia e ekipit përcaktohet nga qëllimi i përditësimit. Ekipi rekrutohet gjatë formimit të dorëzimit; ai përfshin të interesuarit nga ekipi i përgjithshëm i projektit. Më pas shkruhet një plan përditësimi me përgjegjësit për secilën fazë dhe ekipi raporton ndërsa përparon. Të gjithë anëtarët e ekipit janë të këmbyeshëm. Si pjesë e ekipit, ne kemi gjithashtu një zhvillues rezervë, por ai pothuajse kurrë nuk duhet të lidhet.
Teknologji
Në diagramin e teknologjisë, theksohen disa pika, por nën to ka një mori teknologjish - mund të botoni një libër të tërë me përshkrimet e tyre. Pra, ne do të theksojmë më interesantet.
Infrastruktura si Kod
Tani, me siguri, ky koncept nuk do të habisë askënd, por më parë përshkrimet e infrastrukturave linin shumë për të dëshiruar. , mjediset e provës ishin unike, ato ishin të dashura dhe të dashura, grimcat e pluhurit u hodhën në erë.
Në ditët e sotme askush nuk ka frikë të eksperimentojë. Ka imazhe bazë të makinave virtuale dhe skenarë të gatshëm për vendosjen e mjediseve. Të gjithë shabllonet dhe skriptet ruhen në një sistem kontrolli versionesh dhe përditësohen menjëherë. Më parë, kur ishte e nevojshme të dorëzohej një paketë në një stendë, u shfaq një boshllëk konfigurimi. Tani ju vetëm duhet të shtoni një rresht në kodin burimor.
Përveç skripteve të infrastrukturës dhe tubacioneve, qasja e Dokumentacionit si kod përdoret gjithashtu për dokumentacion. Falë kësaj, është e lehtë të lidhni njerëz të rinj me projektin, t'i prezantoni ata me sistemin bazuar në funksionet e përshkruara, për shembull, në planin e provës, dhe gjithashtu të ripërdorni rastet e provës.
Dorëzimi dhe monitorimi i vazhdueshëm
në lidhje me DevOps, ne folëm se si kemi zgjedhur mjetet për zbatimin e shpërndarjes dhe monitorimit të vazhdueshëm. Shpesh nuk ka nevojë të rishkruhet asgjë - mjafton të përdorni skriptet e shkruara më parë, të ndërtoni saktë integrimin midis komponentëve dhe të krijoni një tastierë të përbashkët menaxhimi. Dhe të gjitha proceset mund të nisen duke përdorur një buton ose orar.
Në anglisht ka koncepte të ndryshme, Dorëzim i vazhdueshëm dhe Vendosje e vazhdueshme. Të dyja mund të përkthehen si "dorëzimi i vazhdueshëm", por në fakt ka një ndryshim të vogël midis tyre. Në projektin tonë për rrjedhën e dokumenteve teknike të një kompanie energjetike të shpërndarë, përdoret Dorëzimi - kur instalimi për prodhim ndodh me komandë. Në Deployment, instalimi ndodh automatikisht. Dorëzimi i vazhdueshëm në këtë projekt është bërë përgjithësisht pjesa qendrore e DevOps.
Në përgjithësi, duke mbledhur disa parametra, mund të kuptoni qartë pse praktikat DevOps janë të dobishme. Dhe ia transmetoni këtë menaxhmentit, i cili me të vërtetë i do numrat. Numri i përgjithshëm i nisjeve, koha e ekzekutimit të fazave të skenarit, pjesa e lëshimeve të suksesshme - e gjithë kjo ndikon drejtpërdrejt në kohën e preferuar të të gjithëve për në treg, domethënë, kohën nga një kryerje në sistemin e kontrollit të versionit deri në lëshimin e një versioni në një mjedisi i prodhimit. Me zbatimin e mjeteve të nevojshme, inxhinierët marrin tregues të vlefshëm me postë dhe menaxheri i projektit i sheh ato në pult. Në këtë mënyrë ju mund të vlerësoni menjëherë përfitimet e mjeteve të reja. Dhe mund t'i provoni në infrastrukturën tuaj duke përdorur projektuesin DevOps.
Kush do të ketë nevojë për tonën ?
Le të mos pretendojmë: për fillim ai u bë i dobishëm për ne. Siç kemi thënë tashmë, ju duhet të flisni të njëjtën gjuhë me klientin dhe me ndihmën e projektuesit të DevOps ne mund të skicojmë shpejt bazën për një bisedë të tillë. Specialistët e biznesit do të jenë në gjendje të vlerësojnë vetë se çfarë kanë nevojë dhe kështu të zhvillohen më shpejt. Ne u përpoqëm ta bënim projektuesin sa më të detajuar, duke shtuar një mori përshkrimesh në mënyrë që çdo përdorues të kuptojë se çfarë po zgjedh.
Formati i projektuesit ju lejon të merrni parasysh zhvillimet ekzistuese të kompanisë në proceset e ndërtimit dhe automatizimin. Nuk ka nevojë të rrënoni gjithçka dhe ta rindërtoni atë nëse mund të zgjidhni vetëm zgjidhje që integrohen mirë me proceset ekzistuese dhe që thjesht mund të mbushin boshllëqet.
Ndoshta zhvillimi juaj tashmë është zhvendosur në një nivel më të lartë dhe mjeti ynë do të duket shumë "kapiten". Por ne e shohim të dobishme për veten tonë dhe shpresojmë se do të jetë e dobishme për disa nga lexuesit. Ju kujtojmë për projektuesin - nëse ka ndonjë gjë, ju e merrni diagramin menjëherë pasi të keni futur të dhënat fillestare. Ne do të jemi mirënjohës për komentet dhe shtesat tuaja.
Burimi: www.habr.com