Kuva:
Hei kaikki! Olemme yrityksen automaatioinsinöörejä ja tuemme yrityksen tuotteiden kehitystä: tuemme koko kokoonpanoprosessia kehittäjien suorittamasta koodirivin sitomisesta valmiiden tuotteiden ja lisenssien julkaisemiseen päivityspalvelimilla. Epävirallisesti meitä kutsutaan DevOps-insinööreiksi. Tässä artikkelissa haluamme puhua ohjelmistotuotantoprosessin teknologisista vaiheista, miten näemme ne ja miten luokittelemme ne.
Materiaalista opit monituotekehityksen koordinoinnin monimutkaisuudesta, mitä on teknologinen kartta ja miten se auttaa virtaviivaistamaan ja monistamaan ratkaisuja, mitkä ovat kehitysprosessin päävaiheet ja vaiheet, miten vastuualueet ovat DevOpsin ja yrityksemme tiimien välillä.
Tietoja Chaoksesta ja DevOpsista
Lyhyesti sanottuna DevOps-konsepti sisältää kehitystyökalut ja -palvelut sekä metodologiat ja parhaat käytännöt niiden käyttöön. Nostellaanpa globaalia tavoite DevOps-ideoiden toteuttamisesta yrityksessämme: tämä on johdonmukaista alenemista tuotteiden tuotanto- ja ylläpitokustannuksissa määrällisesti (henkilötunnit tai konetunnit, CPU, RAM, levy jne.). Helpoin ja ilmeisin tapa alentaa kehittämisen kokonaiskustannuksia koko yrityksen tasolla on minimoimalla tyypillisten sarjatehtävien suorittamisen kustannukset kaikissa tuotannon vaiheissa. Mutta mitä nämä vaiheet ovat, miten ne erotetaan yleisestä prosessista, mistä vaiheista ne koostuvat?
Kun yritys kehittää yhtä tuotetta, kaikki on enemmän tai vähemmän selvää: yleensä on yhteinen tiekartta ja kehityssuunnitelma. Mutta mitä tehdä, kun tuotevalikoima laajenee ja tuotteita tulee lisää? Ensi silmäyksellä niillä on samanlaiset prosessit ja kokoonpanolinjat, ja "etsi X eroja" -peli lokeista ja skripteistä alkaa. Mutta entä jos aktiivisessa kehitystyössä on jo yli 5 projektia ja tukea tarvitaan useille versioille, jotka on kehitetty usean vuoden aikana? Haluammeko käyttää uudelleen mahdollisimman monta ratkaisua tuoteputkissa vai olemmeko valmiita käyttämään rahaa yksilölliseen kehitykseen jokaiselle?
Miten löytää tasapaino ainutlaatuisuuden ja sarjaratkaisujen välillä?
Nämä kysymykset alkoivat nousta eteenmme yhä useammin vuodesta 2015 lähtien. Tuotteiden määrä kasvoi ja yritimme laajentaa näiden tuotteiden kokoonpanolinjoja tukenut automaatioosastomme (DevOps) minimiin. Samalla halusimme kopioida mahdollisimman monta ratkaisua tuotteiden välillä. Loppujen lopuksi, miksi tehdä sama asia kymmenessä tuotteessa eri tavoin?
Kehitysjohtaja: "Kaverit, voimmeko jotenkin arvioida, mitä DevOps tekee tuotteille?"
me: "Emme tiedä, emme esittäneet tällaista kysymystä, mutta mitä indikaattoreita pitäisi ottaa huomioon?"
Kehitysjohtaja: "Kuka tietää! Ajatella…"
Kuten tuossa kuuluisassa elokuvassa: "Olen hotellissa! .." - "Öh... Voitko näyttää minulle tien?" Pohdittuamme tulimme siihen tulokseen, että meidän on ensin päätettävä tuotteiden lopulliset tilat; tästä tuli ensimmäinen maalimme.
Kuinka analysoida tusinaa tuotetta melko suurilla 10–200 hengen tiimeillä ja määrittää mitattavissa olevia mittareita, kun toistat ratkaisuja?
1:0 Chaosin tai DevOpsin hyväksi lapaluissa
Aloitimme yrityksellämme soveltaa IDEF0-kaavioita ja erilaisia BPwin-sarjan liiketoimintaprosessikaavioita. Hämmennys alkoi seuraavan projektin seuraavan vaiheen viidennen neliön jälkeen, ja nämä ruudut jokaiselle projektille voidaan piirtää pitkän pythonin pyrstään alle 50+ askeleen. Olin surullinen ja halusin ulvoa kuulle - se ei sopinut yleisesti.
Tyypillisiä tuotantotehtäviä
Tuotantoprosessien mallintaminen on erittäin monimutkaista ja vaivalloista työtä: sinun täytyy kerätä, käsitellä ja analysoida paljon dataa eri osastoilta ja tuotantoketjuilta. Voit lukea tästä lisää artikkelista "'.
Kun aloitimme tuotantoprosessimme mallintamisen, meillä oli erityinen tavoite - välittää jokaiselle yrityksemme tuotteiden kehitystyössä mukana olevalle työntekijälle ja projektipäälliköille:
- miten tuotteet ja niiden komponentit koodirivin sitomisesta alkaen saavuttavat asiakkaan asentajien ja päivitysten muodossa,
- mitä resursseja tarjotaan kullekin tuotteiden tuotantovaiheelle,
- mitä palveluita kussakin vaiheessa on mukana,
- miten kunkin vaiheen vastuualueet on rajattu,
- mitä sopimuksia on olemassa kunkin vaiheen sisään- ja uloskäynnissä.
Klikkaamalla kuvaa aukeaa se täysikokoisena
Työmme yrityksessä on jaettu useisiin toiminta-alueisiin. Infrastruktuurin suunta on mukana kaikkien osaston "rautaisten" resurssien toiminnan optimoinnissa sekä virtuaalikoneiden ja niillä olevan ympäristön käyttöönoton automatisoinnissa. Seurannan suunta tarjoaa 24/7 palvelun suorituskyvyn ohjauksen; tarjoamme myös seurantaa palveluna kehittäjille. Työnkulun suunta tarjoaa tiimeille työkalut kehitys- ja testausprosessien hallintaan, koodin tilan analysointiin ja projektien analytiikan hankkimiseen. Ja lopuksi webdev-suunta tarjoaa julkaisujen julkaisemisen GUS- ja FLUS-päivityspalvelimille sekä tuotteiden lisensoinnin LicenseLab-palvelun avulla. Tuotantoputken tukemiseksi perustamme ja ylläpidämme monia erilaisia apupalveluita kehittäjille (tarinoita joistakin niistä kuullaan vanhoissa tapaamisissa: и). Kehitämme myös sisäisiä automaatiotyökaluja mm .
Viimeisen viiden vuoden aikana työhömme on kertynyt paljon samantyyppisiä ja rutiinitoimintoja ja kehittäjät muilta osastoilta tulevat pääosin ns. tyypillisiä tehtäviä, jonka ratkaisu on täysin tai osittain automatisoitu, ei aiheuta vaikeuksia esiintyjille eikä vaadi merkittäviä määriä työtä. Yhdessä johtavien alueiden kanssa analysoimme tällaisia tehtäviä ja pystyimme tunnistamaan yksittäisiä työkategorioita tai tuotantovaiheet, vaiheet jaettiin jakamattomiin vaiheisiin, ja useita vaiheita lasketaan yhteen tuotantoprosessin ketju.
Yksinkertaisin esimerkki teknologisesta ketjusta on jokaisen tuotteemme kokoonpano-, käyttöönotto- ja testausvaiheet yrityksen sisällä. Esimerkiksi rakennusvaihe koostuu useista erillisistä tyypillisistä vaiheista: lähteiden lataaminen GitLabista, riippuvuuksien ja kolmannen osapuolen kirjastojen valmistelu, yksikkötestaus ja staattisen koodin analyysi, koontiskriptin suorittaminen GitLab CI:ssä, artefaktien julkaiseminen arkistossa Artefactory ja julkaisutiedotteiden luominen sisäisen ChangelogBuilder-työkalumme kautta.
Voit lukea tyypillisistä DevOps-tehtävistä muista Habré-artikkeleistamme: ""Ja"'.
Muodostuu monia tyypillisiä tuotantoketjuja valmistusprosessi. Tavallinen lähestymistapa prosessien kuvaamiseen on käyttää toiminnallisia IDEF0-malleja.
Esimerkki valmistusprosessin mallintamisesta
Kiinnitimme erityistä huomiota jatkuvan integraatiojärjestelmän standardiprojektien kehittämiseen. Tämä mahdollisti hankkeiden yhdistämisen korostaen ns julkaisun rakennussuunnitelma promootioilla.
Näin se toimii. Kaikki projektit näyttävät tyypillisiltä: ne sisältävät Artifactoryn tilannekuvasäilöön kuuluvien kokoonpanojen kokoonpanon, minkä jälkeen ne otetaan käyttöön ja testataan testipenkeissä ja siirretään sitten julkaisutietovarastoon. Artifactory-palvelu on yksi jakelupiste kaikille rakennusartefakteille tiimien ja muiden palvelujen välillä.
Jos yksinkertaistamme ja yleistämme suuresti julkaisujärjestelmäämme, se sisältää seuraavat vaiheet:
- alustojen välinen tuotekokoonpano,
- käyttää testipenkkeihin,
- toiminnallisten ja muiden testien suorittaminen,
- testattujen koontiversioiden mainostaminen arkistojen julkaisemiseksi Artifactoryssa,
- julkaisun julkaisu perustuu päivityspalvelimiin,
- kokoonpanojen ja päivitysten toimitus tuotantoon,
- tuotteen asennuksen ja päivityksen käynnistäminen.
Tarkastellaan esimerkiksi tämän tyypillisen julkaisumallin teknistä mallia (jäljempänä yksinkertaisesti malli) toiminnallisen IDEF0-mallin muodossa. Se kuvastaa CI-prosessimme päävaiheita. IDEF0-malleissa käytetään ns ICOM-merkintä (Input-Control-Output-Mechanism) kuvaamaan, mitä resursseja käytetään kussakin vaiheessa, minkä sääntöjen ja vaatimusten perusteella työtä tehdään, mikä on tulos ja mitkä mekanismit, palvelut tai ihmiset toteuttavat tietyn vaiheen.
Klikkaamalla kuvaa aukeaa se täysikokoisena
Pääsääntöisesti prosessien kuvaukset on helpompi hajottaa ja yksityiskohtaisesti toiminnallisissa malleissa. Mutta kun elementtien lukumäärä kasvaa, on yhä vaikeampaa ymmärtää niissä jotain. Mutta todellisessa kehityksessä on myös apuvaiheita: valvonta, tuotesertifiointi, työnkulun automatisointi ja muut. Skaalausongelman vuoksi hylkäsimme tämän kuvauksen.
Toivon syntymä
Yhdessä kirjassa törmäsimme vanhoihin Neuvostoliiton karttoihin, joissa kuvataan teknologisia prosesseja (jotka muuten ovat edelleen käytössä monissa valtion omistamissa yrityksissä ja yliopistoissa). Odota, odota, sillä meillä on myös työnkulku!.. On vaiheita, tuloksia, mittareita, vaatimuksia, indikaattoreita ja niin edelleen ja niin edelleen... Miksi et yrittäisi soveltaa vuokaavioita myös tuoteputkistoihimme? Tuli tunne: "Tässä se on! Löysimme oikean langan, on aika vetää se kunnolla!
Yksinkertaiseen taulukkoon päätimme tallentaa tuotteet sarakkeittain ja teknologiset vaiheet ja tuoteputken vaiheet riveittäin. Virstanpylväät ovat jotain suurta, kuten tuotteen rakentamisvaihe. Ja vaiheet ovat jotain pienempiä ja yksityiskohtaisempia, kuten vaihe lähdekoodin lataamisesta koontipalvelimelle tai koodin kääntämisen vaihe.
Kartan rivien ja sarakkeiden risteyksissä kirjoitamme tietyn vaiheen ja tuotteen tilat. Tilalle määritettiin joukko tiloja:
- Ei tietoa - tai sopimatonta. On tarpeen analysoida tuotteen tietyn vaiheen kysyntä. Joko analyysi on jo tehty, mutta vaihetta ei tällä hetkellä tarvita tai se ei ole taloudellisesti perusteltua.
- Siirretty - tai ei ole relevanttia tällä hetkellä. Valmisteluvaihetta tarvitaan, mutta toteutusvoimia ei ole tänä vuonna.
- Suunniteltu. Vaihe on suunniteltu toteutettavaksi tänä vuonna.
- Toteutettu. Liukulinjassa oleva vaihe toteutetaan vaaditussa tilavuudessa.
Taulukon täyttäminen aloitettiin projekti kerrallaan. Ensin luokiteltiin yhden projektin vaiheet ja vaiheet ja kirjattiin niiden tila. Sitten he ottivat seuraavan projektin, korjasivat sen tilat ja lisäsivät aiemmista projekteista puuttuvat vaiheet ja vaiheet. Tuloksena saimme koko tuotantoputkemme vaiheet ja vaiheet sekä niiden tilat tietyssä projektissa. Siitä tuli jotain samanlaista kuin tuoteputken osaamismatriisi. Kutsuimme tällaista matriisia teknologiseksi kartaksi.
Teknologiakartan avulla sovitamme metrologisesti järkevästi ryhmien kanssa yhteen vuoden työsuunnitelmat ja tavoitteet, joita haluamme yhdessä saavuttaa: mitä vaiheita lisäämme projektiin tänä vuonna ja mitkä jätämme myöhemmin. Työn aikana meillä voi myös olla parannuksia niissä vaiheissa, jotka olemme suorittaneet vain yhden tuotteen osalta. Sitten laajennamme karttaamme ja esittelemme tämän parannuksen vaiheena tai uutena vaiheena, sitten analysoimme kunkin tuotteen osalta ja selvitämme parannuksen toistamisen toteutettavuuden.
He voivat vastustaa meitä: "Tämä on tietysti hyvä, vain ajan myötä askeleiden ja vaiheiden määrä kasvaa kohtuuttoman suureksi. Kuinka olla?
Olemme ottaneet käyttöön standardinmukaiset ja melko täydelliset kuvaukset vaatimuksista jokaiselle vaiheelle ja askeleelle, jotta ne ymmärtävät kaikki yrityksessä samalla tavalla. Ajan myötä, kun parannuksia otetaan käyttöön, askel voi imeytyä toiseen vaiheeseen tai vaiheeseen, ja sitten ne "lupautuvat". Samalla kaikki vaatimukset ja tekniset vivahteet sopivat yleistysvaiheen tai -vaiheen vaatimuksiin.
Kuinka arvioida ratkaisujen replikoinnin vaikutus? Käytämme äärimmäisen yksinkertaista lähestymistapaa: laskemme uuden vaiheen käyttöönoton alkupääomakustannukset vuosittaisiksi yleisiksi tuotekustannuksiksi ja jaamme sitten kaikilla kopioitaessa.
Osa kehitystyöstä näkyy jo virstanpylväinä ja vaiheina kartalla. Voimme vaikuttaa tuotteen kustannusten alenemiseen ottamalla käyttöön tyypillisten vaiheiden automaation. Sen jälkeen otetaan huomioon muutokset laadullisissa ominaisuuksissa, kvantitatiivisissa mittareissa ja tiimien saamissa voitoissa (säästöjen henkilötunteina tai konetunteina).
Tuotantoprosessin teknologinen kartta
Jos otamme kaikki vaiheemme ja vaiheemme, koodaamme ne tunnisteilla ja laajennamme ne yhdeksi ketjuksi, se osoittautuu erittäin pitkäksi ja käsittämättömäksi (vain sama "pythonin häntä", josta puhuimme artikkelin alussa) :
[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]Nämä ovat vaiheita: tuotteiden rakentaminen [Build], niiden käyttöönotto testipalvelimille [Deploy], testaus [Test], koontiversioiden edistäminen arkistojen julkaisua varten testaustuloksiin [Promote], lisenssien luominen ja julkaiseminen [Lisenssi], julkaisu [Lisenssi] Julkaise] GUS-päivityspalvelimella ja toimitus FLUS-päivityspalvelimille, tuotekomponenttien asennus ja päivitys asiakkaan infrastruktuuriin Product Configuration Management -sovelluksella [Asenna] sekä telemetrian [Telemetria] kerääminen asennetuista tuotteista.
Niiden lisäksi voidaan erottaa erilliset vaiheet: infrastruktuurin tilan seuranta [InfMonitoring], lähdekoodin versiointi [SourceCodeControl], rakennusympäristön valmistelu [Prepare], projektinhallinta [Workflow], viestintävälineiden tarjoaminen tiimeille [Communication], tuotesertifiointi [ Sertifiointi] ja CI-prosessien omavaraisuuden varmistaminen [CISelfSuffficiency] (esimerkiksi kokoonpanojen riippumattomuus Internetistä). Kymmeniä vaiheita prosesseissamme ei edes oteta huomioon, koska ne ovat hyvin tarkkoja.
Koko tuotantoprosessi on paljon helpompi ymmärtää ja tarkastella, jos se esitetään muodossa tekninen kartta; tämä on taulukko, jossa mallin yksittäiset tuotantovaiheet ja hajautetut vaiheet on kirjoitettu riveihin ja sarakkeisiin kuvaus siitä, mitä kussakin vaiheessa tai vaiheessa tehdään. Pääpaino on kunkin vaiheen tarjoavissa resursseissa ja vastuualueiden rajaamisessa.
Kartta on meille eräänlainen luokitin. Se heijastaa tuotteiden tuotannon suuria teknisiä osia. Sen ansiosta automaatiotiimimme helpotti olla vuorovaikutuksessa kehittäjien kanssa ja suunnitella yhdessä automaatiovaiheiden toteutusta sekä ymmärtää mitä työvoimakustannuksia ja resursseja (henkilö- ja laitteisto) tarvitaan.
Yrityksemme sisällä kartta luodaan automaattisesti jinja-mallista tavallisena HTML-tiedostona ja ladataan sitten GitLab Pages -palvelimelle. Näyttökaappaus, jossa on esimerkki täysin luodusta kartasta, voidaan katsoa .
Klikkaamalla kuvaa aukeaa se täysikokoisena
Lyhyesti sanottuna teknologinen kartta on yleiskuva tuotantoprosessista, joka heijastaa selkeästi luokiteltuja lohkoja, joilla on tyypillinen toiminnallisuus.
Tiekarttamme rakenne
Kartta koostuu useista osista:
- Otsikkoalue - tässä on yleinen kuvaus kartasta, peruskäsitteet esitellään, tuotantoprosessin pääresurssit ja tulokset määritellään.
- Dashboard - täällä voit hallita yksittäisten tuotteiden tietojen näyttöä, yhteenveto toteutetuista vaiheista ja vaiheista yleensä kaikille tuotteille.
- Teknologinen kartta - taulukkomainen kuvaus teknologisesta prosessista. Kartalla:
- kaikki vaiheet, vaiheet ja niiden koodit on annettu;
- vaiheista annetaan lyhyet ja täydelliset kuvaukset;
- kussakin vaiheessa käytetyt syöttöresurssit ja palvelut ilmoitetaan;
- kunkin vaiheen ja erillisen vaiheen tulokset ilmoitetaan;
- kunkin vaiheen ja vaiheen vastuualue on merkitty;
- tekniset resurssit, kuten HDD (SSD), RAM, vCPU ja työtunnit, jotka ovat tarpeen työn tukemiseksi tässä vaiheessa, sekä tällä hetkellä - tosiasia että tulevaisuudessa - suunnitelma, on määritetty;
- Jokaisen tuotteen osalta ilmoitetaan, mitkä sen tekniset vaiheet tai vaiheet on toteutettu, suunniteltu toteutettaviksi, merkityksettömiä tai toteuttamatta jääneitä.
Päätöksenteko teknologisen kartan perusteella
Kartan tutkimisen jälkeen on mahdollista tehdä joitain toimenpiteitä - riippuen työntekijän roolista yrityksessä (kehityspäällikkö, tuotepäällikkö, kehittäjä tai testaaja):
- ymmärtää, mitä vaiheita todellisesta tuotteesta tai projektista puuttuu, ja arvioida niiden toteuttamisen tarvetta;
- rajata vastuualueet useiden osastojen välillä, jos ne toimivat eri vaiheissa;
- sopia sopimukset näyttämöjen sisään- ja uloskäynneissä;
- integroi työvaiheesi yleiseen kehitysprosessiin;
- arvioida tarkemmin kunkin vaiheen tarjoavien resurssien tarvetta.
Yhteenveto kaikesta yllä olevasta
Reititys on monipuolinen, laajennettavissa ja helppo huoltaa. On paljon helpompaa kehittää ja ylläpitää prosessikuvausta tässä muodossa kuin tiukassa akateemisessa IDEF0-mallissa. Lisäksi taulukkokuvaus on yksinkertaisempi, tutumpi ja paremmin jäsennelty kuin toiminnallinen malli.
Vaiheiden teknistä toteutusta varten meillä on erityinen sisäinen työkalu CrossBuilder - kerrostyökalu CI-järjestelmien, -palveluiden ja infrastruktuurin välillä. Kehittäjän ei tarvitse leikata pyöräänsä: CI-järjestelmässämme riittää, että suoritat yhden CrossBuilder-työkalun skripteistä (ns. tehtävä), joka suorittaa sen oikein ottaen huomioon infrastruktuurimme ominaisuudet. .
Tulokset
Artikkeli osoittautui melko pitkäksi, mutta tämä on väistämätöntä kuvattaessa monimutkaisten prosessien mallintamista. Lopuksi haluaisin lyhyesti korjata pääideamme:
- Tavoitteena DevOps-ideoiden toteuttamisessa yrityksessämme on jatkuvasti alentaa yrityksen tuotteiden tuotanto- ja ylläpitokustannuksia määrällisesti (henkilö- tai konetunnit, vCPU, RAM, Disk).
- Tapa alentaa kehittämisen kokonaiskustannuksia on minimoida tyypillisten sarjatehtävien suorittamisen kustannukset: teknologisen prosessin vaiheet ja vaiheet.
- Tyypillinen tehtävä on tehtävä, jonka ratkaisu on täysin tai osittain automatisoitu, ei aiheuta vaikeuksia suorittajille eikä vaadi merkittäviä työvoimakustannuksia.
- Tuotantoprosessi koostuu vaiheista, vaiheet on jaettu jakamattomiin vaiheisiin, jotka ovat tyypillisiä eri mittakaavaisia ja laajuisia tehtäviä.
- Erilaisista tyypillisistä tehtävistä olemme päässeet monimutkaisiin teknologisiin ketjuihin ja tuotantoprosessin monitasoisiin malleihin, jotka voidaan kuvata toimivalla IDEF0-mallilla tai yksinkertaisemmalla teknologiakartalla.
- Teknologinen kartta on taulukkoesitys tuotantoprosessin vaiheista ja vaiheista. Tärkein asia: kartan avulla voit nähdä koko prosessin kokonaisuudessaan, isoina paloina ja mahdollisuuden tarkentaa niitä.
- Teknologisen kartan perusteella voidaan arvioida vaiheiden käyttöönottoa tietyssä tuotteessa, rajata vastuualueita, sopia sopimuksista vaiheiden tuloissa ja lähdöissä sekä arvioida tarkemmin resurssien tarvetta.
Seuraavissa artikkeleissa kuvataan yksityiskohtaisemmin, mitä teknisiä työkaluja käytetään tiettyjen teknisten vaiheiden toteuttamiseen kartallamme.
Artikkelin kirjoittajat:
- — Automaatiopäällikkö (DevOps), Positive Technologies
- - Varajäsen Positive Technologiesin automaatioosaston (DevOps) johtaja
Lähde: will.com