Billede:
Hej alle! Vi er automationsingeniører fra virksomheden og vi støtter udviklingen af virksomhedens produkter: vi understøtter hele montagepipelinen fra udviklernes begåelse af en kodelinje til udgivelsen af færdige produkter og licenser på opdateringsservere. Uformelt kaldes vi DevOps-ingeniører. I denne artikel vil vi tale om de teknologiske stadier af softwareproduktionsprocessen, hvordan vi ser dem, og hvordan vi klassificerer dem.
Ud fra materialet lærer du om kompleksiteten i at koordinere multi-produktudvikling, om hvad et teknologisk kort er, og hvordan det hjælper med at strømline og replikere løsninger, hvad er de vigtigste stadier og trin i udviklingsprocessen, hvordan er ansvarsområderne. mellem DevOps og teams i vores virksomhed.
Om Chaos og DevOps
Kort fortalt inkluderer konceptet DevOps udviklingsværktøjer og -tjenester samt metoder og bedste praksis for deres brug. Lad os fremhæve det globale mål fra implementeringen af DevOps-ideer i vores virksomhed: dette er en konsekvent reduktion i omkostningerne til produktion og vedligeholdelse af produkter i kvantitative termer (mandtimer eller maskintimer, CPU, RAM, disk osv.). Den nemmeste og mest oplagte måde at reducere de samlede omkostninger ved udvikling på hele virksomhedens niveau er minimere omkostningerne ved at udføre typiske serielle opgaver på alle stadier af produktionen. Men hvad er disse stadier, hvordan adskiller man dem fra den generelle proces, hvilke trin består de af?
Når en virksomhed udvikler ét produkt, er alt mere eller mindre klart: Der er normalt en fælles køreplan og udviklingsplan. Men hvad skal man gøre, når produktlinjen udvides, og der er flere produkter? Ved første øjekast har de lignende processer og samlebånd, og "find X forskelle"-spillet i logfiler og scripts begynder. Men hvad nu hvis der allerede er 5+ projekter i aktiv udvikling, og der er behov for support til flere versioner udviklet over flere år? Ønsker vi at genbruge det størst mulige antal løsninger i produktpipelines, eller er vi klar til at bruge penge på en unik udvikling for hver?
Hvordan finder man en balance mellem unikhed og serielle løsninger?
Disse spørgsmål begyndte at dukke op for os mere og oftere siden 2015. Antallet af produkter voksede, og vi forsøgte at udvide vores automationsafdeling (DevOps), som understøttede samlebåndene for disse produkter, til et minimum. Samtidig ønskede vi at kopiere så mange løsninger som muligt mellem produkterne. Når alt kommer til alt, hvorfor gøre det samme i ti produkter på forskellige måder?
Udviklingsdirektør: "Drenge, kan vi på en eller anden måde evaluere, hvad DevOps gør for produkter?"
Vi: "Vi ved det ikke, vi stillede ikke sådan et spørgsmål, men hvilke indikatorer skal overvejes?"
Udviklingsdirektør: "Hvem ved! Tænke…"
Som i den berømte film: "Jeg er på et hotel! .." - "Øh ... Kan du vise mig vejen?" Ved nærmere eftertanke kom vi til den konklusion, at vi først skal tage stilling til produkternes endelige tilstand; dette blev vores første mål.
Så hvordan analyserer du et dusin produkter med ret store teams fra 10 til 200 personer og bestemmer målbare målinger, når du kopierer løsninger?
1:0 til fordel for Chaos, eller DevOps på skulderbladene
Vi startede med et forsøg på at anvende IDEF0-diagrammer og forskellige forretningsprocesdiagrammer fra BPwin-serien. Forvirringen begyndte efter det femte felt i næste fase af det næste projekt, og disse firkanter for hvert projekt kan tegnes i halen af en lang python under 50+ trin. Jeg var ked af det og ville hyle mod månen - det passede generelt ikke.
Typiske produktionsopgaver
Modellering af produktionsprocesser er et meget komplekst og omhyggeligt arbejde: Du skal indsamle, bearbejde og analysere en masse data fra forskellige afdelinger og produktionskæder. Det kan du læse mere om i artiklen "'.
Da vi begyndte at modellere vores produktionsproces, havde vi et specifikt mål - at formidle til hver medarbejder, der er involveret i udviklingen af vores virksomheds produkter, og til projektledere:
- hvordan produkter og deres komponenter, startende fra commit af en linje kode, når kunden i form af installatører og opdateringer,
- hvilke ressourcer der stilles til rådighed for hvert trin i produktionen af produkter,
- hvilke tjenester der er involveret på hvert trin,
- hvordan ansvarsområderne for hvert trin er afgrænset,
- hvilke kontrakter der findes ved indgangen og udgangen af hver etape.
Ved at klikke på billedet åbnes det i fuld størrelse
Vores arbejde i virksomheden er opdelt i flere funktionsområder. Infrastrukturens retning er engageret i optimering af driften af alle afdelingens "jern"-ressourcer samt automatisering af udrulningen af virtuelle maskiner og miljøet på dem. Overvågningsretningen giver 24/7 serviceydelseskontrol; vi leverer også overvågning som en service til udviklere. Workflow-retningen giver teams værktøjer til at styre udviklings- og testprocesser, analysere kodens tilstand og få analyser på projekter. Og endelig sørger webdev-retningen for offentliggørelse af udgivelser på GUS- og FLUS-opdateringsserverne samt licensering af produkter ved hjælp af LicenseLab-tjenesten. For at understøtte produktionspipelinen opsætter og vedligeholder vi mange forskellige supporttjenester til udviklere (du kan lytte til historier om nogle af dem på gamle møder: и). Vi udvikler også interne automatiseringsværktøjer, bl.a .
I løbet af de seneste fem år har vores arbejde akkumuleret en del af samme type og rutinemæssige operationer, og vores udviklere fra andre afdelinger kommer hovedsageligt fra de såkaldte typiske opgaver, hvis løsning er helt eller delvist automatiseret, forårsager ikke vanskeligheder for kunstnere og kræver ikke betydelige mængder arbejde. Sammen med de førende områder analyserede vi sådanne opgaver og var i stand til at identificere individuelle kategorier af arbejde, eller produktionstrin, etaperne blev opdelt i udelelige trin, og flere trin lægger op produktionsproceskæde.
Det enkleste eksempel på en teknologisk kæde er stadierne af montering, implementering og test af hvert af vores produkter i virksomheden. Til gengæld består byggestadiet for eksempel af mange separate typiske trin: download af kilder fra GitLab, forberedelse af afhængigheder og 3. parts biblioteker, enhedstest og statisk kodeanalyse, eksekvering af et build-script på GitLab CI, udgivelse af artefakter i repository Artifactory og generering af release notes gennem vores interne ChangelogBuilder værktøj.
Du kan læse om typiske DevOps-opgaver i vores andre artikler om Habré: ""Og"'.
Mange typiske produktionskæder dannes fremstillingsproces. Standardtilgangen til at beskrive processer er at bruge funktionelle IDEF0-modeller.
Et eksempel på modellering af en fremstillings-CI-proces
Vi lagde særlig vægt på udviklingen af standardprojekter til et kontinuerligt integrationssystem. Dette gjorde det muligt at opnå ensretning af projekter, hvilket fremhævede de såkaldte release build-ordning med kampagner.
Sådan fungerer det. Alle projekter ser typiske ud: De inkluderer konfigurationen af samlinger, der falder ind i snapshot-depotet hos Artifactory, hvorefter de implementeres og testes på testbænke og derefter forfremmet til release-depotet. Artifactory-tjenesten er et enkelt distributionspunkt for alle byggeartefakter mellem teams og andre tjenester.
Hvis vi i høj grad forenkler og generaliserer vores udgivelsesskema, så inkluderer det følgende trin:
- produktsamling på tværs af platforme,
- indsættelse til testbænke,
- køre funktionelle og andre tests,
- promovering af testede builds til frigivelse af repositories på Artifactory,
- offentliggørelse af release builds på opdateringsservere,
- levering af samlinger og opdateringer til produktion,
- lancering af installation og opdatering af produktet.
Overvej f.eks. den teknologiske model for dette typiske udgivelsesskema (i det følgende blot Model) i form af en funktionel IDEF0-model. Det afspejler hovedstadierne i vores CI-proces. IDEF0 modeller bruger den såkaldte ICOM notation (Input-Control-Output-Mechanism) til at beskrive, hvilke ressourcer der bruges på hvert trin, baseret på hvilke regler og krav der udføres, hvad der er output, og hvilke mekanismer, tjenester eller personer, der implementerer et bestemt trin.
Ved at klikke på billedet åbnes det i fuld størrelse
Som regel er det lettere at nedbryde og detaljere beskrivelsen af processer i funktionelle modeller. Men efterhånden som antallet af elementer vokser, bliver det sværere og sværere at forstå noget i dem. Men i reel udvikling er der også hjælpefaser: overvågning, certificering af produkter, automatisering af arbejdsprocesser og andre. Det er på grund af skaleringsproblemet, at vi har opgivet denne beskrivelse.
Fødsel af håb
I en bog stødte vi på gamle sovjetiske kort, der beskriver teknologiske processer (som i øvrigt stadig bruges i dag på mange statsejede virksomheder og universiteter). Vent, vent, for vi har også en arbejdsgang!.. Der er stadier, resultater, målinger, krav, indikatorer og så videre og så videre... Hvorfor ikke prøve at anvende flowsheets til vores produktpipelines også? Der var en følelse: "Det er det! Vi har fundet den rigtige tråd, det er på tide at trække det godt!
I en simpel tabel besluttede vi at registrere produkter efter kolonner og teknologiske stadier og produktpipeline trin for rækker. Milepæle er noget stort, såsom et produktopbygningstrin. Og trin er noget mindre og mere detaljeret, såsom trinnet med at downloade kildekoden til build-serveren eller trinnet med at kompilere koden.
I skæringspunkterne mellem rækkerne og kolonnerne på kortet nedsætter vi status for en bestemt fase og produkt. For statusser blev et sæt tilstande defineret:
- Ingen oplysninger - eller upassende. Det er nødvendigt at analysere efterspørgslen efter en fase i produktet. Enten er analysen allerede gennemført, men stadiet er i øjeblikket ikke nødvendigt eller er ikke økonomisk begrundet.
- Udsat - eller ikke relevant i øjeblikket. Der er brug for en fase i pipelinen, men der er ingen kræfter til implementering i år.
- Planlagt. Etapen er planlagt til implementering i år.
- Implementeret. Stadiet i rørledningen implementeres i det nødvendige volumen.
Udfyldning af tabellen begyndte projekt for projekt. Først blev faserne og trinene i et projekt klassificeret, og deres status blev registreret. Så tog de det næste projekt, fiksede statusserne i det og tilføjede de stadier og trin, der manglede i tidligere projekter. Som et resultat fik vi stadierne og trinene i hele vores produktionspipeline og deres status i et specifikt projekt. Det viste sig noget, der ligner produktpipeline-kompetencematricen. Vi kaldte sådan en matrix et teknologisk kort.
Ved hjælp af det teknologiske kort koordinerer vi måleteknisk rimeligt med teamene de arbejdsplaner for året og de mål, som vi sammen ønsker at nå: hvilke faser vi tilføjer til projektet i år, og hvilke vi forlader til senere. I løbet af arbejdet kan vi også have forbedringer i de stadier, som vi kun har gennemført for ét produkt. Derefter udvider vi vores kort og introducerer denne forbedring som et trin eller et nyt trin, derefter analyserer vi for hvert produkt og finder ud af muligheden for at kopiere forbedringen.
De kan gøre indsigelse mod os: "Det hele er selvfølgelig godt, kun med tiden vil antallet af trin og trin blive uoverkommeligt stort. Hvordan skal man være?
Vi har indført standard og nogenlunde fuldstændige beskrivelser af kravene til hvert trin og trin, så de bliver forstået af alle i virksomheden på samme måde. Over tid, efterhånden som der indføres forbedringer, kan et trin blive absorberet i et andet trin eller trin, og så vil de "kollapse". Samtidig passer alle krav og teknologiske nuancer ind i kravene til generaliseringsstadiet eller -trinnet.
Hvordan evaluerer man effekten af replikerende løsninger? Vi bruger en ekstremt simpel tilgang: Vi tilskriver startkapitalomkostningerne for implementeringen af en ny fase til de årlige generelle produktomkostninger og dividerer derefter med alle, når vi replikerer.
Dele af udviklingen er allerede vist som milepæle og trin på kortet. Vi kan påvirke reduktionen af omkostningerne ved produktet gennem indførelse af automatisering for typiske faser. Derefter overvejer vi ændringerne i kvalitative egenskaber, kvantitative målinger og overskuddet modtaget af holdene (i mandetimer eller maskintimer med besparelser).
Teknologisk kort over produktionsprocessen
Hvis vi tager alle vores stadier og trin, koder dem med tags og udvider dem til en kæde, så vil det vise sig at være meget langt og uforståeligt (bare den samme "pythonhale", som vi talte om i begyndelsen af artiklen) :
[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 stadierne i at bygge produkter [Build], implementere dem til at teste servere [Deploy], test [Test], promovering af builds til frigivelse af repositories baseret på resultaterne af test [Promote], generering og udgivelse af licenser [Licens], publicering [ Publicer] på GUS opdateringsserveren og levering til FLUS opdateringsservere, installation og opdatering af produktkomponenter på kundens infrastruktur vha. Product Configuration Management [Install], samt indsamling af telemetri [Telemetri] fra installerede produkter.
Ud over dem kan der skelnes mellem separate faser: overvågning af infrastrukturtilstand [InfMonitoring], kildekodeversionering [SourceCodeControl], forberedelse af byggemiljøet [Forbered], projektledelse [Workflow], forsyne teams med kommunikationsværktøjer [Kommunikation], produktcertificering [ Certificering] og sikring af selvforsyning af CI-processer [CISelfSufficiency] (f.eks. uafhængighed af forsamlinger fra internettet). Dusinvis af trin i vores processer vil ikke engang blive overvejet, fordi de er meget specifikke.
Det vil være meget lettere at forstå og se på hele produktionsprocessen, hvis den præsenteres i skemaet teknologisk kort; dette er en tabel, hvor de enkelte produktionstrin og dekomponerede trin i modellen er skrevet i rækker, og i kolonner en beskrivelse af, hvad der gøres på hvert trin eller trin. Hovedvægten lægges på de ressourcer, der giver hver etape, og afgrænsningen af ansvarsområder.
Kortet for os er en slags klassificering. Det afspejler de store teknologiske dele af produktionen af produkter. Takket være det blev det nemmere for vores automatiseringsteam at interagere med udviklere og i fællesskab planlægge implementeringen af automatiseringsstadier samt forstå, hvilke arbejdsomkostninger og ressourcer (menneskelige og hardware) der kræves til dette.
Inde i vores virksomhed genereres kortet automatisk fra jinja-skabelonen som en almindelig HTML-fil og uploades derefter til GitLab Pages-serveren. Et skærmbillede med et eksempel på et fuldt genereret kort kan ses .
Ved at klikke på billedet åbnes det i fuld størrelse
Kort sagt er det teknologiske kort et generaliseret billede af produktionsprocessen, som afspejler klart klassificerede blokke med typisk funktionalitet.
Strukturen af vores køreplan
Kortet består af flere dele:
- Titelområde - her er en generel beskrivelse af kortet, grundlæggende begreber introduceres, de vigtigste ressourcer og resultater af produktionsprocessen er defineret.
- Dashboard - her kan du styre visningen af data for individuelle produkter, en oversigt over de implementerede stadier og trin generelt for alle produkter er givet.
- Teknologisk kort - en tabelbeskrivelse af den teknologiske proces. På kortet:
- alle stadier, trin og deres koder er givet;
- korte og fuldstændige beskrivelser af stadierne gives;
- de inputressourcer og -tjenester, der anvendes på hvert trin, er angivet;
- resultaterne af hvert trin og et separat trin er angivet;
- ansvarsområdet for hvert trin og trin er angivet;
- de tekniske ressourcer, såsom HDD (SSD), RAM, vCPU, og de mandetimer, der er nødvendige for at understøtte arbejdet på dette stadie, både på nuværende tidspunkt - en kendsgerning og i fremtiden - en plan, er blevet fastlagt;
- for hvert produkt er det angivet, hvilke teknologiske stadier eller trin for det, der er implementeret, planlagt til implementering, irrelevante eller ikke implementeret.
Beslutningstagning baseret på det teknologiske kort
Efter at have undersøgt kortet, er det muligt at foretage nogle handlinger - afhængigt af medarbejderens rolle i virksomheden (udviklingschef, produktchef, udvikler eller tester):
- forstå, hvilke stadier der mangler i et rigtigt produkt eller projekt, og vurdere behovet for deres implementering;
- afgrænse ansvarsområderne mellem flere afdelinger, hvis de arbejder på forskellige etaper;
- aftale kontrakter ved ind- og udgange af scenerne;
- integrere dit arbejdstrin i den overordnede udviklingsproces;
- mere præcist vurdere behovet for ressourcer, der giver hver af faserne.
Opsummerer alt ovenstående
Ruten er alsidig, udvidelsesbar og nem at vedligeholde. Det er meget lettere at udvikle og vedligeholde en beskrivelse af processer i denne form end i en stram akademisk IDEF0-model. Derudover er en tabelbeskrivelse enklere, mere velkendt og bedre struktureret end en funktionel model.
Til den tekniske implementering af trinene har vi et særligt internt værktøj CrossBuilder - et lagværktøj mellem CI-systemer, tjenester og infrastruktur. Udvikleren behøver ikke at klippe sin cykel: i vores CI-system er det nok at køre et af scripts (den såkaldte opgave) i CrossBuilder-værktøjet, som vil udføre det korrekt under hensyntagen til funktionerne i vores infrastruktur .
Resultaterne af
Artiklen viste sig at være ret lang, men dette er uundgåeligt, når man skal beskrive modelleringen af komplekse processer. Til sidst vil jeg gerne kort fikse vores hovedideer:
- Målet med at implementere DevOps-ideer i vores virksomhed er konsekvent at reducere omkostningerne ved produktion og vedligeholdelse af virksomhedens produkter i kvantitative termer (mandtimer eller maskintimer, vCPU, RAM, Disk).
- Måden at reducere de samlede omkostninger ved udvikling er at minimere omkostningerne ved at udføre typiske serielle opgaver: stadier og trin i den teknologiske proces.
- En typisk opgave er en opgave, hvis løsning er helt eller delvist automatiseret, ikke volder vanskeligheder for udførende og ikke kræver væsentlige arbejdsomkostninger.
- Produktionsprocessen består af trin, trinene er opdelt i udelelige trin, som er typiske opgaver af forskellig skala og omfang.
- Fra forskellige typiske opgaver er vi kommet til komplekse teknologiske kæder og multi-level modeller af produktionsprocessen, som kan beskrives ved en funktionel IDEF0 model eller et enklere teknologisk kort.
- Det teknologiske kort er en tabelrepræsentation af stadierne og trinene i produktionsprocessen. Det vigtigste: kortet giver dig mulighed for at se hele processen i sin helhed, i store stykker med mulighed for at detaljere dem.
- Ud fra det teknologiske kort er det muligt at vurdere behovet for at indføre stadier i et bestemt produkt, afgrænse ansvarsområder, aftale kontrakter ved input og output af faser og mere præcist vurdere behovet for ressourcer.
I de følgende artikler vil vi beskrive mere detaljeret, hvilke tekniske værktøjer der bruges til at implementere visse teknologiske stadier på vores kort.
Artiklens forfattere:
- — Head of Automation (DevOps) hos Positive Technologies
- - Stedfortræder Leder af Automationsafdelingen (DevOps) hos Positive Technologies
Kilde: www.habr.com