Bilde:
Hei alle sammen! Vi er automasjonsingeniører fra selskapet og vi gir støtte til utviklingen av selskapets produkter: vi støtter hele monteringspipelinen fra utviklernes utføring av en kodelinje til publisering av ferdige produkter og lisenser på oppdateringsservere. Uformelt kalles vi DevOps-ingeniører. I denne artikkelen ønsker vi å snakke om de teknologiske stadiene i programvareproduksjonsprosessen, hvordan vi ser dem og hvordan vi klassifiserer dem.
Fra materialet vil du lære om kompleksiteten ved å koordinere multiproduktutvikling, hva et teknologisk kart er og hvordan det hjelper å organisere og replikere løsninger, hvilke hovedstadier og trinn utviklingsprosessen består av, hvordan ansvarsområdene er avgrenset. mellom DevOps og team i selskapet vårt.
Om Chaos og DevOps
La oss kort merke oss at konseptet med DevOps inkluderer utviklingsverktøy og -tjenester, samt metoder og beste praksis for bruken av dem. La oss fremheve det globale mål fra implementeringen av DevOps-ideer i vårt selskap: dette er en konsekvent reduksjon i kostnadene for produksjon og vedlikehold av produkter i kvantitative termer (arbeidstimer eller maskintimer, CPU, RAM, disk etc.). Den enkleste og mest åpenbare måten å redusere de totale kostnadene ved utvikling på bedriftsnivå er å minimere kostnadene ved å utføre typiske serielle oppgaver på alle stadier av produksjonen. Men hva er disse stadiene, hvordan kan de skilles fra den generelle prosessen, hvilke steg består de av?
Når en bedrift utvikler ett produkt, er alt mer eller mindre klart: Det er vanligvis et generelt veikart og utviklingsopplegg. Men hva skal man gjøre når produktlinjen utvides og det er flere produkter? Ved første øyekast har de lignende prosesser og samlebånd, og spillet med "finn X-forskjeller" i logger og skript begynner. Hva om det allerede er 5+ prosjekter i aktiv utvikling og det kreves støtte for flere versjoner utviklet over flere år? Ønsker vi å gjenbruke så mange løsninger som mulig i produktpipelines eller er vi klare til å bruke penger på unik utvikling for hver?
Hvordan finne en balanse mellom unike og serielle løsninger?
Disse spørsmålene begynte å dukke opp for oss mer og oftere fra og med 2015. Antallet produkter vokste, og vi prøvde å utvide automatiseringsavdelingen vår (DevOps), som støttet samlebåndene til disse produktene, til et minimum. Samtidig ønsket jeg å replikere så mange løsninger som mulig mellom produktene. Tross alt, hvorfor gjøre det samme i ti produkter på forskjellige måter?
Utviklingsdirektør: "Gutter, kan vi på en eller annen måte evaluere hva DevOps gjør for produkter?"
Vi: "Vi vet ikke, vi har ikke stilt dette spørsmålet, men hvilke indikatorer bør beregnes?"
Utviklingsdirektør: "Hvem vet! Synes at..."
Som i den berømte filmen: "Jeg skal til hotellet!..." - "Øh... Kan du vise meg veien?" Etter å ha tenkt, kom vi til den konklusjonen at vi først må bestemme oss for produktenes endelige tilstand; dette ble vårt første mål.
Så hvordan kan du analysere et dusin produkter med ganske store team på 10 til 200 personer og bestemme målbare beregninger når du replikerer løsninger?
1:0 til fordel for Chaos, eller DevOps på bladene
Vi startet med å prøve å bruke IDEF0-diagrammer og ulike forretningsprosessdiagrammer fra BPwin-serien. Forvirringen begynte etter den femte ruten i neste fase av det neste prosjektet, og disse rutene for hvert prosjekt kan trekkes inn i halen av en lang pyton i 50+ trinn. Jeg følte meg trist og ville hyle mot månen - den passet ikke i det hele tatt.
Typiske produksjonsoppgaver
Å modellere produksjonsprosesser er et svært komplekst og møysommelig arbeid: du må samle inn, behandle og analysere mye data fra ulike avdelinger og produksjonskjeder. Du kan lese mer om dette i artikkelen "'.
Da vi begynte å modellere produksjonsprosessen vår, hadde vi et spesifikt mål - å formidle til alle ansatte som er involvert i utviklingen av selskapets produkter og til prosjektledere:
- hvordan produkter og deres komponenter, med utgangspunkt i en kodelinje, når kunden i form av installatører og oppdateringer,
- hvilke ressurser som tilbys i hvert trinn av produktproduksjonen,
- hvilke tjenester som er involvert i hvert trinn,
- hvordan ansvarsområder er avgrenset for hvert trinn,
- hvilke kontrakter som eksisterer ved inngangen og utgangen av hvert trinn.
Klikk på bildet for å åpne i full størrelse
Vårt arbeid i selskapet er delt inn i flere funksjonsområder. Infrastrukturavdelingen er engasjert i å optimalisere driften av alle avdelingens maskinvareressurser, samt automatisere utplasseringen av virtuelle maskiner og miljøet på disse. Overvåkingsretningen gir kontroll over ytelsen til tjenester 24/7; Vi tilbyr også overvåking som en tjeneste for utviklere. Arbeidsflytretningen gir team verktøy for å administrere utviklings- og testprosesser, analysere kodestatus og innhente analyser på prosjekter. Og til slutt sikrer webdev-retningen publisering av utgivelser på GUS- og FLUS-oppdateringsserverne, samt lisensiering av produkter som bruker LicenseLab-tjenesten. For å støtte produksjonspipelinen setter vi opp og vedlikeholder mange forskjellige støttetjenester for utviklere (du kan lytte til historier om noen av dem på gamle møter: и). Vi utvikler også interne automasjonsverktøy, bl.a .
I løpet av de siste fem årene har vårt arbeid akkumulert mye lignende og rutinemessige operasjoner, og den såkalte typiske oppgaver, hvis løsning er helt eller delvis automatisert, forårsaker ikke vanskeligheter for utøvere og krever ikke betydelige mengder arbeid. Sammen med de ledende områdene analyserte vi slike oppgaver og var i stand til å identifisere individuelle arbeidskategorier, eller produksjonsstadier, trinnene er delt inn i udelelige trinn, og flere trinn legger sammen produksjonsprosesskjeden.
Det enkleste eksemplet på en teknologisk kjede er stadiene med montering, distribusjon og testing av hvert av produktene våre i selskapet. I sin tur består for eksempel byggestadiet av mange separate standardtrinn: nedlasting av kilder fra GitLab, klargjøring av avhengigheter og tredjepartsbiblioteker, enhetstesting og statisk kodeanalyse, kjøring av et byggeskript på GitLab CI, publisering av artefakter til et depot på Artifactory og generere utgivelsesnotater gjennom vårt interne ChangelogBuilder-verktøy.
Du kan lese om typiske DevOps-oppgaver i våre andre artikler om Habré: ""Og"'.
Mange typiske produksjonskjeder dannes produksjonsprosess. Standardtilnærmingen for å beskrive prosesser er å bruke funksjonelle IDEF0-modeller.
Et eksempel på modellering av en produksjons-CI-prosess
Vi la spesielt vekt på utvikling av standardprosjekter for et kontinuerlig integreringssystem. Dette gjorde det mulig å oppnå forening av prosjekter, fremheve den såkalte utgivelsesdiagram over bygg med kampanjer.
Slik fungerer det. Alle prosjekter ser typiske ut: de inkluderer konfigurasjonen av sammenstillinger som går til øyeblikksbildelageret på Artifactory, hvoretter de distribueres og testes på testbenker, og deretter forfremmes til utgivelsesdepotet. Artifactory-tjenesten er et enkelt punkt for å distribuere alle byggeartefakter mellom team og andre tjenester.
Hvis vi i stor grad forenkler og generaliserer utgivelsesskjemaet vårt, inkluderer det følgende stadier:
- produktbygging på tvers av plattformer,
- utplassering til testbenker,
- lansering av funksjonelle og andre tester,
- promotering av testede sammenstillinger for å frigi depoter på Artifactory,
- publisere utgivelsesbygg for å oppdatere servere,
- levering av bygg og oppdateringer til produksjon,
- lansering av installasjon og produktoppdateringer.
La oss vurdere, som et eksempel, den teknologiske modellen til denne typiske utgivelsesordningen (heretter bare referert til som modellen) i form av en funksjonell IDEF0-modell. Det gjenspeiler hovedstadiene i CI-prosessen vår. IDEF0-modeller bruker den såkalte ICOM-notasjon (Input-Control-Output-Mechanism) for å beskrive hvilke ressurser som brukes på hvert trinn, basert på hvilke regler og krav arbeidet utføres, hva som er output og hvilke mekanismer, tjenester eller personer som implementerer et bestemt trinn.
Klikk på bildet for å åpne i full størrelse
Som regel er det i funksjonelle modeller lettere å dekomponere og detaljere beskrivelsen av prosesser. Men etter hvert som antallet elementer vokser, blir det vanskeligere og vanskeligere å forstå noe om dem. Men i reell utvikling er det også hjelpestadier: overvåking, produktsertifisering, automatisering av arbeidsprosesser og andre. Det er nettopp på grunn av skaleringsproblemet at vi forlot denne beskrivelsen.
Håpets fødsel
I en bok kom vi over gamle sovjetiske kart som beskriver teknologiske prosesser (som forresten fortsatt brukes i dag i mange statseide virksomheter og universiteter). Vent, vent, vi har også en teknologisk prosess!.. Det er stadier, resultater, beregninger, krav, indikatorer, etc., etc... Hvorfor ikke prøve å bruke teknologiske kart til våre produkttransportører? Det var en følelse: «Dette er det! Vi har funnet den rette tråden, det er på tide å gi den et godt rykk!"
I en enkel tabell bestemte vi oss for å registrere produkter etter kolonner, og teknologiske stadier og trinn på produkttransportøren etter rader. Stadier er noe stort, for eksempel monteringsfasen av et produkt. Og trinn er noe mindre og mer detaljert, for eksempel trinnet med å laste ned kildekoden til byggeserveren eller trinnet med å kompilere koden.
I skjæringspunktene mellom rader og kolonner på kartet setter vi statuser for et bestemt stadium og produkt. Mange stater er definert for statuser:
- Ingen informasjon - eller upraktisk. Det er nødvendig å analysere etterspørselen etter et stadium i produktet. Enten er analysen allerede utført, men stadiet er foreløpig ikke nødvendig eller er ikke økonomisk begrunnet.
- Utsatt - eller ikke relevant for øyeblikket. Dette stadiet i rørledningen er nødvendig, men det er ikke energi til å gjennomføre det i år.
- Planlagt. Etappen er planlagt gjennomført i år.
- Implementert. Stadiet i rørledningen gjennomføres i nødvendig omfang.
Utfylling av tabellen startet prosjekt for prosjekt. Først klassifiserte vi stadiene og trinnene i ett prosjekt og registrerte statusene deres. Så tok de neste prosjekt, registrerte statusene i det og la til stadier og steg som manglet i tidligere prosjekter. Som et resultat mottok vi stadiene og trinnene i hele produksjonspipelinen vår og statusene deres i et spesifikt prosjekt. Resultatet er noe som ligner på en kompetansematrise for en mattransportør. Vi kalte en slik matrise et teknologisk kart.
Ved hjelp av det teknologiske kartet er vi metrologisk enig med teamene om arbeidsplanene for året og målene vi ønsker å nå sammen: hvilke stadier vi legger til prosjektet i år, og hvilke vi legger til senere. Mens vi jobber, kan vi også se forbedringer i trinn som vi har fullført for bare ett produkt. Deretter utvider vi kartet vårt og introduserer denne forbedringen som et stadium eller et nytt trinn, deretter gjennomfører vi en analyse for hvert produkt og finner ut muligheten for å replikere forbedringen.
De kan protestere mot oss: «Dette er selvfølgelig bra, men over tid vil antallet trinn og etapper bli uoverkommelig stort. Hva burde jeg gjøre?
Vi introduserte standard og ganske komplette beskrivelser av krav for hvert trinn og trinn slik at de i bedriften ble forstått av alle på samme måte. Over tid, ettersom forbedringer implementeres, kan et trinn bli absorbert i et annet trinn eller et annet trinn - da vil de kollapse. Samtidig passer alle krav og teknologiske nyanser inn i kravene til generaliseringsstadiet eller trinnet.
Hvordan evaluere effekten av replikerende løsninger? Vi bruker en ekstremt enkel tilnærming: vi tilskriver startkapitalkostnadene for implementering av en ny fase til årlige generelle produktkostnader, og deler dem deretter mellom alle under replikering.
Deler av utviklingen gjenspeiles allerede som etapper og trinn på kartet. Vi kan påvirke reduksjonen av produktkostnadene gjennom innføring av automatisering for typiske stadier. Etter dette beregner vi endringer i kvalitative egenskaper, kvantitative beregninger og overskuddet mottatt av teamene (i arbeidstimer eller sparte maskintimer).
Teknologisk kart over produksjonsprosessen
Hvis vi tar alle stadiene og trinnene våre, koder dem med tagger og utvider dem til en kjede, vil det vise seg å være veldig langt og uforståelig (nøyaktig den samme "pytonhalen" som vi snakket om i begynnelsen av artikkelen) :
[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]Dette er stadiene for å sette sammen produkter [Build], distribuere dem til å teste servere [Deploy], teste [Test], promotere sammenstillinger for å frigi repositories basert på testresultater [Promote], generere og publisere lisenser [License], publisering [Publish] på GUS oppdateringsserver og levering av FLUS oppdateringer til servere, installasjon og oppdatering av produktkomponenter på kundens infrastruktur ved bruk av Product Configuration Management [Install], samt innsamling av telemetri [Telemetri] fra installerte produkter.
I tillegg til dem kan vi skille mellom separate stadier: overvåke tilstanden til infrastrukturen [InfMonitoring], administrere versjoner av kildekoden [SourceCodeControl], forberede monteringsmiljøet [Prepare], prosjektledelse [Workflow], gi teamene kommunikasjonsverktøy [ Kommunikasjon], produktsertifisering [Sertifisering] og sikring av selvforsyning av CI-prosesser [CISelfSufficiency] (for eksempel uavhengighet av sammenstillinger fra Internett). Vi vil ikke engang vurdere dusinvis av trinn i prosessene våre, fordi de er veldig spesifikke.
Det vil være mye lettere å forstå og se på hele produksjonsprosessen hvis du forestiller deg det i skjemaet teknologisk kart; Dette er en tabell der de enkelte produksjonsstadiene og dekomponerte trinnene i modellen er registrert i rader, og i kolonner en beskrivelse av hva som gjøres på hvert trinn eller trinn. Hovedvekten er lagt på ressursene som gir hvert trinn og avgrensning av ansvarsområder.
For oss er et kart en slags klassifiserer. Det gjenspeiler store teknologiske deler av produktproduksjonen. Takket være det har det blitt enklere for automatiseringsteamet vårt å samhandle med utviklere og i fellesskap planlegge implementeringen av automatiseringstrinn, samt forstå hvilke arbeidskostnader og ressurser (menneske og maskinvare) som vil kreves for dette.
Inne i selskapet vårt blir kartet automatisk generert fra en jinja-mal som en vanlig HTML-fil, og deretter lastet opp til GitLab Pages-serveren. Et skjermbilde med et eksempel på et fullt generert kart kan vises .
Klikk på bildet for å åpne i full størrelse
Kort fortalt er et teknologisk kart et generalisert bilde av produksjonsprosessen, som gjenspeiler tydelig klassifiserte blokker med standard funksjonalitet.
Strukturen til vårt teknologiske kart
Kartet består av flere deler:
- Overskriftsområde - her er en generell beskrivelse av kartet, grunnleggende konsepter introduseres, og hovedressursene og resultatene av produksjonsprosessen er definert.
- Informasjonspanel - her kan du kontrollere visningen av data for individuelle produkter; et sammendrag av de implementerte stadiene og trinnene generelt for alle produkter er gitt.
- Teknologisk kart - en tabellbeskrivelse av den teknologiske prosessen. På kartet:
- alle stadier, trinn og deres koder er gitt;
- korte og fullstendige beskrivelser av stadiene er gitt;
- inputressursene og tjenestene som brukes på hvert trinn er angitt;
- resultatene av hvert trinn og individuelle trinn er indikert;
- ansvarsområdet for hvert trinn og trinn er angitt;
- tekniske ressurser har blitt bestemt, for eksempel HDD (SSD), RAM, vCPU og arbeidstimer som er nødvendige for å støtte arbeidet på dette stadiet, både for øyeblikket - faktisk og i fremtiden - plan;
- for hvert produkt er det angitt hvilke teknologiske stadier eller trinn for det som er implementert, er planlagt for implementering, er irrelevant eller ikke er implementert.
Ta beslutninger basert på det teknologiske kartet
Etter å ha studert kartet, kan du ta noen handlinger, avhengig av den ansattes rolle i selskapet (utviklingssjef, produktsjef, utvikler eller tester):
- forstå hvilke stadier som mangler i et reelt produkt eller prosjekt og vurdere behovet for implementering av dem;
- avgrense ansvarsområder mellom flere avdelinger dersom de jobber på ulike stadier;
- forhandle kontrakter for innganger og utganger av trinn;
- integrere arbeidsstadiet ditt i den generelle utviklingsprosessen;
- mer nøyaktig vurdere behovet for ressurser for å støtte hvert trinn.
Oppsummerer alt ovenfor
Teknologikartet er allsidig, utvidbart og enkelt å vedlikeholde. Det er mye lettere å utvikle og vedlikeholde prosessbeskrivelser i denne formen enn i den strenge akademiske IDEF0-modellen. I tillegg er en tabellbeskrivelse enklere, mer kjent og bedre strukturert enn en funksjonell modell.
Et spesielt internt verktøy, CrossBuilder, er ansvarlig for den tekniske implementeringen av trinnene – et lagdelingsverktøy mellom CI-systemer, tjenester og infrastruktur. Utvikleren trenger ikke å kutte sykkelen sin: i vårt CI-system er det nok å kjøre et av skriptene (den såkalte oppgaven) til CrossBuilder-verktøyet, som vil utføre det riktig, med tanke på funksjonene til infrastrukturen vår.
Resultater av
Artikkelen viste seg å være ganske lang, men dette er uunngåelig når man skal beskrive modelleringen av komplekse prosesser. Til slutt vil jeg kort oppgi hovedideene våre:
- Målet med å introdusere DevOps-ideer i selskapet vårt er å konsekvent redusere kostnadene ved produksjon og vedlikehold av selskapets produkter i kvantitative termer (arbeidstimer eller maskintimer, vCPU, RAM, disk).
- En måte å redusere de totale kostnadene ved utvikling er å minimere kostnadene ved å utføre standard serielle oppgaver: stadier og trinn i den teknologiske prosessen.
- En typisk oppgave er en oppgave hvis løsning er helt eller delvis automatisert, ikke forårsaker vanskeligheter for utøvere og ikke krever betydelige arbeidskostnader.
- Produksjonsprosessen består av stadier, stadiene er delt inn i udelelige trinn, som representerer typiske oppgaver i ulik skala og volum.
- Fra isolerte standardoppgaver har vi kommet til komplekse teknologiske kjeder og flernivåmodeller av produksjonsprosessen, som kan beskrives med en funksjonell IDEF0-modell eller et enklere teknologisk kart.
- Et flytskjema er en tabellrepresentasjon av stadiene og trinnene i en produksjonsprosess. Det viktigste: kartet lar deg se hele prosessen som en helhet, i store biter med mulighet for detaljering.
- Basert på det teknologiske kartet kan du vurdere behovet for å implementere stadier i et bestemt produkt, avgrense ansvarsområder, avtale kontrakter for inn- og utganger av etapper, og mer nøyaktig vurdere behovet for ressurser.
I de følgende artiklene vil vi snakke mer detaljert om hvilke tekniske verktøy som brukes til å implementere visse teknologiske stadier på kartet vårt.
Forfattere av artikkelen:
- — Leder for automatiseringsavdelingen (DevOps) hos Positive Technologies
- - stedfortreder Leder for automatiseringsavdelingen (DevOps) i Positive Technologies
Kilde: www.habr.com