Prent:
Hi almal! Ons is outomatiseringsingenieurs van die maatskappy en ons ondersteun die ontwikkeling van die maatskappy se produkte: ons ondersteun die hele samestellingspyplyn van die pleeg van 'n reël kode deur ontwikkelaars tot die publikasie van voltooide produkte en lisensies op opdateringsbedieners. Informeel word ons DevOps-ingenieurs genoem. In hierdie artikel wil ons praat oor die tegnologiese stadiums van die sagtewareproduksieproses, hoe ons dit sien en hoe ons dit klassifiseer.
Uit die materiaal sal jy leer oor die kompleksiteit van die koördinering van multi-produk ontwikkeling, oor wat 'n tegnologiese kaart is en hoe dit help om oplossings te stroomlyn en te herhaal, wat is die hoofstadia en stappe van die ontwikkelingsproses, hoe is die verantwoordelikheidsareas tussen DevOps en spanne in ons maatskappy.
Oor Chaos en DevOps
Kortliks, die konsep van DevOps sluit ontwikkelingshulpmiddels en -dienste in, sowel as metodologieë en beste praktyke vir die gebruik daarvan. Kom ons sonder die globale uit die doel van die implementering van DevOps-idees in ons maatskappy: dit is 'n konsekwente vermindering in die koste van produksie en instandhouding van produkte in kwantitatiewe terme (man-ure of masjienure, SVE, RAM, Skyf, ens.). Die maklikste en mees voor die hand liggende manier om die algehele koste van ontwikkeling op die vlak van die hele maatskappy te verminder, is die vermindering van die koste van die uitvoering van tipiese reekstake in alle stadiums van produksie. Maar wat is hierdie stadiums, hoe om hulle van die algemene proses te skei, uit watter stappe bestaan dit?
Wanneer 'n maatskappy een produk ontwikkel, is alles min of meer duidelik: daar is gewoonlik 'n gemeenskaplike padkaart en ontwikkelingskema. Maar wat om te doen wanneer die produkreeks uitbrei en daar meer produkte is? Met die eerste oogopslag het hulle soortgelyke prosesse en monteerlyne, en die "vind X verskille"-speletjie in logs en skrifte begin. Maar wat as daar reeds 5+ projekte in aktiewe ontwikkeling is en ondersteuning vir verskeie weergawes wat oor etlike jare ontwikkel is, word vereis? Wil ons die maksimum moontlike aantal oplossings in produkpyplyne hergebruik of is ons gereed om geld te spandeer op 'n unieke ontwikkeling vir elkeen?
Hoe om 'n balans tussen uniekheid en reeksoplossings te vind?
Hierdie vrae het sedert 2015 al hoe meer voor ons begin opkom. Die aantal produkte het gegroei, en ons het probeer om ons outomatiseringsafdeling (DevOps), wat die monteerlyne van hierdie produkte ondersteun het, tot 'n minimum uit te brei. Terselfdertyd wou ons soveel moontlik oplossings tussen produkte herhaal. Per slot van rekening, hoekom doen dieselfde ding in tien produkte op verskillende maniere?
Ontwikkelingsdirekteur: "Manne, kan ons op een of ander manier evalueer wat DevOps vir produkte doen?"
Ons is: "Ons weet nie, ons het nie so 'n vraag gevra nie, maar watter aanwysers moet oorweeg word?"
Ontwikkelingsdirekteur: "Wie weet! Dink…”
Soos in daardie bekende film: "Ek is in 'n hotel! .." - "Uh ... Kan jy my die pad wys?" By nabetragting het ons tot die gevolgtrekking gekom dat ons eers moet besluit oor die finale toestande van die produkte; dit het ons eerste doelwit geword.
So, hoe ontleed jy 'n dosyn produkte met redelik groot spanne van 10 tot 200 mense en bepaal meetbare statistieke wanneer oplossings herhaal word?
1:0 ten gunste van Chaos, of DevOps op die skouerblaaie
Ons het begin met 'n poging om IDEF0-diagramme en verskeie besigheidsprosesdiagramme uit die BPwin-reeks toe te pas. Die verwarring het begin na die vyfde blokkie van die volgende fase van die volgende projek, en hierdie blokkies vir elke projek kan in die stert van 'n lang luislang onder 50+ treë geteken word. Ek het hartseer gevoel en wou vir die maan huil - dit het oor die algemeen nie gepas nie.
Tipiese produksie take
Modellering van produksieprosesse is 'n baie komplekse en noukeurige taak: jy moet baie data van verskeie departemente en produksiekettings insamel, verwerk en ontleed. Jy kan meer hieroor lees in die artikel "".
Toe ons ons produksieproses begin modelleer het, het ons 'n spesifieke doelwit gehad - om aan elke werknemer betrokke by die ontwikkeling van ons maatskappy se produkte en aan projekbestuurders oor te dra:
- hoe produkte en hul komponente, vanaf die pleging van 'n reël kode, die kliënt bereik in die vorm van installeerders en opdaterings,
- watter hulpbronne voorsien word vir elke stadium van produksie van produkte,
- watter dienste by elke stadium betrokke is,
- hoe die areas van verantwoordelikheid vir elke stadium afgebaken word,
- watter kontrakte bestaan by die ingang en uitgang van elke stadium.
As u op die prent klik, sal dit in volle grootte oopmaak
Ons werk in die maatskappy is verdeel in verskeie funksionele areas. Die rigting van die infrastruktuur is besig met die optimalisering van die werking van al die "yster" hulpbronne van die departement, sowel as die outomatisering van die ontplooiing van virtuele masjiene en die omgewing daarop. Die rigting van monitering bied 24/7 diensprestasiebeheer; ons verskaf ook monitering as 'n diens vir ontwikkelaars. Die werkvloeirigting voorsien spanne van gereedskap om ontwikkelings- en toetsprosesse te bestuur, die toestand van die kode te ontleed en ontleding van projekte te kry. En uiteindelik bied die webdev-rigting die publikasie van vrystellings op die GUS- en FLUS-opdateringbedieners, sowel as die lisensiëring van produkte wat die LicenseLab-diens gebruik. Om die produksiepyplyn te ondersteun, stel en onderhou ons baie verskillende ondersteuningsdienste vir ontwikkelaars (jy kan na stories oor sommige van hulle op ou ontmoetings luister: и). Ons ontwikkel ook interne outomatiseringsinstrumente, insluitend .
Oor die afgelope vyf jaar het ons werk baie van dieselfde tipe en roetine-bedrywighede opgehoop, en ons ontwikkelaars van ander departemente kom hoofsaaklik uit die sg. tipiese take, waarvan die oplossing ten volle of gedeeltelik geoutomatiseer is, veroorsaak nie probleme vir kunstenaars nie en vereis nie aansienlike hoeveelhede werk nie. Saam met die leidende areas het ons sulke take ontleed en kon individuele kategorieë werk identifiseer, of produksiestappe, die stadiums is in ondeelbare stappe verdeel, en verskeie stadiums voeg by produksie proses ketting.
Die eenvoudigste voorbeeld van 'n tegnologiese ketting is die stadiums van samestelling, ontplooiing en toetsing van elk van ons produkte binne die maatskappy. Op sy beurt bestaan die boustadium byvoorbeeld uit baie afsonderlike tipiese stappe: aflaai van bronne vanaf GitLab, voorbereiding van afhanklikhede en derdeparty-biblioteke, eenheidstoetsing en statiese kode-analise, uitvoering van 'n bouskrip op GitLab CI, publisering van artefakte in die bewaarplek op Artifactory en generering van vrystellingsnotas deur ons interne ChangelogBuilder-instrument.
Jy kan lees oor tipiese DevOps-take in ons ander artikels oor Habré: ""En"".
Baie tipiese produksiekettings vorm vervaardigingsproses. Die standaardbenadering om prosesse te beskryf is om funksionele IDEF0-modelle te gebruik.
'n Voorbeeld van modellering van 'n vervaardigings-CI-proses
Ons het spesiale aandag gegee aan die ontwikkeling van standaardprojekte vir 'n deurlopende integrasiestelsel. Dit het dit moontlik gemaak om die eenwording van projekte te bereik, met die klem op die sogenaamde vrystelling bou skema met promosies.
Hier is hoe dit werk. Alle projekte lyk tipies: dit sluit die opstelling van samestellings in wat in die momentopnamebewaarplek by Artifactory val, waarna dit op toetsbanke ontplooi en getoets word, en dan bevorder word na die vrystellingsbewaarplek. Die Artifactory-diens is 'n enkele verspreidingspunt vir alle bou-artefakte tussen spanne en ander dienste.
As ons ons vrystellingskema aansienlik vereenvoudig en veralgemeen, sluit dit die volgende stappe in:
- kruis-platform produk samestelling,
- ontplooiing om banke te toets,
- funksionele en ander toetse uitvoer,
- die bevordering van getoetste bouwerk om bewaarplekke by Artifactory vry te stel,
- publikasie van vrystellingbou op opdateringsbedieners,
- aflewering van samestellings en opdaterings aan produksie,
- die bekendstelling van die installering en opdatering van die produk.
Beskou byvoorbeeld die tegnologiese model van hierdie tipiese vrystellingskema (hierna bloot Model) in die vorm van 'n funksionele IDEF0-model. Dit weerspieël die hoofstadia van ons GI-proses. IDEF0 modelle gebruik die sg ICOM-notasie (Inset-Beheer-Uitset-meganisme) om te beskryf watter hulpbronne in elke stadium gebruik word, gebaseer op watter reëls en vereistes werk uitgevoer word, wat die uitset is, en watter meganismes, dienste of mense 'n bepaalde stadium implementeer.
As u op die prent klik, sal dit in volle grootte oopmaak
As 'n reël is dit makliker om die beskrywing van prosesse in funksionele modelle te ontbind en te detail. Maar soos die aantal elemente groei, word dit al hoe moeiliker om iets daarin te verstaan. Maar in werklike ontwikkeling is daar ook bykomende stadiums: monitering, sertifisering van produkte, outomatisering van werkprosesse, en ander. Dit is as gevolg van die skaalprobleem dat ons hierdie beskrywing laat vaar het.
Geboorte van hoop
In een boek het ons op ou Sowjet-kaarte afgekom wat tegnologiese prosesse beskryf (wat, terloops, vandag nog by baie staatsondernemings en universiteite gebruik word). Wag, wag, want ons het ook 'n werkvloei!.. Daar is stadiums, resultate, maatstawwe, vereistes, aanwysers, ensovoorts, ensovoorts... Hoekom nie probeer om vloeistate ook op ons produkpyplyne toe te pas nie? Daar was 'n gevoel: “Dit is dit! Ons het die regte draad gevind, dit is tyd om dit goed te trek!
In 'n eenvoudige tabel het ons besluit om produkte volgens kolomme, en tegnologiese stadiums en produkpyplyn stappe volgens rye aan te teken. Mylpale is iets groots, soos 'n produkboustap. En stappe is iets kleiner en meer gedetailleerd, soos die stap om die bronkode af te laai na die boubediener of die stap om die kode saam te stel.
By die kruisings van die rye en kolomme van die kaart, plaas ons die statusse vir 'n spesifieke stadium en produk. Vir statusse is 'n stel state gedefinieer:
- Geen data - of onvanpas. Dit is nodig om die vraag na 'n stadium in die produk te ontleed. Óf die ontleding is reeds uitgevoer, maar die stadium is tans nie nodig nie of is nie ekonomies geregverdig nie.
- Uitgestel - of nie op die oomblik relevant nie. ’n Stadium in die pyplyn is nodig, maar daar is geen kragte vir implementering vanjaar nie.
- Beplan. Die stadium word beplan vir implementering vanjaar.
- Geïmplementeer. Die stadium in die pyplyn word in die vereiste volume geïmplementeer.
Die invul van die tabel het projek vir projek begin. Eerstens is die stadiums en stappe van een projek geklassifiseer en hul statusse is aangeteken. Toe het hulle die volgende projek geneem, die statusse daarin reggemaak en die stadiums en stappe bygevoeg wat in vorige projekte ontbreek het. Gevolglik het ons die stadiums en stappe van ons hele produksiepyplyn en hul status in 'n spesifieke projek gekry. Dit het geblyk iets soortgelyk aan die produk pyplyn bevoegdheid matriks. Ons het so 'n matriks 'n tegnologiese kaart genoem.
Met behulp van die tegnologiese kaart koördineer ons metrologies redelik met die spanne die werkplanne vir die jaar en die teikens wat ons saam wil bereik: watter stadiums ons vanjaar by die projek voeg, en watter ons laat vir later. Ons kan ook in die loop van die werk verbeterings hê in die stadiums wat ons vir slegs een produk voltooi het. Dan brei ons ons kaart uit en stel hierdie verbetering as 'n stadium of 'n nuwe stap bekend, dan ontleed ons vir elke produk en vind uit die haalbaarheid om die verbetering te herhaal.
Hulle kan teen ons beswaar maak: “Dit is alles, natuurlik, goed, net mettertyd sal die aantal stappe en fases buitensporig groot word. Hoe om te wees?
Ons het standaard en redelik volledige beskrywings van die vereistes vir elke stadium en stap ingestel, sodat dit deur almal binne die maatskappy op dieselfde manier verstaan word. Met verloop van tyd, soos verbeterings ingestel word, kan 'n stap in 'n ander stadium of stap opgeneem word, en dan sal hulle "ineenstort". Terselfdertyd pas alle vereistes en tegnologiese nuanses in by die vereistes van die veralgemenende stadium of stap.
Hoe om die effek van repliserende oplossings te evalueer? Ons gebruik 'n uiters eenvoudige benadering: ons skryf die aanvanklike kapitaalkoste vir die implementering van 'n nuwe stadium toe aan die jaarlikse algemene produkkoste, en deel dan deur almal wanneer ons repliseer.
Dele van die ontwikkeling word reeds as mylpale en stappe op die kaart gewys. Ons kan die vermindering van die koste van die produk beïnvloed deur die bekendstelling van outomatisering vir tipiese stadiums. Daarna oorweeg ons die veranderinge in kwalitatiewe kenmerke, kwantitatiewe maatstawwe en die wins wat die spanne ontvang (in man-ure of masjien-ure van besparing).
Tegnologiese kaart van die produksieproses
As ons al ons stadiums en stappe neem, dit met etikette enkodeer en dit in een ketting uitbrei, sal dit baie lank en onverstaanbaar blyk te wees (net dieselfde "python-stert" waarvan ons aan die begin van die artikel gepraat het) :
[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]Dit is die stadiums van die bou van produkte [Bou], die implementering daarvan om bedieners te toets [Ontplooi], toets [Toets], die bevordering van bouwerk om bewaarplekke vry te stel gebaseer op die resultate van die toets [Bevorder], genereer en publiseer lisensies [Lisensie], publisering [ Publiseer] op die GUS-opdateringbediener en aflewering aan FLUS-opdateringbedieners, installering en opdatering van produkkomponente op die kliënt se infrastruktuur deur gebruik te maak van Produkkonfigurasiebestuur [Installeer], asook insameling van telemetrie [Telemetrie] vanaf geïnstalleerde produkte.
Benewens hulle, kan afsonderlike stadiums onderskei word: infrastruktuur-toestandmonitering [InfMonitoring], bronkodeweergawe [SourceCodeControl], bou-omgewingvoorbereiding [Berei], projekbestuur [Werkvloei], voorsien spanne van kommunikasie-instrumente [Kommunikasie], produksertifisering [ Sertifisering] en die versekering van selfvoorsiening van GI-prosesse [CISelfSufficiency] (byvoorbeeld onafhanklikheid van gemeentes van die internet). Tientalle stappe in ons prosesse sal nie eers oorweeg word nie, want dit is baie spesifiek.
Dit sal baie makliker wees om die hele produksieproses te verstaan en te sien as dit in die vorm aangebied word tegnologiese kaart; dit is 'n tabel waarin die individuele produksiestadia en ontbinde stappe van die Model in rye geskryf word, en in kolomme 'n beskrywing van wat by elke stadium of stap gedoen word. Die hoofklem word geplaas op die hulpbronne wat elke stadium verskaf, en die afbakening van verantwoordelikheidsareas.
Die kaart is vir ons 'n soort klassifiseerder. Dit weerspieël die groot tegnologiese dele van die produksie van produkte. Danksy dit het dit makliker geword vir ons outomatiseringspan om met ontwikkelaars te kommunikeer en gesamentlik die implementering van outomatiseringstadia te beplan, asook om te verstaan watter arbeidskoste en hulpbronne (mens en hardeware) hiervoor benodig sal word.
Binne ons maatskappy word die kaart outomaties gegenereer vanaf die jinja-sjabloon as 'n gewone HTML-lêer, en dan opgelaai na die GitLab Pages-bediener. 'n Skermskoot met 'n voorbeeld van 'n volledig gegenereerde kaart kan bekyk word .
As u op die prent klik, sal dit in volle grootte oopmaak
Kortom, die tegnologiese kaart is 'n algemene prentjie van die produksieproses, wat duidelik geklassifiseerde blokke met tipiese funksionaliteit weerspieël.
Struktuur van ons padkaart
Die kaart bestaan uit verskeie dele:
- Titelgebied - hier is 'n algemene beskrywing van die kaart, basiese konsepte word bekendgestel, die hoofbronne en resultate van die produksieproses word gedefinieer.
- Dashboard - hier kan jy die vertoning van data vir individuele produkte beheer, 'n opsomming van die geïmplementeerde stadiums en stappe in die algemeen vir alle produkte word verskaf.
- Tegnologiese kaart - 'n tabelvormige beskrywing van die tegnologiese proses. Op die kaart:
- alle stadiums, stappe en hul kodes word gegee;
- kort en volledige beskrywings van die stadiums word gegee;
- die insetbronne en dienste wat in elke stadium gebruik word, word aangedui;
- die resultate van elke stadium en 'n aparte stap word aangedui;
- die area van verantwoordelikheid vir elke stadium en stap word aangedui;
- die tegniese hulpbronne, soos HDD (SSD), RAM, vCPU, en die man-ure wat nodig is om die werk op hierdie stadium te ondersteun, beide op die huidige oomblik - 'n feit, en in die toekoms - 'n plan, is bepaal;
- vir elke produk word aangedui watter tegnologiese stadiums of stappe daarvoor geïmplementeer, beplan vir implementering, irrelevant of nie geïmplementeer is nie.
Besluitneming gebaseer op die tegnologiese kaart
Nadat u die kaart ondersoek het, is dit moontlik om 'n paar aksies te neem - afhangende van die rol van die werknemer in die maatskappy (ontwikkelingsbestuurder, produkbestuurder, ontwikkelaar of toetser):
- verstaan watter stadiums in 'n werklike produk of projek ontbreek, en die behoefte aan die implementering daarvan te evalueer;
- die verantwoordelikheidsgebiede tussen verskeie departemente af te baken indien hulle op verskillende stadiums werk;
- ooreenkom op kontrakte by die in- en uitgange van die verhoë;
- integreer jou stadium van werk in die algehele ontwikkelingsproses;
- assesseer die behoefte aan hulpbronne wat elk van die stadiums voorsien, meer akkuraat.
Som al die bogenoemde op
Die roetering is veelsydig, uitbreidbaar en maklik om te onderhou. Dit is baie makliker om 'n beskrywing van prosesse in hierdie vorm te ontwikkel en in stand te hou as in 'n streng akademiese IDEF0-model. Daarbenewens is 'n tabelbeskrywing eenvoudiger, meer bekend en beter gestruktureer as 'n funksionele model.
Vir die tegniese implementering van die stappe, het ons 'n spesiale interne hulpmiddel CrossBuilder - 'n laag hulpmiddel tussen CI stelsels, dienste en infrastruktuur. Die ontwikkelaar hoef nie sy fiets te sny nie: in ons CI-stelsel is dit genoeg om een van die skrifte (die sogenaamde taak) van die CrossBuilder-instrument uit te voer, wat dit korrek sal uitvoer, met inagneming van die kenmerke van ons infrastruktuur .
Resultate van
Die artikel was redelik lank, maar dit is onvermydelik wanneer die modellering van komplekse prosesse beskryf word. Op die ou end wil ek graag ons hoofgedagtes kortliks regmaak:
- Die doel van die implementering van DevOps-idees in ons maatskappy is om konsekwent die koste van produksie en instandhouding van die maatskappy se produkte in kwantitatiewe terme te verminder (man-ure of masjien-ure, vCPU, RAM, skyf).
- Die manier om die algehele koste van ontwikkeling te verminder, is om die koste van die uitvoering van tipiese reekstake te verminder: stadiums en stappe van die tegnologiese proses.
- 'n Tipiese taak is 'n taak waarvan die oplossing ten volle of gedeeltelik geoutomatiseer is, nie probleme vir presteerders veroorsaak nie en nie beduidende arbeidskoste vereis nie.
- Die produksieproses bestaan uit stadiums, die stadiums is verdeel in ondeelbare stappe, wat tipiese take van verskillende skaal en omvang is.
- Van uiteenlopende tipiese take het ons gekom tot komplekse tegnologiese kettings en multi-vlak modelle van die produksie proses, wat beskryf kan word deur 'n funksionele IDEF0 model of 'n eenvoudiger tegnologiese kaart.
- Die tegnologiese kaart is 'n tabelvormige voorstelling van die stadiums en stappe van die produksieproses. Die belangrikste ding: die kaart laat jou toe om die hele proses in sy geheel te sien, in groot stukke met die moontlikheid om dit te beskryf.
- Gebaseer op die tegnologiese kaart, is dit moontlik om die behoefte om stadiums in 'n bepaalde produk in te voer, te bepaal, areas van verantwoordelikheid af te baken, kontrakte by die insette en uitsette van stadiums ooreen te kom, en die behoefte aan hulpbronne meer akkuraat te assesseer.
In die volgende artikels sal ons in meer besonderhede beskryf watter tegniese gereedskap gebruik word om sekere tegnologiese stadiums op ons kaart te implementeer.
Artikel skrywers:
- — Hoof van outomatisering (DevOps) by Positive Technologies
- - Adjunk Hoof van Outomatiseringsafdeling (DevOps) by Positive Technologies
Bron: will.com