Jednom smo kupcu u jednom objektu isporučili sustav za elektroničko upravljanje dokumentima. A onda na drugi objekt. I još jedan. I na četvrtom, i na petom. Toliko smo se zanijeli da smo došli do 10 podijeljenih objekata. Ispalo je snažno... pogotovo kada smo morali uvesti promjene. U sklopu isporuke proizvodnom krugu, 5 scenarija sustava testiranja u konačnici je zahtijevalo 10 sati i 6-7 zaposlenika. Takvi su nas troškovi tjerali da isporuke obavljamo što rjeđe. Nakon tri godine rada, nismo izdržali i odlučili smo projekt začiniti prstohvatom DevOpsa.
Sada se sva testiranja odvijaju u 3 sata, au njima sudjeluju 3 osobe: inženjer i dva testera. Poboljšanja su jasno izražena u brojkama i dovode do smanjenja toliko voljenog TTM-a. Prema našem iskustvu, mnogo je 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 tvrtka uvodi sustav upravljanja tehničkom dokumentacijom na 10 velikih objekata. Nije lako upravljati projektima ove razmjere bez DevOps-a, jer veliki udio ručnog rada uvelike odgađa rad i također smanjuje kvalitetu - sav ručni rad prepun je pogrešaka. S druge strane, postoje projekti u kojima postoji samo jedna instalacija, ali sve treba raditi automatski, stalno i bez greške - na primjer, isti sustavi protoka dokumenata u velikim monolitnim organizacijama. Inače će netko 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 s kupcem radimo putem ugovora, au ovom slučaju naši se interesi malo razlikuju. Kupac gleda na projekt strogo unutar proračuna 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 ga zanimaju brza izdanja s dodanom poslovnom vrijednošću ili izgradnja cjevovoda za automatizaciju?
Jao, kada radite s unaprijed odobrenim troškom, ovaj interes nije uvijek pronađen. 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žurnih izvornih kodova, kodna baza istog sustava bila je različita na različitim instalacijama, dokumentacija je djelomično nedostajala, a djelomično je bila užasne kvalitete. Naravno, kupac nije imao kontrolu nad izvornim kodom, asemblerom, izdanjima itd.
Za sada ne znaju svi za DevOps, ali čim govorimo o njegovim prednostima, o stvarnoj uštedi resursa, oči svih kupaca zasjaju. Stoga se broj zahtjeva koji uključuju DevOps s vremenom povećava. Ovdje, kako bismo lako govorili istim jezikom s korisnicima, moramo brzo povezati poslovne probleme i DevOps prakse koje će pomoći u izgradnji odgovarajućeg razvojnog kanala.
Dakle, imamo skup problema s jedne strane, imamo DevOps znanje, prakse i alate s druge strane. Zašto ne podijeliti iskustvo sa svima?
Stvaranje DevOps konstruktora
Agile ima svoj manifest. ITIL ima svoju metodologiju. DevOps je manje sretan - još nije nabavio predloške i standarde. Iako utvrditi zrelost poduzeća na temelju procjene njihovog razvoja i prakse poslovanja.
Srećom, poznata tvrtka Gartner 2014.g i analizirali ključne DevOps prakse i odnose među njima. Na temelju toga objavio sam infografiku:
Uzeli smo to kao osnovu za naš . Svako od četiri područja ima set alata - sakupili smo ih u bazu podataka, identificirali najpopularnije, identificirali točke integracije i prikladne mehanizme optimizacije. Ukupno se pokazalo 36 praksi i 115 alata, od kojih je četvrtina open source ili besplatni softver. Zatim ćemo govoriti o tome što smo postigli u svakom području i, kao primjer, o tome kako je to implementirano u projektu izrade tehničkog upravljanja dokumentima, s kojim smo započeli post.
procesi
U ozloglašenom projektu EDMS, sustav upravljanja tehničkom dokumentacijom bio je raspoređen prema istoj shemi na svakom od 10 objekata. Instalacija uključuje 4 poslužitelja: poslužitelj baze podataka, poslužitelj aplikacija, indeksiranje punog teksta i upravljanje sadržajem. U instalaciji rade unutar jednog čvora i nalaze se u podatkovnom centru u objektima. Svi se objekti malo razlikuju u infrastrukturi, ali to ne ometa globalnu interakciju.
Prvo smo, u skladu s DevOps praksom, lokalno automatizirali infrastrukturu, zatim smo isporuku doveli do testnog kruga, a zatim do kupčevog proizvoda. Svaki proces je razrađen korak po korak. Postavke okruženja fiksirane su u sustavu izvornog koda, uzimajući u obzir koji je distribucijski komplet sastavljen za automatsko ažuriranje. U slučaju promjena konfiguracije, inženjeri jednostavno trebaju napraviti odgovarajuće promjene u sustavu kontrole verzija - i tada će se automatsko ažuriranje odvijati bez problema.
Zahvaljujući ovom pristupu, proces testiranja je znatno pojednostavljen. Prethodno je projekt imao testere koji nisu radili ništa osim ručnog ažuriranja postolja. Sada samo dođu, vide da sve funkcionira i rade korisnije stvari. Svako ažuriranje testira se automatski - od površinske razine do automatizacije poslovnog scenarija. Rezultati se objavljuju kao zasebna izvješća u TestRailu.
Kultura
Kontinuirano eksperimentiranje najbolje je objasniti kroz primjer dizajna testa. Testiranje sustava koji još ne postoji je kreativan posao. Kada pišete plan testiranja, morate razumjeti kako ispravno testirati i koje grane slijediti. Također pronađite ravnotežu između vremena i proračuna kako biste odredili optimalan broj provjera. Važno je odabrati točno potrebne testove, razmisliti o tome kako će korisnik komunicirati sa sustavom, uzeti u obzir okolinu i moguće vanjske čimbenike. Nemoguće je bez kontinuiranog eksperimentiranja.
Sada o kulturi interakcije. Prije su postojale dvije suprotstavljene strane - inženjeri i programeri. Programeri su rekli: “Nije nas briga kako će biti lansiran. 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 kad nam date šifru koja curi, nije nam jasno kako komunicirati.”. 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 stalno promjenjiv, ali u isto vrijeme pouzdan softver.
Unutar istog tima stručnjaci su odlučni pomoći jedni drugima. Kako je bilo prije? Na primjer, spremale su se neke debele upute za implementaciju, oko 50 stranica, inženjer ih je pročitao, nešto mu nije bilo jasno, opsovao je i pitao programera u tri sata ujutro za komentar. Programer je komentirao i također psovao – na kraju nitko nije bio zadovoljan. Osim toga, naravno, bilo je grešaka, jer se ne možete sjetiti svega u uputama. A sada inženjer, zajedno s programerom, piše skriptu za automatiziranu implementaciju infrastrukture aplikacijskog softvera. I međusobno govore praktički istim jezikom.
Ljudi
Veličina tima određena je opsegom ažuriranja. Tim se regrutira tijekom formiranja isporuke, a uključuje zainteresirane iz općeg projektnog tima. Zatim se piše plan ažuriranja s onima koji su odgovorni za svaku fazu, a tim izvještava kako napreduje. Svi članovi tima su zamjenjivi. U timu imamo i backup developera, no on se gotovo nikad ne mora spajati.
Tehnologija
U tehnološkom dijagramu istaknuto je nekoliko točaka, ali ispod njih je hrpa tehnologija - mogli biste objaviti cijelu knjigu s njihovim opisima. Stoga ćemo istaknuti najzanimljivije.
Infrastruktura kao kod
Sada, vjerojatno, ovaj koncept neće nikoga iznenaditi, ali prethodno su opisi infrastrukture ostavljali mnogo za željeti. , ispitna su okruženja bila jedinstvena, njegovala se i njegovala, čestice prašine otpuhivale su s njih.
Danas se nitko ne boji eksperimentirati. Postoje osnovne slike virtualnih strojeva, postoje gotovi scenariji za implementaciju okruženja. Svi predlošci i skripte pohranjeni su u sustavu kontrole verzija i promptno se ažuriraju. Ranije, kada je bilo potrebno dostaviti paket na postolje, pojavio se nedostatak konfiguracije. Sada samo trebate dodati redak izvornom kodu.
Osim infrastrukturnih skripti i cjevovoda, za dokumentaciju se također koristi pristup Dokumentacija kao kod. Zahvaljujući tome, lako je povezati nove ljude s projektom, upoznati ih sa sustavom na temelju funkcija opisanih, na primjer, u planu testiranja, te ponovno 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 praćenja. Često nema potrebe ništa prepisivati - dovoljno je koristiti prethodno napisane skripte, ispravno izgraditi integraciju između komponenti i stvoriti zajedničku upravljačku konzolu. I svi se procesi mogu pokrenuti pomoću jednog gumba ili rasporeda.
U engleskom jeziku postoje različiti koncepti, Continuous Delivery i Continuous Deployment. Oba se mogu prevesti kao "kontinuirana isporuka", ali zapravo postoji mala razlika između njih. U našem projektu za tijek tehničke dokumentacije tvrtke za distribuiranu energiju koristi se Isporuka - kada se instalacija za proizvodnju odvija na naredbu. U postavljanju, instalacija se odvija automatski. Kontinuirana isporuka u ovom projektu općenito je postala središnji dio DevOps-a.
Općenito, prikupljanjem određenih parametara možete jasno razumjeti zašto su DevOps prakse korisne. I prenesite to upravi, koja stvarno voli brojke. Ukupan broj lansiranja, vrijeme izvršenja faza skripte, udio uspješnih lansiranja - sve to izravno utječe na svačije omiljeno vrijeme izlaska na tržište, odnosno vrijeme od predaje u sustav kontrole verzije do izdanja verzije na proizvodno okruženje. Uz implementaciju potrebnih alata, inženjeri dobivaju vrijedne pokazatelje poštom, a voditelj projekta ih vidi na nadzornoj ploči. Na taj način možete odmah procijeniti prednosti novih alata. Možete ih isprobati na svojoj infrastrukturi koristeći DevOps dizajner.
Kome će trebati naš ?
Nemojmo se pretvarati: za početak, postao nam je koristan. Kao što smo već rekli, s korisnikom 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 što im je potrebno i tako se brže razvijati. Dizajner smo pokušali učiniti što detaljnijim, dodajući hrpu opisa kako bi svaki korisnik razumio što bira.
Format dizajnera omogućuje vam da uzmete u obzir postojeći razvoj tvrtke u građevinskim procesima i automatizaciji. Nema potrebe sve rušiti i ponovno graditi ako samo možete odabrati rješenja koja se dobro integriraju s postojećim procesima i koja mogu jednostavno popuniti praznine.
Možda je vaš razvoj već prešao na višu razinu i naš alat će vam se činiti previše "kapetanskim". Ali smatramo da je koristan za sebe i nadamo se da će biti od koristi nekome od čitatelja. Podsjećamo vas projektantu - ako ništa, dijagram dobijete odmah nakon unosa početnih podataka. Bit ćemo vam zahvalni na povratnim informacijama i dodacima.
Izvor: www.habr.com