Jednom smo kupcu u jednom objektu isporučili elektronski sistem upravljanja dokumentima. A onda na drugi objekat. I još jedan. I na četvrtom, i na petom. Toliko smo se zanijeli da smo stigli do 10 distribuiranih objekata. Ispalo je snažno... posebno kada smo došli do promjena. Kao dio isporuke u krug proizvodnje, 5 scenarija sistema testiranja na kraju je zahtijevalo 10 sati i 6-7 zaposlenih. Takvi troškovi su nas natjerali da što rjeđe vršimo isporuke. Nakon tri godine rada, nismo izdržali i odlučili smo da začinimo projekat s prstohvatom DevOps-a.
Sada se sva testiranja odvijaju za 3 sata, a u njemu učestvuju 3 osobe: inženjer i dva testera. Poboljšanja su jasno izražena u brojevima i dovode do smanjenja toliko voljenog TTM-a. Prema našem iskustvu, postoji mnogo više kupaca koji mogu imati koristi od DevOps-a nego onih koji uopće znaju za njega. Stoga, kako bismo DevOps približili ljudima, razvili smo jednostavan konstruktor o kojem ćemo detaljnije govoriti u ovom postu.
Sada ćemo vam reći detaljnije. Jedna energetska kompanija uvodi sistem upravljanja tehničkom dokumentacijom na 10 velikih objekata. Nije lako kretati se projektima ovog obima bez DevOps-a, jer veliki udio ručnog rada uvelike odlaže rad, a ujedno i smanjuje kvalitetu - sav ručni rad je prepun grešaka. S druge strane, postoje projekti u kojima postoji samo jedna instalacija, ali sve treba da radi automatski, stalno i bez kvarova - na primjer, isti sistemi toka dokumenata u velikim monolitnim organizacijama. U suprotnom će neko ručno izvršiti postavke, zaboraviti na upute za implementaciju - i kao rezultat toga, u proizvodnji će se postavke izgubiti i sve će se srušiti.
Obično sa kupcem radimo preko ugovora, au ovom slučaju se naši interesi malo razilaze. Kupac gleda na projekat striktno u okviru budžeta i tehničkih specifikacija. Može biti teško objasniti mu prednosti raznih DevOps praksi koje nisu uključene u tehničke specifikacije. Što ako je zainteresiran za brza izdanja s dodatnom poslovnom vrijednošću ili za izgradnju procesa automatizacije?
Nažalost, kada se radi s unaprijed odobrenim troškovima, ovaj interes se ne pronađe uvijek. U našoj praksi bio je slučaj kada smo morali pokupiti razvoj beskrupuloznog i nemarnog izvođača. Bilo je strašno: nije bilo ažuriranih izvornih kodova, baza kodova istog sistema je bila različita na različitim instalacijama, dokumentacija je bila djelimično odsutna, a dijelom užasnog kvaliteta. Naravno, kupac nije imao kontrolu nad izvornim kodom, montažom, izdanjima itd.
Do sada nisu svi znali za DevOps, ali čim progovorimo o njegovim prednostima, o stvarnoj uštedi resursa, oči svih kupaca zasvijetle. Dakle, broj zahtjeva koji uključuju DevOps vremenom raste. Ovdje, kako bismo lako razgovarali istim jezikom s klijentima, moramo brzo povezati poslovne probleme i DevOps prakse koje će pomoći u izgradnji odgovarajućeg razvojnog cevovoda.
Dakle, imamo skup problema s jedne strane, imamo DevOps znanja, prakse i alate s druge strane. Zašto ne podijeliti iskustvo sa svima?
Kreiranje DevOps konstruktora
Agile ima svoj manifest. ITIL ima svoju metodologiju. DevOps ima manje sreće - još nije nabavio šablone i standarde. Iako odrediti zrelost kompanija na osnovu procjene njihovog razvoja i operativne prakse.
Na sreću, poznata kompanija Gartner je 2014 i analizirali ključne DevOps prakse i odnose između njih. Na osnovu toga, objavio sam infografiku:
Uzeli smo to kao osnovu za naše . Svaka od četiri oblasti ima skup alata – prikupili smo ih u bazu podataka, identifikovali najpopularnije, identifikovali tačke integracije i odgovarajuće mehanizme optimizacije. Ukupno se ispostavilo 36 vježbi i 115 alata, od kojih je četvrtina otvorenog koda ili besplatni softver. Zatim ćemo govoriti o tome šta smo postigli u svakoj oblasti i, kao primjer, o tome kako je to implementirano u projektu kreiranja tehničkog upravljanja dokumentima, s kojim smo započeli post.
Procesi
U ozloglašenom projektu EDMS sistem upravljanja tehničkom dokumentacijom je raspoređen po istoj šemi na svakom od 10 objekata. Instalacija uključuje 4 servera: server baze podataka, server aplikacija, indeksiranje punog teksta i upravljanje sadržajem. U instalaciji rade u okviru jednog čvora i nalaze se u data centru na objektima. Svi objekti se neznatno razlikuju u infrastrukturi, ali to ne ometa globalnu interakciju.
Prvo smo, prema DevOps praksi, automatizirali infrastrukturu lokalno, zatim smo doveli isporuku do testnog kruga, a potom i do proizvoda kupca. Svaki proces je razrađen korak po korak. Postavke okruženja su fiksirane u sistemu izvornog koda, uzimajući u obzir koji se komplet za distribuciju kompajlira za automatsko ažuriranje. U slučaju promjena konfiguracije, inženjeri jednostavno trebaju izvršiti odgovarajuće promjene u sistemu kontrole verzija - i tada će se automatsko ažuriranje odvijati bez problema.
Zahvaljujući ovom pristupu, proces testiranja je znatno pojednostavljen. Ranije je projekat imao testere koji nisu radili ništa osim ručno ažurirali štandove. Sada samo dođu, vide da sve radi i urade još korisnije stvari. Svako ažuriranje se testira automatski - od površinskog nivoa do automatizacije poslovnog scenarija. Rezultati se objavljuju kao zasebni izvještaji u TestRail-u.
Kultura
Kontinuirano eksperimentiranje najbolje se može objasniti kroz primjer dizajna testa. Testiranje sistema koji još ne postoji je kreativan posao. Kada pišete plan testiranja, morate razumjeti kako ispravno testirati i koje grane slijediti. I također pronađite ravnotežu između vremena i budžeta kako biste odredili optimalan broj provjera. Važno je odabrati tačno potrebne testove, razmisliti o tome kako će korisnik komunicirati sa sistemom, uzeti u obzir okruženje i moguće vanjske faktore. Nemoguće je bez kontinuiranog eksperimentiranja.
Sada o kulturi interakcije. Ranije su postojale dvije suprotstavljene strane - inženjeri i programeri. Programeri su rekli: “Nije nas briga kako će to biti pokrenuto. Vi ste inženjeri, pametni ste, pobrinite se da radi bez kvarova". Inženjeri su odgovorili: “Vi programeri ste previše nemarni. Budimo oprezniji i rjeđe ćemo puštati vaša izdanja. Jer svaki put kada nam date kod koji curi, nije nam jasno kako da komuniciramo.”. Ovo je pitanje kulturne interakcije koje je drugačije strukturirano iz DevOps perspektive. Ovdje su i inženjeri i programeri dio jedinstvenog tima koji je fokusiran na konstantno mijenjanje, ali u isto vrijeme pouzdan softver.
Unutar istog tima, stručnjaci su odlučni da pomažu jedni drugima. Kako je bilo prije? Na primjer, spremale su se neke debele upute za implementaciju, oko 50 stranica, inženjer je pročitao, nešto nije razumio, opsovao i tražio od developera u tri sata ujutro da prokomentariše. Programer je komentarisao i psovao - na kraju niko nije bio zadovoljan. Osim toga, naravno, bilo je i grešaka, jer ne možete se sjetiti svega u uputama. A sada inženjer, zajedno sa programerom, piše skriptu za automatizovano postavljanje infrastrukture aplikativnog softvera. I razgovaraju jedni s drugima praktično na istom jeziku.
ljudi
Veličina tima je određena opsegom ažuriranja. Tim se regrutuje prilikom formiranja isporuke i uključuje zainteresovane iz generalnog projektnog tima. Zatim se napiše plan ažuriranja sa odgovornima za svaku fazu, a tim izvještava kako napreduje. Svi članovi tima su zamjenjivi. Kao dio tima, imamo i backup programera, ali on se gotovo nikad ne mora povezati.
tehnologije
U tehnološkom dijagramu je istaknuto nekoliko tačaka, ali ispod njih postoji gomila tehnologija - mogli biste objaviti cijelu knjigu s njihovim opisima. Stoga ćemo izdvojiti najzanimljivije.
Infrastruktura kao kod
Sada, vjerovatno, ovaj koncept nikoga neće iznenaditi, ali ranije su opisi infrastrukture ostavljali mnogo željenog. , testna okruženja su bila jedinstvena, njegovana su i njegovana, čestice prašine su otpuhane s njih.
Danas se niko ne plaši eksperimentisanja. Postoje osnovne slike virtuelnih mašina, postoje gotovi scenariji za implementaciju okruženja. Svi predlošci i skripti su pohranjeni u sistemu kontrole verzija i promptno se ažuriraju. Ranije, kada je bilo potrebno isporučiti paket na štand, pojavio se propust u konfiguraciji. Sada samo trebate dodati liniju izvornom kodu.
Pored infrastrukturnih skripti i cevovoda, za dokumentaciju se koristi i pristup Dokumentacija kao kod. Zahvaljujući tome, lako je povezati nove ljude s projektom, uvesti ih u sistem na osnovu funkcija opisanih, na primjer, u planu testiranja, kao i ponovo koristiti testne slučajeve.
Kontinuirana isporuka i praćenje
o DevOps-u, razgovarali smo o tome kako smo odabrali alate za implementaciju kontinuirane isporuke i nadgledanja. Često nema potrebe da se bilo šta prepisuje - dovoljno je koristiti prethodno napisane skripte, pravilno izgraditi integraciju između komponenti i kreirati zajedničku upravljačku konzolu. A svi procesi se mogu pokrenuti pomoću jednog dugmeta ili rasporeda.
Na engleskom postoje različiti koncepti, Continuous Delivery i Continuous Deployment. Oboje se može prevesti kao „kontinuirana isporuka“, ali u stvari postoji mala razlika između njih. U našem projektu za tok tehničke dokumentacije distribuirane energetske kompanije koristi se, radije, Isporuka - kada se instalacija za proizvodnju odvija na komandu. U Deploymentu, instalacija se odvija automatski. Kontinuirana isporuka u ovom projektu je općenito postala centralni deo DevOps-a.
Općenito, prikupljanjem određenih parametara možete jasno razumjeti zašto su DevOps prakse korisne. I prenesite ovo menadžmentu, koji zaista voli brojke. Ukupan broj pokretanja, vrijeme izvršavanja faza skripte, udio uspješnih pokretanja - sve to direktno utiče na svačije omiljeno vrijeme na tržištu, odnosno na vrijeme od urezivanja na sistem kontrole verzija do objavljivanja verzije na proizvodno okruženje. Uz implementaciju potrebnih alata, inženjeri dobijaju vrijedne indikatore poštom, a voditelj projekta ih vidi na kontrolnoj tabli. Na taj način možete odmah procijeniti prednosti novih alata. I možete ih isprobati na svojoj infrastrukturi koristeći DevOps dizajner.
Kome će trebati naše ?
Nemojmo se pretvarati: za početak nam je postao koristan. Kao što smo već rekli, sa kupcem morate razgovarati istim jezikom, a uz pomoć DevOps dizajnera možemo brzo skicirati osnovu za takav razgovor. Poslovni stručnjaci moći će sami procijeniti šta im je potrebno i tako se brže razvijati. Potrudili smo se da dizajner bude što detaljniji, dodajući gomilu opisa kako bi svaki korisnik shvatio šta bira.
Format dizajnera vam omogućava da uzmete u obzir postojeći razvoj kompanije u procesima izgradnje i automatizaciji. Nema potrebe da sve rušite i ponovo gradite ako možete odabrati samo rješenja koja se dobro integriraju s postojećim procesima i koja jednostavno mogu popuniti praznine.
Možda je vaš razvoj već prešao na viši nivo i naš alat će se činiti previše "kapetanskim". Ali smatramo da je to korisno za sebe i nadamo se da će biti od koristi nekom od čitalaca. Podsjećamo vas dizajneru - ako ništa drugo, dobijete dijagram odmah nakon unosa početnih podataka. Bit ćemo zahvalni na vašim povratnim informacijama i dopunama.
izvor: www.habr.com