Vi leverte en gang et elektronisk dokumenthåndteringssystem til en kunde ved ett anlegg. Og så til et annet objekt. Og en til. Og på den fjerde, og på den femte. Vi ble så revet med at vi nådde 10 fordelte gjenstander. Det viste seg kraftig ... spesielt når vi kom til å levere endringene. Som en del av leveransen til produksjonskretsen krevde 5 scenarier av testsystemet til slutt 10 timer og 6-7 ansatte. Slike kostnader tvang oss til å utføre leveranser så sjelden som mulig. Etter tre års drift klarte vi det ikke og bestemte oss for å krydre prosjektet med en klype DevOps.
Nå foregår all testing på 3 timer, og 3 personer deltar i den: en ingeniør og to testere. Forbedringene kommer tydelig til uttrykk i tall og fører til en reduksjon i den høyt elskede TTM. Vår erfaring er at det er mange flere kunder som kan dra nytte av DevOps enn de som selv vet om det. Derfor, for å bringe DevOps nærmere folk, har vi utviklet en enkel konstruktør, som vi vil snakke mer om i dette innlegget.
La oss nå fortelle deg mer detaljert. Ett energiselskap implementerer et teknisk dokumenthåndteringssystem på 10 store anlegg. Det er ikke lett å navigere i prosjekter av denne skalaen uten DevOps, fordi en stor andel manuelt arbeid forsinker arbeidet kraftig og reduserer også kvaliteten - alt manuelt arbeid er full av feil. På den annen side er det prosjekter hvor det kun er én installasjon, men alt må fungere automatisk, konstant og uten feil – for eksempel de samme dokumentflytsystemene i store monolittiske organisasjoner. Ellers vil noen gjøre innstillingene manuelt, glemme distribusjonsinstruksjonene - og som et resultat, i produksjonen vil innstillingene gå tapt og alt vil kollapse.
Vanligvis samarbeider vi med kunden gjennom en kontrakt, og i dette tilfellet spriker interessene våre litt. Kunden ser på prosjektet strengt innenfor budsjett og tekniske spesifikasjoner. Det kan være vanskelig å forklare ham fordelene med ulike DevOps-praksiser som ikke er inkludert i de tekniske spesifikasjonene. Hva om han er interessert i hurtigutgivelser med økt forretningsverdi, eller i å bygge en automatiseringspipeline?
Dessverre, når du arbeider med en forhåndsgodkjent kostnad, er ikke alltid denne interessen funnet. I vår praksis var det et tilfelle da vi måtte ta opp utviklingen av en useriøs og uforsiktig entreprenør. Det var forferdelig: det var ingen oppdaterte kildekoder, kodebasen til det samme systemet var forskjellig på forskjellige installasjoner, dokumentasjonen var delvis fraværende, og delvis av forferdelig kvalitet. Kunden hadde selvfølgelig ikke kontroll over kildekoden, montering, utgivelser osv.
Så langt er det ikke alle som vet om DevOps, men så snart vi snakker om fordelene, om reelle ressursbesparelser, lyser øynene til alle kunder. Så antallet forespørsler som inkluderer DevOps øker over tid. Her, for å enkelt kunne snakke samme språk med kunder, må vi raskt koble sammen forretningsproblemer og DevOps-praksis som vil bidra til å bygge en passende utviklingspipeline.
Så vi har et sett med problemer på den ene siden, vi har DevOps kunnskap, praksis og verktøy på den andre. Hvorfor ikke dele opplevelsen med alle?
Opprette en DevOps-konstruktør
Agile har sitt eget manifest. ITIL har sin egen metodikk. DevOps er mindre heldig - den har ennå ikke anskaffet maler og standarder. Selv om bestemme modenhet av selskaper basert på en vurdering av deres utvikling og driftspraksis.
Heldigvis ble det kjente selskapet Gartner i 2014 og analyserte nøkkel DevOps-praksis og relasjonene mellom dem. Basert på dette ga jeg ut en infografikk:
Vi tok det som grunnlag for vår . Hvert av de fire områdene har et sett med verktøy - vi samlet dem inn i en database, identifiserte de mest populære, identifiserte integrasjonspunkter og passende optimaliseringsmekanismer. Totalt viste det seg 36 øvelser og 115 verktøy, hvorav en fjerdedel er åpen kildekode eller fri programvare. Deretter skal vi snakke om hva vi har fått til på hvert område og som eksempel om hvordan dette ble implementert i prosjektet for å lage teknisk dokumenthåndtering, som vi startet innlegget med.
prosesser
I det beryktede EDMS-prosjektet ble det tekniske dokumentasjonsstyringssystemet distribuert i henhold til samme ordning ved hvert av de 10 objektene. Installasjonen inkluderer 4 servere: databaseserver, applikasjonsserver, fulltekstindeksering og innholdsbehandling. I installasjonen opererer de innenfor en enkelt node og er plassert i datasenteret på anleggene. Alle objekter er litt forskjellige i infrastruktur, men dette forstyrrer ikke global interaksjon.
Først, i henhold til DevOps-praksis, automatiserte vi infrastrukturen lokalt, så brakte vi leveransen til testkretsen og deretter til kundens produkt. Hver prosess ble utarbeidet trinn for trinn. Miljøinnstillingene er fikset i kildekodesystemet, tar hensyn til hvilket distribusjonssett som er kompilert for automatisk oppdatering. Ved konfigurasjonsendringer trenger ingeniører ganske enkelt å gjøre de nødvendige endringene i versjonskontrollsystemet - og deretter vil den automatiske oppdateringen skje uten problemer.
Takket være denne tilnærmingen har testprosessen blitt betydelig forenklet. Tidligere hadde prosjektet testere som ikke gjorde annet enn å manuelt oppdatere stands. Nå kommer de bare, ser at alt fungerer og gjør mer nyttige ting. Hver oppdatering testes automatisk – fra overflatenivå til automatisering av forretningsscenarioer. Resultatene legges ut som egne rapporter i TestRail.
Культура
Kontinuerlig eksperimentering forklares best gjennom eksemplet med testdesign. Å teste et system som ikke eksisterer ennå er kreativt arbeid. Når du skriver en testplan, må du forstå hvordan du tester riktig og hvilke grener du skal følge. Og finn også en balanse mellom tid og budsjett for å bestemme det optimale antallet sjekker. Det er viktig å velge nøyaktig de nødvendige testene, tenke på hvordan brukeren vil samhandle med systemet, ta hensyn til miljøet og mulige eksterne faktorer. Det er umulig å gjøre uten kontinuerlig eksperimentering.
Nå om samhandlingskulturen. Tidligere var det to motsatte sider - ingeniører og utviklere. Utviklerne sa: "Vi bryr oss ikke om hvordan det vil bli lansert. Dere er ingeniører, dere er smarte, sørg for at den fungerer uten feil". Ingeniørene svarte: «Dere utviklere er for uforsiktige. La oss være mer forsiktige, så spiller vi utgivelsene dine sjeldnere. For hver gang du gir oss en lekk kode, er det ikke klart for oss hvordan vi skal samhandle.". Dette er en kulturell interaksjonssak som er strukturert annerledes fra et DevOps-perspektiv. Her er både ingeniører og utviklere en del av et enkelt team som er fokusert på stadig endring, men samtidig pålitelig programvare.
Innenfor samme team er spesialister fast bestemt på å hjelpe hverandre. Som det var før? For eksempel ble noen tykke distribusjonsinstruksjoner utarbeidet, omtrent 50 sider lange. Ingeniøren leste den, forsto ikke noe, bannet og ba utvikleren klokken tre om morgenen om å kommentere. Utvikleren kommenterte og bannet også - til slutt var det ingen som var fornøyd. I tillegg var det naturligvis noen feil, fordi du ikke kan huske alt i instruksjonene. Og nå skriver ingeniøren, sammen med utvikleren, et skript for automatisert distribusjon av applikasjonsprogramvareinfrastruktur. Og de snakker med hverandre praktisk talt på samme språk.
Folk
Størrelsen på teamet bestemmes av omfanget av oppdateringen. Teamet rekrutteres under dannelsen av leveransen; det inkluderer interesserte fra det generelle prosjektteamet. Deretter skrives det en oppdateringsplan med de ansvarlige for hvert trinn, og teamet rapporterer etter hvert som det skrider frem. Alle teammedlemmer er utskiftbare. Som en del av teamet har vi også en backuputvikler, men han trenger nesten aldri å koble seg på.
Teknologi
I teknologidiagrammet er noen få punkter fremhevet, men under dem er det en haug med teknologier - du kan publisere en hel bok med beskrivelsene deres. Så vi vil fremheve det mest interessante.
Infrastruktur som kode
Nå vil sannsynligvis ikke dette konseptet overraske noen, men tidligere har beskrivelsene av infrastrukturer mye å være ønsket. , testmiljøene var unike, de ble verdsatt og verdsatt, støvpartikler ble blåst av dem.
I dag er ingen redde for å eksperimentere. Det er grunnleggende bilder av virtuelle maskiner, det er ferdige scenarier for distribusjon av miljøer. Alle maler og skript lagres i et versjonskontrollsystem og oppdateres umiddelbart. Tidligere, når det var nødvendig å levere en pakke til et stativ, dukket det opp et konfigurasjonsgap. Nå trenger du bare å legge til en linje i kildekoden.
I tillegg til infrastrukturskript og pipelines, brukes Documentation as a Code-tilnærmingen også for dokumentasjon. Takket være dette er det enkelt å koble nye personer til prosjektet, introdusere dem til systemet basert på funksjonene beskrevet for eksempel i testplanen, og også gjenbruke testcases.
Kontinuerlig levering og overvåking
om DevOps snakket vi om hvordan vi valgte verktøy for å implementere kontinuerlig levering og overvåking. Ofte er det ikke nødvendig å omskrive noe - det er nok å bruke tidligere skrevne skript, bygge korrekt integrasjon mellom komponenter og lage en felles administrasjonskonsoll. Og alle prosesser kan startes med én knapp eller tidsplan.
På engelsk er det ulike konsepter, Continuous Delivery og Continuous Deployment. Begge kan oversettes som "kontinuerlig levering", men faktisk er det en liten forskjell mellom dem. I vårt prosjekt for den tekniske dokumentflyten til et distribuert energiselskap brukes heller Levering - når installasjon for produksjon skjer på kommando. I distribusjon skjer installasjonen automatisk. Kontinuerlig levering i dette prosjektet har generelt blitt sentral del av DevOps.
Generelt, ved å samle inn visse parametere, kan du tydelig forstå hvorfor DevOps-praksis er nyttig. Og formidle dette til ledelsen, som virkelig elsker tall. Det totale antallet lanseringer, utførelsestiden for skriptstadier, andelen vellykkede lanseringer - alt dette påvirker direkte alles favoritttidspunkt til markedet, det vil si tiden fra en forpliktelse til versjonskontrollsystemet til utgivelsen av en versjon på en produksjonsmiljø. Med implementeringen av de nødvendige verktøyene mottar ingeniører verdifulle indikatorer per post, og prosjektlederen ser dem på dashbordet. På denne måten kan du umiddelbart vurdere fordelene med nye verktøy. Og du kan prøve dem på infrastrukturen din ved å bruke DevOps-designeren.
Hvem vil trenge vår ?
La oss ikke late som: Til å begynne med ble han nyttig for oss. Som vi allerede har sagt, må du snakke samme språk med kunden, og ved hjelp av DevOps-designeren kan vi raskt skissere grunnlaget for en slik samtale. Bedriftsspesialister vil selv kunne vurdere hva de trenger og dermed utvikle seg raskere. Vi prøvde å gjøre designeren så detaljert som mulig, og la til en haug med beskrivelser slik at enhver bruker forstår hva han velger.
Designerens format lar deg ta hensyn til selskapets eksisterende utvikling innen byggeprosesser og automatisering. Det er ingen grunn til å rive alt ned og bygge det opp igjen hvis du bare kan velge løsninger som integreres godt med eksisterende prosesser og som rett og slett kan fylle hullene.
Kanskje utviklingen din allerede har flyttet til et høyere nivå, og verktøyet vårt vil virke for "kaptein". Men vi finner det nyttig for oss selv og håper at det vil være nyttig for noen av leserne. Vi minner deg på til designeren - hvis noe, mottar du diagrammet umiddelbart etter at du har lagt inn de første dataene. Vi vil være takknemlige for tilbakemeldinger og tillegg.
Kilde: www.habr.com