Kurssin opiskelijoille laaditun artikkelin käännös "DevOps-käytännöt ja -työkalut" OTUS-koulutusprojektissa.

Sinun kannattaa valita yksivarasto, koska se edistää tiimeissäsi läpinäkyvyyttä ja jaettua vastuuta erityisesti tiimien kasvaessa. Joka tapauksessa sinun on investoitava työkaluihin, mutta on aina parempi, jos oletuskäyttäytyminen on komentoissasi haluamaasi toimintaa.

Miksi me puhumme tästä?

Matt Klein kirjoitti artikkelin "Monorepos: Älä tee!"  (Kääntäjän huomautus: Habrén käännös "Yksivarastot: älä"). Pidän Mattista, mielestäni hän on erittäin älykäs ja sinun pitäisi lukea hänen näkökulmansa. Hän julkaisi kyselyn alun perin Twitterissä:

Käännös:
Tänä uudenvuodenpäivänä aion kiistellä siitä, kuinka naurettavia monoarkistot ovat. 2019 alkoi rauhallisesti. Tämän hengessä tarjoan sinulle kyselyn. Ketkä ovat suuria fanaatikkoja? Tukijat:
- Monorepo
- Ruoste
- Väärä kysely / molemmat

Vastaukseni oli: "Olen kirjaimellisesti molempia noita ihmisiä." Sen sijaan, että puhuisit siitä, kuinka Rust on huume, katsotaanpa, miksi hän on mielestäni väärässä monoarkistoissa. Hieman itsestäsi. Olen Chef Softwaren teknologiajohtaja. Meillä on noin 100 insinööriä, koodikanta noin 11-12 vuoden takaa ja 4 päätuotetta. Osa tästä koodista on monivarastossa (aloitusasemani), osa monovarastossa (nykyinen asemani).

Ennen kuin aloitan: jokainen tässä esittämäni argumentti koskee molempia arkistoita. Mielestäni ei ole mitään teknistä syytä, miksi sinun pitäisi valita yhden tyyppinen arkisto toisen sijaan. Voit saada minkä tahansa lähestymistavan toimimaan. Puhun siitä mielelläni, mutta en ole kiinnostunut keinotekoisista teknisistä syistä, miksi yksi on parempi kuin toinen.

Olen samaa mieltä Mattin ensimmäisen osan kanssa:

Koska mittakaavassa yksivarasto ratkaisee kaikki samat ongelmat, jotka monivarasto ratkaisee, mutta samalla pakottaa sinut yhdistämään koodisi tiukasti ja vaatii uskomattomia ponnisteluja versionhallintajärjestelmän skaalautuvuuden lisäämiseksi.

Sinun on ratkaistava samat ongelmat riippumatta siitä, valitsetko monoarkiston vai monivaraston. Miten julkaiset julkaisuja? Mikä on lähestymistapasi päivityksiin? Taaksepäin yhteensopivuus? Projektien väliset riippuvuudet? Mitkä arkkitehtoniset tyylit ovat hyväksyttäviä? Kuinka hallitset rakentamis- ja testausinfrastruktuuriasi? Lista on loputon. Ja ratkaiset ne kaikki kasvaessasi. Ilmaista juustoa ei ole olemassa.

Luulen, että Mattin argumentti on samanlainen kuin monet insinöörit (ja johtajat), joita kunnioitan. Tämä tapahtuu komponentin parissa työskentelevän insinöörin tai komponentin parissa työskentelevän tiimin näkökulmasta. Kuulet asioita, kuten:

• Koodikanta on kookas - en tarvitse kaikkea tätä roskaa.
• Sitä on vaikeampi testata, koska minun on testattava kaikki tämä roska, jota en tarvitse.
• Ulkoisten riippuvuuksien kanssa työskentely on vaikeampaa.
• Tarvitsen oman virtuaalisen versionhallintajärjestelmän.

Tietenkin kaikki nämä kohdat ovat perusteltuja. Näin tapahtuu molemmissa tapauksissa - monivarastossa minulla on omaa roskaa, rakentamiseen tarvittavan lisäksi... Saatan tarvita myös muuta roskaa. Joten "yksinkertaisesti" luon työkaluja, jotka tarkistavat koko projektin. Tai luon väärennetyn monoarkiston alimoduuleilla. Voisimme kävellä tämän ympärillä koko päivän. Mutta mielestäni Mattin argumentti jättää huomiotta pääsyyn, jonka käänsin melko voimakkaasti monoarkiston hyväksi:

Se provosoi kommunikaatiota ja näyttää ongelmia

Kun erottelemme arkistot, luomme de facto koordinointi- ja avoimuusongelman. Tämä vastaa tapaamme ajatella tiimeistä (etenkin tapaa, jolla yksittäiset jäsenet ajattelevat niistä): olemme vastuussa tietystä komponentista. Työskentelemme suhteellisen eristyksissä. Rajat ovat kiinteät tiimilleni ja komponenteille, joiden parissa työskentelemme.

Kun arkkitehtuuri muuttuu monimutkaisemmaksi, yksi tiimi ei voi enää hallita sitä yksin. Hyvin harvoilla insinööreillä on koko järjestelmä päässään. Oletetaan, että hallitset jaettua komponenttia A, jota tiimit B, C ja D käyttävät. Tiimi A muokkaa, parantaa API:ta ja muuttaa myös sisäistä toteutusta. Tämän seurauksena muutokset eivät ole yhteensopivia taaksepäin. Mitä neuvoja sinulla on?

• Etsi kaikki paikat, joissa vanhaa APIa käytetään.
• Onko paikkoja, joissa uutta APIa ei voi käyttää?
• Voitko korjata ja testata muita osia varmistaaksesi, etteivät ne hajoa?
• Voivatko nämä tiimit testata muutoksiasi juuri nyt?

Huomaa, että nämä kysymykset ovat riippumattomia arkiston tyypistä. Sinun on löydettävä joukkueet B, C ja D. Sinun on puhuttava heille, selvitettävä aika, ymmärrettävä heidän prioriteettinsa. Toivomme ainakin sinun.

Kukaan ei todellakaan halua tehdä tätä. Tämä on paljon vähemmän hauskaa kuin vain pirun APIn korjaaminen. Kaikki on inhimillistä ja sotkuista. Monivarastossa voit yksinkertaisesti tehdä muutoksia, antaa sen kyseisen komponentin parissa työskenteleville henkilöille (todennäköisesti ei B, C tai D) tarkistettavaksi ja jatkaa eteenpäin. Joukkueet B, C ja D voivat vain pysyä nykyisessä versiossaan. Ne uusiutuvat, kun he ymmärtävät neroksesi!

Yksinkertaisessa arkistossa vastuu siirtyy oletusarvoisesti. Joukkue A vaihtaa komponenttiaan ja, jos ei ole varovainen, rikkoo välittömästi B:n, C:n ja D:n. Tämä johtaa siihen, että B, C ja D ilmestyvät A:n ovelle ihmetellen, miksi joukkue A rikkoi kokoonpanon. Tämä opettaa A:lle, että he eivät voi ohittaa yllä olevaa luetteloani. Heidän täytyy puhua siitä, mitä he aikovat tehdä. Voivatko B, C ja D liikkua? Entä jos B ja C voivat, mutta D liittyy läheisesti vanhan algoritmin toiminnan sivuvaikutukseen?

Sitten meidän on puhuttava siitä, kuinka tästä tilanteesta selvitään:

1. Tuki useille sisäisille API:lle ja merkitsee vanhan algoritmin vanhentuneeksi, kunnes D voi lopettaa sen käytön.
2. Tuki useille julkaisuversioille, joista toisessa on vanha käyttöliittymä ja toisessa uusi.
3. Viivytä A:n muutosten julkaisemista, kunnes B, C ja D voivat hyväksyä sen samanaikaisesti.

Oletetaan, että olemme valinneet yhden, useita sovellusliittymiä. Tässä tapauksessa meillä on kaksi koodia. Vanha ja uusi. Varsin kätevä joissain tilanteissa. Tarkistamme vanhan koodin takaisin, merkitsemme sen vanhentuneeksi ja sovimme poistoaikataulun D-tiimin kanssa. Pohjimmiltaan identtinen poly- ja mono-arkistoissa.

Jotta voimme julkaista useita versioita, tarvitsemme haaran. Nyt meillä on kaksi komponenttia - A1 ja A2. Joukkueet B ja C käyttävät A2:ta ja D käyttävät A1:tä. Kaikkien komponenttien on oltava valmiita julkaisuun, koska tietoturvapäivityksiä ja muita virheenkorjauksia voidaan tarvita ennen kuin D voi siirtyä eteenpäin. Monivarastossa voimme piilottaa tämän pitkäikäiseen oksaan, joka tuntuu hyvältä. Yksivarastossa pakotamme koodin luomaan uudessa moduulissa. Joukkueen D on silti tehtävä muutoksia "vanhaan" komponenttiin. Kaikki näkevät täällä maksamamme kustannukset – meillä on nyt kaksi kertaa enemmän koodia, ja A1:tä ja A2:ta koskevien virheenkorjausten on koskettava molempia. Haaroittumismenetelmällä monivarastossa tämä on piilotettu kirsikkapoimin taakse. Pidämme kustannuksia alhaisempana, koska päällekkäisyyttä ei ole. Käytännön näkökulmasta hinta on sama: rakennat, julkaiset ja ylläpidät kahta suurelta osin identtistä koodikantaa, kunnes voit poistaa niistä yhden. Erona on, että yksivarastossa tämä kipu on suoraa ja näkyvää. Tämä on vielä pahempaa, ja se on hyvä.

Lopulta päästiin kolmanteen pisteeseen. Julkaisun viive. On mahdollista, että A:n tekemät muutokset parantavat joukkueen A elämää. Tärkeää, mutta ei kiireellistä. Voimmeko vain viivyttää? Monivarastossa painamme tätä kiinnittääksemme artefaktin. Tietenkin kerromme tämän tiimille D. Pysy vain vanhassa versiossa, kunnes saat kiinni! Tämä saa sinut pelaamaan pelkuria. Tiimi A jatkaa työskentelyä komponenttinsa parissa jättäen huomiotta sen tosiasian, että Team D käyttää yhä vanhentuneempaa versiota (se on joukkueen D ongelma, he ovat tyhmiä). Sillä välin joukkue D puhuu huonosti Joukkueen A huolimattomasta asenteesta koodin vakauteen, jos he puhuvat siitä ollenkaan. Kuukaudet kuluvat. Lopulta joukkue D päättää tarkastella päivitysmahdollisuutta, mutta A:lla on vain lisää muutoksia. Joukkue A tuskin muistaa milloin tai miten he rikkoivat D:n. Päivitys on tuskallisempaa ja kestää kauemmin. Mikä siirtää sen alemmas prioriteettipinossa. Siihen päivään asti, kun A:ssa on tietoturvaongelma, joka pakottaa meidät luomaan haaran. Joukkueen A täytyy palata ajassa taaksepäin, löytää piste, jolloin D oli vakaa, korjata ongelma siellä ja valmistaa se julkaisuun. Tämä on ihmisten tosiasiallinen valinta, ja se on ylivoimaisesti pahin. Se näyttää olevan hyvä sekä joukkueelle A että joukkueelle D, kunhan voimme sivuuttaa toisiamme.

Yksivarastossa kolmas ei todellakaan ole vaihtoehto. Sinun on pakko käsitellä tilannetta kahdella tavalla. Sinun on nähtävä kahden julkaisuhaaran kustannukset. Opi suojautumaan päivityksiltä, ​​jotka rikkovat taaksepäin yhteensopivuuden. Mutta mikä tärkeintä: et voi välttää vaikeaa keskustelua.

Kokemukseni mukaan kun joukkueet kasvavat isoiksi, koko järjestelmää ei ole enää mahdollista pitää mielessä, ja se on tärkein osa. Sinun on parannettava erimielisyyksien näkyvyyttä järjestelmässä. Sinun on työskenneltävä aktiivisesti saadaksesi tiimit katsomaan pois komponenteistaan ​​ja katsomaan muiden tiimien ja kuluttajien työtä.

Kyllä, voit luoda työkaluja, jotka yrittävät ratkaista monivarasto-ongelman. Mutta kokemukseni jatkuvan toimituksen ja automaation opettamisesta suurissa yrityksissä kertoo minulle tämän: oletuskäyttäytyminen ilman lisätyökalujen käyttöä on käyttäytymistä, jota odotat näkeväsi. Monivaraston oletuskäyttäytyminen on eristäminen, se on koko pointti. Yksivaraston oletuskäyttäytyminen on jaettua vastuuta ja läpinäkyvyyttä, se on koko pointti. Molemmissa tapauksissa aion luoda työkalun, joka tasoittaa karkeat reunat. Johtajana valitsen joka kerta monoarkiston, koska työkalujen täytyy vahvistaa haluamaani kulttuuria ja kulttuuri syntyy pienistä päätöksistä ja tiimin päivittäisestä työstä.

Vain rekisteröityneet käyttäjät voivat osallistua kyselyyn. Kirjaudu sisään, ole kiltti.

Ketkä ovat suurimpia fanaatikkoja? Tukijat:

• Monorepo

• Ruoste

• Väärä kysely / molemmat

33 käyttäjää äänesti. 13 käyttäjää pidättyi äänestämästä.

Lähde: will.com