Oersetting fan it artikel taret foar kursusstudinten yn it OTUS edukatyf projekt.
Jo moatte in monorepository kieze, om't it gedrach dat it befoarderet yn jo teams transparânsje en dielde ferantwurdlikens is, foaral as teams groeie. Hoe dan ek, jo moatte ynvestearje yn ark, mar it is altyd better as it standertgedrach it gedrach is dat jo wolle yn jo kommando's.
Wêrom hawwe wy it oer dit?
Matt Klein skreau it artikel (oersetternotysje: oersetting op Habré ). Ik hâld fan Matt, ik tink dat hy heul tûk is en jo moatte syn eachpunt lêze. Hy pleatste de poll oarspronklik op Twitter:
Oersetting:
Dizze Nijjiersdei sil ik stride oer hoe bespotlik monorepositories binne. 2019 begûn rêstich. Yn 'e geast hjirfan bied ik jo in enkête oan. Wa binne de grutte fanatyk? Supporters:
- Monorepo
- Rust
- Ferkearde poll / beide
Myn antwurd wie: "Ik bin letterlik beide minsken." Yn stee fan te praten oer hoe't Rust in drug is, litte wy sjen wêrom't ik tink dat hy ferkeard is oer monorepositories. In bytsje oer dysels. Ik bin de CTO fan Chef Software. Wy hawwe sawat 100 yngenieurs, in koadebasis dy't sawat 11-12 jier werom giet, en 4 haadprodukten. Guon fan dizze koade is yn in polyrepository (myn startposysje), guon is yn in monorepository (myn hjoeddeistige posysje).
Foardat ik begjin: elk argumint dat ik hjir meitsje sil jilde foar beide soarten repositories. Yn myn miening is d'r gjin technyske reden wêrom't jo ien type repository moatte kieze oer in oar. Jo kinne elke oanpak wurkje. Ik bin bliid om te praten oer it, mar ik bin net ynteressearre yn keunstmjittige technyske redenen wêrom't ien is superieur oan in oar.
Ik bin it iens mei it earste diel fan Matt syn punt:
Want op skaal sil in monorepository alle deselde problemen oplosse dy't in polyrepository oplost, mar jo tagelyk twinge om jo koade strak te koppelen en ongelooflijke ynspanningen nedich om de skalberens fan jo ferzjekontrôlesysteem te fergrutsjen.
Jo sille deselde problemen moatte oplosse, nettsjinsteande of jo in monorepository of in polyrepository kieze. Hoe meitsje jo releases frij? Wat is jo oanpak foar updates? Efterút kompatibiliteit? Cross projekt ôfhinklikens? Hokker arsjitektoanyske stilen binne akseptabel? Hoe beheare jo jo bouw- en testynfrastruktuer? De list is einleaze. En jo sille se allegear oplosse as jo groeie. Der is gjin frije tsiis.
Ik tink dat Matt syn argumint is gelyk oan views dield troch in protte yngenieurs (en managers) Ik respektearje. Dit bart út it perspektyf fan 'e yngenieur dy't oan 'e komponint wurket as it team dat oan 'e komponint wurket. Jo hearre dingen lykas:
- De koadebase is bulk - ik haw al dizze rommel net nedich.
- It is dreger om te testen, om't ik al dizze rommel moat testen dy't ik net nedich is.
- It is dreger om te wurkjen mei eksterne ôfhinklikens.
- Ik haw myn eigen firtuele ferzjekontrôlesystemen nedich.
Fansels binne al dizze punten terjochte. Dit bart yn beide gefallen - yn 'e polyrepository haw ik myn eigen junk, neist de ien dy't nedich is foar it bouwen ... Ik kin ek oare junk nedich wêze. Dat ik meitsje "gewoan" ark dy't it heule projekt kontrolearje. Of ik meitsje in falsk monorepository mei submodules. Wy koene hjir de hiele dei om rinne. Mar ik tink dat it argumint fan Matt de wichtichste reden mist, dy't ik frij swier omdraaide foar it monorepository:
It provosearret kommunikaasje en lit problemen sjen
As wy repositories skiede, meitsje wy in de facto probleem fan koördinaasje en transparânsje. Dit komt oerien mei de manier wêrop wy tinke oer teams (benammen de manier wêrop yndividuele leden oer harren tinke): wy binne ferantwurdlik foar in bepaald ûnderdiel. Wy wurkje yn relatyf isolemint. De grinzen steane fêst op myn team en de komponint(en) dêr't wy oan wurkje.
As arsjitektuer komplekser wurdt, kin ien team it net mear allinich beheare. Hiel pear yngenieurs hawwe it hiele systeem yn har holle. Litte wy sizze dat jo in dielde komponint A beheare dy't brûkt wurdt troch Teams B, C en D. Team A refaktorearret, ferbetteret de API, en feroaret ek de ynterne ymplemintaasje. As gefolch binne de wizigingen net efterút kompatibel. Hokker advys hawwe jo?
- Fine alle plakken dêr't de âlde API wurdt brûkt.
- Binne d'r plakken wêr't de nije API net brûkt wurde kin?
- Kinne jo oare komponinten reparearje en testen om te soargjen dat se net brekke?
- Kinne dizze teams jo wizigingen no direkt testen?
Tink derom dat dizze fragen ûnôfhinklik binne fan it type repository. Jo moatte teams B, C en D fine. Jo moatte mei har prate, de tiid fine, har prioriteiten begripe. Wy hoopje teminsten dat jo sille.
Nimmen wol dit echt dwaan. Dit is in stik minder leuk dan gewoan de ferrekte API reparearje. It is allegear minsklik en rommelich. Yn in polyrepository kinne jo gewoan wizigingen meitsje, it jaan oan de minsken dy't wurkje oan dat komponint (wierskynlik net B, C of D) foar resinsje, en trochgean. Teams B, C en D kinne foar no gewoan bliuwe by harren hjoeddeistige ferzje. Se sille wurde fernijd as se realisearje jo sjeny!
Yn in monorepository wurdt ferantwurding standert ferpleatst. Ploech A feroaret har komponint en brekt, as net foarsichtich, fuortendaliks B, C en D. Dit liedt ta B, C en D dy't by A's doar ferskine, en freegje har ôf wêrom't Ploech A de gearkomste bruts. Dit leart A dat se myn list hjirboppe net kinne oerslaan. Se moatte prate oer wat se sille dwaan. Kin B, C en D bewegen? Wat as B en C kinne, mar D wie nau besibbe oan in side-effekt fan it gedrach fan it âlde algoritme?
Dan moatte wy prate oer hoe't wy út dizze situaasje komme:
- Stipe foar meardere ynterne API's, en sil it âlde algoritme markearje as ôfkard oant D it kin stopje mei it brûken.
- Stipe foar meardere release ferzjes, ien mei de âlde ynterface, ien mei de nije.
- Fertrage de frijlitting fan feroaringen fan A oant B, C en D it tagelyk kinne akseptearje.
Litte wy sizze dat wy 1 hawwe selektearre, ferskate API's. Yn dit gefal hawwe wy twa stikken koade. Ald en nij. Hiel handich yn guon situaasjes. Wy kontrolearje de âlde koade wer yn, markearje it as ferâldere, en iens oer in fuortheljen skema mei it team D. Yn wêzen identyk foar poly en mono repositories.
Om meardere ferzjes frij te litten, hawwe wy in branch nedich. No hawwe wy twa komponinten - A1 en A2. Teams B en C brûke A2 en D brûkt A1. Wy hawwe elke komponint nedich om klear te wêzen foar frijlitting, om't befeiligingsupdates en oare bugfixes nedich binne foardat D foarút kin. Yn in polyrepository kinne wy dit ferbergje yn in lange libbene tûke dy't goed fielt. Yn in monorepository twinge wy de koade om te meitsjen yn in nije module. Ploech D sil noch feroarings oanbringe moatte yn it "âlde" ûnderdiel. Elkenien kin de kosten sjen dy't wy hjir betelje - wy hawwe no twa kear safolle koade, en alle bugfixes dy't fan tapassing binne op A1 en A2 moatte jilde foar beide. Mei de fertakkende oanpak yn in polyrepository is dit ferburgen efter cherry-pick. Wy beskôgje de kosten as leger omdat der gjin duplikaasje is. Fanút in praktysk eachpunt binne de kosten itselde: jo sille twa foar it grutste part identike koadebases bouwe, frijlitte en ûnderhâlde oant jo ien fan har kinne wiskje. It ferskil is dat mei in monorepository dizze pine direkt en sichtber is. Dit is noch slimmer, en dat is goed.
Uteinlik kamen wy by it tredde punt. Release fertraging. It is mooglik dat feroarings makke troch A sille ferbetterje it libben fan Team A. Wichtich, mar net driuwend. Kinne wy gewoan fertrage? Yn in polyrepository drukke wy dit om it artefakt te pinjen. Fansels fertelle wy dit oan Team D. Bliuw gewoan op 'e âlde ferzje oant jo it ynhelje! Dit stelt jo op om de leffe te spyljen. Team A bliuwt te wurkjen oan har komponint, negearje it feit dat Team D in hieltyd ferâldere ferzje brûkt (dat is it probleem fan Team D, se binne dom). Underwilens praat Team D min oer de achtleaze hâlding fan Team A oangeande koadestabiliteit, as se der überhaupt oer prate. Moannen passe. Uteinlik beslút Team D om te sjen nei de mooglikheid om te aktualisearjen, mar A hat allinich mear feroarings. Team A herinnert amper wannear of hoe't se bruts D. De fernijing is pynliker en sil langer duorje. Wat stjoert it fierder del de prioriteit stack. Oant de dei dat wy in feiligensprobleem hawwe yn A dy't ús twingt om in tûke te meitsjen. Team A moat werom yn 'e tiid, fine in punt doe't D wie stabyl, reparearje it probleem dêr, en meitsje it klear foar frijlitting. Dit is de de facto kar dy't minsken meitsje, en it is fierwei it minste. It liket goed te wêzen foar sawol Team A as Team D, salang't wy inoar negearje kinne.
Yn in monorepository is de tredde echt gjin opsje. Jo wurde twongen om te gean mei de situaasje op ien fan twa manieren. Jo moatte de kosten sjen foar it hawwen fan twa frijlittingstûken. Learje josels te beskermjen tsjin updates dy't efterútkompatibiliteit brekke. Mar it wichtichste: jo kinne net foarkomme dat jo in dreech petear hawwe.
Yn myn ûnderfining, as teams wurde grut, is it net mear mooglik om te hâlden it hiele systeem yn gedachten, en dat is it wichtichste part. Jo moatte de sichtberens fan ûnfrede yn it systeem ferbetterje. Jo moatte aktyf wurkje om teams te krijen om fuort te sjen fan har komponinten en te sjen nei it wurk fan oare teams en konsuminten.
Ja, jo kinne ark meitsje dy't besykje it probleem fan polyrepository op te lossen. Mar myn ûnderfining ûnderwizen fan trochgeande levering en automatisearring yn grutte bedriuwen fertelt my dit: it standertgedrach sûnder it brûken fan ekstra ark is it gedrach dat jo ferwachtsje te sjen. It standertgedrach fan in polyrepository is isolaasje, dat is it hiele punt. It standertgedrach fan in monorepository is dielde ferantwurdlikens en transparânsje, dat is it hiele punt. Yn beide gefallen sil ik in ark meitsje dat de rûge rânen soepelje sil. As lieder sil ik elke kear in monorepository kieze, om't de ark nedich is om de kultuer te fersterkjen dy't ik wol, en kultuer komt fan lytse besluten en it deistich wurk fan it team.
Allinnich registrearre brûkers kinne meidwaan oan 'e enkête. , asjebleaft.
Wa binne de grutste fanatyk? Supporters:
-
Monorepo
-
Rust
-
Ferkearde poll / beide
33 brûkers stimden. 13 brûkers ûntholden har.
Boarne: www.habr.com