Bild:
Hej alla! Vi är automationsingenjörer från företaget och vi stödjer utvecklingen av företagets produkter: vi stödjer hela monteringspipelinen från att utvecklare utför en kodrad till publicering av färdiga produkter och licenser på uppdateringsservrar. Informellt kallas vi DevOps-ingenjörer. I den här artikeln vill vi prata om de tekniska stadierna i mjukvaruproduktionsprocessen, hur vi ser dem och hur vi klassificerar dem.
Från materialet kommer du att lära dig om komplexiteten i att koordinera multiproduktutveckling, om vad en teknisk karta är och hur den hjälper till att effektivisera och replikera lösningar, vilka är de viktigaste stegen och stegen i utvecklingsprocessen, hur är ansvarsområdena mellan DevOps och team i vårt företag.
Om Chaos och DevOps
Kortfattat inkluderar konceptet DevOps utvecklingsverktyg och tjänster, såväl som metoder och bästa praxis för deras användning. Låt oss peka ut det globala mål från implementeringen av DevOps-idéer i vårt företag: detta är en konsekvent minskning av kostnaden för produktion och underhåll av produkter i kvantitativa termer (mantimmar eller maskintimmar, CPU, RAM, disk, etc.). Det enklaste och mest uppenbara sättet att minska den totala kostnaden för utveckling på hela företagets nivå är minimera kostnaden för att utföra typiska serieuppgifter i alla produktionsled. Men vilka är dessa stadier, hur skiljer man dem från den allmänna processen, vilka steg består de av?
När ett företag utvecklar en produkt är allt mer eller mindre klart: det finns vanligtvis en gemensam färdplan och utvecklingsschema. Men vad ska man göra när produktsortimentet utökas och det finns fler produkter? Vid första anblicken har de liknande processer och monteringslinjer, och spelet "hitta X skillnader" i loggar och skript börjar. Men vad händer om det redan finns 5+ projekt i aktiv utveckling och det krävs stöd för flera versioner utvecklade under flera år? Vill vi återanvända så många lösningar som möjligt i produktpipelines eller är vi redo att spendera pengar på en unik utveckling för var och en?
Hur hittar man en balans mellan unikhet och serielösningar?
Dessa frågor började dyka upp framför oss allt oftare sedan 2015. Antalet produkter växte och vi försökte utöka vår automationsavdelning (DevOps), som stödde monteringslinjerna för dessa produkter, till ett minimum. Samtidigt ville vi replikera så många lösningar som möjligt mellan produkter. När allt kommer omkring, varför göra samma sak i tio produkter på olika sätt?
Utvecklingsdirektör: "Killar, kan vi på något sätt utvärdera vad DevOps gör för produkter?"
Vi: "Vi vet inte, vi ställde inte en sådan fråga, men vilka indikatorer bör övervägas?"
Utvecklingsdirektör: "Vem vet! Tror…"
Som i den där berömda filmen: "I'm in a hotel! .." - "Eh ... Kan du visa mig vägen?" Vid närmare eftertanke kom vi fram till att vi först måste besluta om produkternas sluttillstånd; detta blev vårt första mål.
Så, hur analyserar du ett dussin produkter med ganska stora team från 10 till 200 personer och bestämmer mätbara mätvärden när du replikerar lösningar?
1:0 till förmån för Chaos, eller DevOps på skulderbladen
Vi började med ett försök att tillämpa IDEF0-diagram och olika affärsprocessdiagram från BPwin-serien. Förvirringen började efter den femte rutan i nästa steg i nästa projekt, och dessa rutor för varje projekt kan ritas i svansen av en lång pyton under 50+ steg. Jag kände mig ledsen och ville yla mot månen - det passade inte i allmänhet.
Typiska produktionsuppgifter
Att modellera produktionsprocesser är ett mycket komplext och mödosamt jobb: du behöver samla in, bearbeta och analysera mycket data från olika avdelningar och produktionskedjor. Du kan läsa mer om detta i artikeln "".
När vi började modellera vår produktionsprocess hade vi ett specifikt mål - att förmedla till alla anställda som är involverade i utvecklingen av vårt företags produkter och till projektledare:
- hur produkter och deras komponenter, utgående från en kodrad, når kunden i form av installatörer och uppdateringar,
- vilka resurser som tillhandahålls för varje steg i produktionen av produkter,
- vilka tjänster är involverade i varje steg,
- hur ansvarsområdena för varje steg är avgränsade,
- vilka kontrakt som finns vid ingången och utgången av varje etapp.
Genom att klicka på bilden öppnas den i full storlek
Vårt arbete i företaget är uppdelat i flera funktionsområden. Infrastrukturens riktning är engagerad i optimeringen av driften av alla "järn"-resurser på avdelningen, såväl som automatisering av utplaceringen av virtuella maskiner och miljön på dem. Riktningen för övervakningen ger 24/7 serviceprestandakontroll; vi tillhandahåller även övervakning som en tjänst för utvecklare. Arbetsflödesriktningen förser team med verktyg för att hantera utvecklings- och testprocesser, analysera kodens tillstånd och få analyser av projekt. Och slutligen tillhandahåller webdev-riktningen publicering av utgåvor på GUS- och FLUS-uppdateringsservrarna, såväl som licensiering av produkter som använder LicenseLab-tjänsten. För att stödja produktionspipelinen ställer vi upp och underhåller många olika supporttjänster för utvecklare (du kan lyssna på berättelser om några av dem på gamla möten: и). Vi utvecklar även interna automationsverktyg, bl.a .
Under de senaste fem åren har vårt arbete samlat på sig mycket av samma typ och rutinverksamhet och våra utvecklare från andra avdelningar kommer främst från s.k. typiska uppgifter, vars lösning är helt eller delvis automatiserad, orsakar inte svårigheter för utförare och kräver inte betydande mängder arbete. Tillsammans med de ledande områdena analyserade vi sådana uppgifter och kunde identifiera enskilda arbetskategorier, eller produktionssteg, stadierna var indelade i odelbara steg, och flera stadier läggs ihop produktionsprocesskedja.
Det enklaste exemplet på en teknisk kedja är stegen för montering, driftsättning och testning av var och en av våra produkter inom företaget. I sin tur, till exempel, består byggstadiet av många separata typiska steg: ladda ner källor från GitLab, förbereda beroenden och tredjepartsbibliotek, enhetstestning och statisk kodanalys, exekvera ett byggskript på GitLab CI, publicera artefakter i förvaret på Artifactory och generering av release notes genom vårt interna ChangelogBuilder-verktyg.
Du kan läsa om typiska DevOps-uppgifter i våra andra artiklar om Habré: ""Och"".
Många typiska produktionskedjor bildas tillverkningsprocess. Standardmetoden för att beskriva processer är att använda funktionella IDEF0-modeller.
Ett exempel på modellering av en CI-tillverkningsprocess
Vi ägnade särskild uppmärksamhet åt utvecklingen av standardprojekt för ett kontinuerligt integrationssystem. Detta gjorde det möjligt att uppnå enande av projekt, vilket belyser den så kallade släpp byggsystem med kampanjer.
Så här fungerar det. Alla projekt ser typiska ut: de inkluderar konfigurationen av sammansättningar som faller in i ögonblicksbildförvaret på Artifactory, varefter de distribueras och testas på testbänkar och sedan flyttas upp till releaseförvaret. Artifactory-tjänsten är en enda distributionspunkt för alla byggartefakter mellan team och andra tjänster.
Om vi avsevärt förenklar och generaliserar vårt releaseschema inkluderar det följande steg:
- plattformsoberoende produktmontering,
- utplacering för att testa bänkar,
- köra funktionella och andra tester,
- främja testade konstruktioner för att släppa arkiv på Artifactory,
- publicering av utgåvor på uppdateringsservrar,
- leverans av sammansättningar och uppdateringar till produktion,
- lansering av installation och uppdatering av produkten.
Tänk till exempel på den tekniska modellen för detta typiska releaseschema (nedan helt enkelt modell) i form av en funktionell IDEF0-modell. Det återspeglar huvudstadierna i vår CI-process. IDEF0-modeller använder den sk ICOM-notation (Input-Control-Output-Mechanism) för att beskriva vilka resurser som används i varje steg, baserat på vilka regler och kravarbete som utförs, vad som är resultatet och vilka mekanismer, tjänster eller personer som implementerar ett visst steg.
Genom att klicka på bilden öppnas den i full storlek
Som regel är det lättare att dekomponera och detaljera beskrivningen av processer i funktionella modeller. Men i takt med att antalet element växer blir det svårare och svårare att förstå något i dem. Men i verklig utveckling finns det också hjälpsteg: övervakning, produktcertifiering, automatisering av arbetsflöden och andra. Det är på grund av skalningsproblemet som vi övergav den här beskrivningen.
Hoppets födelse
I en bok stötte vi på gamla sovjetiska kartor som beskriver tekniska processer (som för övrigt fortfarande används idag på många statligt ägda företag och universitet). Vänta, vänta, för vi har också ett arbetsflöde!.. Det finns stadier, resultat, mått, krav, indikatorer och så vidare och så vidare... Varför inte försöka tillämpa flödesscheman på våra produktpipelines också? Det fanns en känsla: "Det här är det! Vi har hittat rätt tråd, det är dags att dra den ordentligt!
I en enkel tabell bestämde vi oss för att registrera produkter efter kolumner, och tekniska stadier och produktpipeline steg för rader. Milstolpar är något stort, till exempel ett produktbyggande steg. Och steg är något mindre och mer detaljerat, som steget att ladda ner källkoden till byggservern eller steget att kompilera koden.
I skärningspunkterna mellan raderna och kolumnerna på kartan lägger vi ner status för en specifik etapp och produkt. För statusar definierades en uppsättning tillstånd:
- Ingen information - eller olämpligt. Det är nödvändigt att analysera efterfrågan på ett stadium i produkten. Antingen har analysen redan genomförts, men stadiet behövs för närvarande inte eller är inte ekonomiskt motiverat.
- Uppskjuten - eller inte relevant för tillfället. Det behövs ett skede i pipelinen, men det finns inga krafter för genomförandet i år.
- Planerad. Etappen är planerad att genomföras i år.
- Genomfört. Stadiet i pipelinen implementeras i den erforderliga volymen.
Att fylla i tabellen började projekt för projekt. Först klassificerades stadierna och stegen i ett projekt och deras status registrerades. Sedan tog de nästa projekt, fixade statusen i det och lade till de stadier och steg som saknades i tidigare projekt. Som ett resultat fick vi stadierna och stegen i hela vår produktionspipeline och deras status i ett specifikt projekt. Det visade sig något liknande produktpipeline-kompetensmatrisen. Vi kallade en sådan matris för en teknisk karta.
Med hjälp av den tekniska kartan samordnar vi mättekniskt rimligt med teamen de arbetsplaner för året och de mål som vi tillsammans vill uppnå: vilka etapper vi lägger till projektet i år, och vilka vi lämnar för senare. Under arbetets gång kan vi också ha förbättringar i de stadier som vi har genomfört för endast en produkt. Sedan utökar vi vår karta och introducerar denna förbättring som ett steg eller ett nytt steg, sedan analyserar vi för varje produkt och tar reda på möjligheten att replikera förbättringen.
De kan invända mot oss: "Detta är naturligtvis bra, bara med tiden kommer antalet steg och etapper att bli oöverkomligt stort. Hur man är?
Vi har infört standardiserade och ganska fullständiga beskrivningar av kraven för varje steg och steg, så att de förstås av alla inom företaget på samma sätt. Med tiden, när förbättringar införs, kan ett steg tas upp i ett annat steg eller steg, och sedan kommer de att "kollaps". Samtidigt passar alla krav och tekniska nyanser in i kraven för generaliseringsstadiet eller steget.
Hur utvärderar man effekten av att replikera lösningar? Vi använder ett extremt enkelt tillvägagångssätt: vi tillskriver de initiala kapitalkostnaderna för implementeringen av ett nytt steg till årliga allmänna produktkostnader och dividerar sedan med alla vid replikering.
Delar av utvecklingen visas redan som milstolpar och steg på kartan. Vi kan påverka minskningen av kostnaden för produkten genom införandet av automatisering för typiska steg. Efter det överväger vi förändringarna i kvalitativa egenskaper, kvantitativa mått och vinsten som teamen fått (i mantimmar eller maskintimmar av besparingar).
Teknologisk karta över produktionsprocessen
Om vi tar alla våra steg och steg, kodar dem med taggar och utökar dem till en kedja, kommer det att visa sig vara väldigt långt och obegripligt (bara själva "pytonsvansen" som vi pratade om i början av artikeln) :
[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]Det här är stadierna för att bygga produkter [Build], distribuera dem för att testa servrar [Deploy], testa [Test], främja byggen för att släppa arkiv baserat på resultaten av testning [Promote], generera och publicera licenser [License], publicering [ Publicera] på GUS uppdateringsserver och leverans till FLUS uppdateringsservrar, installation och uppdatering av produktkomponenter på kundens infrastruktur med hjälp av Product Configuration Management [Install], samt insamling av telemetri [Telemetri] från installerade produkter.
Utöver dem kan separata stadier urskiljas: övervakning av infrastrukturtillstånd [InfMonitoring], versionering av källkod [SourceCodeControl], förberedelse av byggmiljön [Förbereda], projektledning [Arbetsflöde], förse team med kommunikationsverktyg [Kommunikation], produktcertifiering [ Certifiering] och säkerställa självförsörjning av CI-processer [CISelfSufficiency] (till exempel oberoende av sammansättningar från Internet). Dussintals steg i våra processer kommer inte ens att beaktas, eftersom de är mycket specifika.
Det blir mycket lättare att förstå och se hela produktionsprocessen om den presenteras i formuläret teknisk karta; detta är en tabell där de individuella produktionsstegen och nedbrutna stegen i modellen skrivs i rader och i kolumner en beskrivning av vad som görs i varje steg eller steg. Huvudvikten läggs på de resurser som ger varje led, och avgränsningen av ansvarsområden.
Kartan för oss är en sorts klassificerare. Det speglar de stora tekniska delarna av produktionen av produkter. Tack vare det blev det enklare för vårt automationsteam att interagera med utvecklare och gemensamt planera implementeringen av automatiseringsstadier, samt förstå vilka arbetskostnader och resurser (människa och hårdvara) som kommer att krävas för detta.
Inom vårt företag genereras kartan automatiskt från jinja-mallen som en vanlig HTML-fil, och laddas sedan upp till GitLab Pages-servern. En skärmdump med ett exempel på en fullt genererad karta kan ses .
Genom att klicka på bilden öppnas den i full storlek
Kort sagt är den tekniska kartan en generaliserad bild av produktionsprocessen, som återspeglar tydligt klassificerade block med typisk funktionalitet.
Strukturen på vår färdplan
Kartan består av flera delar:
- Titelområde - här är en allmän beskrivning av kartan, grundläggande begrepp introduceras, de viktigaste resurserna och resultaten av produktionsprocessen definieras.
- Dashboard - här kan du styra visningen av data för enskilda produkter, en sammanfattning av de implementerade stegen och stegen i allmänhet för alla produkter tillhandahålls.
- Teknologisk karta - en tabellformig beskrivning av den tekniska processen. På kartan:
- alla steg, steg och deras koder anges;
- korta och fullständiga beskrivningar av stadierna ges;
- de inmatningsresurser och tjänster som används i varje steg anges;
- resultaten av varje steg och ett separat steg anges;
- ansvarsområdet för varje steg och steg anges;
- de tekniska resurserna, såsom HDD (SSD), RAM, vCPU och de mantimmar som krävs för att stödja arbetet i detta skede, både för närvarande - ett faktum och i framtiden - en plan, har fastställts;
- för varje produkt anges vilka tekniska steg eller steg för den som har implementerats, planerat för implementering, irrelevanta eller inte implementerade.
Beslutsfattande baserat på den tekniska kartan
Efter att ha undersökt kartan är det möjligt att vidta några åtgärder - beroende på vilken roll medarbetaren har i företaget (utvecklingschef, produktchef, utvecklare eller testare):
- förstå vilka stadier som saknas i en verklig produkt eller projekt, och bedöma behovet av deras genomförande;
- avgränsa ansvarsområdena mellan flera avdelningar om de arbetar på olika etapper;
- komma överens om kontrakt vid scenernas in- och utgångar;
- integrera ditt arbetsstadium i den övergripande utvecklingsprocessen;
- mer exakt bedöma behovet av resurser som tillhandahåller vart och ett av stegen.
Sammanfattar allt ovanstående
Rutten är mångsidig, utdragbar och lätt att underhålla. Det är mycket lättare att utveckla och underhålla en beskrivning av processer i denna form än i en strikt akademisk IDEF0-modell. Dessutom är en tabellbeskrivning enklare, mer bekant och bättre strukturerad än en funktionell modell.
För den tekniska implementeringen av stegen har vi ett speciellt internt verktyg CrossBuilder – ett lagerverktyg mellan CI-system, tjänster och infrastruktur. Utvecklaren behöver inte klippa sin cykel: i vårt CI-system räcker det att köra ett av skripten (den så kallade uppgiften) i CrossBuilder-verktyget, som kommer att utföra det korrekt, med hänsyn till funktionerna i vår infrastruktur .
Resultat av
Artikeln visade sig vara ganska lång, men detta är oundvikligt när man beskriver modelleringen av komplexa processer. Till sist skulle jag vilja fixa våra huvudidéer kort:
- Målet med att implementera DevOps-idéer i vårt företag är att konsekvent minska kostnaderna för produktion och underhåll av företagets produkter i kvantitativa termer (mantimmar eller maskintimmar, vCPU, RAM, Disk).
- Sättet att minska den totala kostnaden för utveckling är att minimera kostnaderna för att utföra typiska serieuppgifter: stadier och steg i den tekniska processen.
- En typisk uppgift är en uppgift vars lösning är helt eller delvis automatiserad, inte orsakar svårigheter för utförare och inte kräver betydande arbetskostnader.
- Produktionsprocessen består av steg, stegen är indelade i odelbara steg, som är typiska uppgifter av olika skala och omfattning.
- Från olika typiska uppgifter har vi kommit till komplexa tekniska kedjor och flernivåmodeller av produktionsprocessen, som kan beskrivas med en funktionell IDEF0-modell eller en enklare teknisk karta.
- Den tekniska kartan är en tabellformig representation av stadierna och stegen i produktionsprocessen. Det viktigaste: kartan låter dig se hela processen i sin helhet, i stora bitar med möjlighet att detaljera dem.
- Baserat på den tekniska kartan är det möjligt att bedöma behovet av att införa stadier i en viss produkt, avgränsa ansvarsområden, komma överens om kontrakt vid ingångarna och utgångarna av stegen och mer exakt bedöma behovet av resurser.
I de följande artiklarna kommer vi att beskriva mer i detalj vilka tekniska verktyg som används för att implementera vissa tekniska stadier på vår karta.
Artikelförfattare:
- — Chef för Automation (DevOps) på Positive Technologies
- - Suppleant Chef för automationsavdelningen (DevOps) på Positive Technologies
Källa: will.com