Monorepos ir aktuāla diskusiju tēma. Nesen bija daudz rakstu par to, kāpēc jums vajadzētu un nevajadzētu izmantot šāda veida arhitektūru savam projektam, taču lielākā daļa no tiem vienā vai otrā veidā ir tendenciozi. Šī sērija ir mēģinājums apkopot un izskaidrot pēc iespējas vairāk informācijas, lai saprastu, kā un kad lietot monorepos.

TO Monorepository ir arhitektūras jēdziens, kura būtībā satur visu nozīmi tā nosaukumā. Tā vietā, lai pārvaldītu vairākus krātuves, visas savas izolētās koda daļas jūs glabājat vienā krātuvē. Paturiet prātā vārdu izolēts - tas nozīmē, ka monorepo nav nekā kopīga ar monolītām lietotnēm. Vienā repo varat saglabāt daudzu veidu loģiskas lietotnes; piemēram, vietne un tās iOS lietotne.

kā lietot apache dzirksti

Šī koncepcija ir samērā veca un parādījās apmēram pirms desmit gadiem. Google bija viens no pirmajiem uzņēmumiem, kas izmantoja šo pieeju savu koda bāzes pārvaldībai. Jūs varat jautāt, ja tā pastāv jau desmit gadus, tad kāpēc tā ir tik aktuāla tēma tikai tagad? Pārsvarā pēdējo 5-6 gadu laikā daudzas lietas ir piedzīvojušas dramatiskas izmaiņas. ES6, SCSS priekšapstrādātāji, uzdevumu pārvaldnieki, npm utt. Mūsdienās, lai uzturētu nelielu uz React balstītu lietotni, jums jātiek galā ar projektu paketēm, testa komplektiem, CI / CD skriptiem, Docker konfigurācijām un kas vēl zina. Un tagad iedomājieties, ka nelielas lietotnes vietā jums ir jāuztur milzīga platforma, kas sastāv no daudzām funkcionālām zonām. Ja domājat par arhitektūru, jūs vēlaties darīt divas galvenās lietas: nodalīt bažas un izvairīties no koda krāpšanās.

Lai tas notiktu, jūs, iespējams, vēlēsities atsevišķās paketēs izolēt lielas funkcijas un pēc tam tos izmantot, izmantojot vienu ieejas punktu galvenajā lietotnē. Bet kā jūs pārvaldāt šīs paketes? Katrai pakotnei būs jābūt savai darbplūsmas vides konfigurācijai, un tas nozīmē, ka katru reizi, kad vēlaties izveidot jaunu pakotni, jums būs jākonfigurē jauna vide, jāpārkopē visi konfigurācijas faili utt. Vai, piemēram, ja jums kaut kas jāmaina būvēšanas sistēmā, jums būs jāpārskata katrs repo, jāveic saistības, jāizveido pieprasījums un jāgaida katra būvēšana, kas jūs ļoti palēnina. Šajā solī mēs tiekamies ar monorepos.

Tā vietā, lai mums būtu daudz krātuvju ar savām konfigurācijām, mums būs tikai viens patiesības avots - monorepo: viens testa komplekta skrējējs, viens Docker konfigurācijas fails un viena Webpack konfigurācija. Un jums joprojām ir mērogojamība, iespēja nodalīt problēmas, kodu koplietošana ar kopīgām pakotnēm un daudz citu plusi. Izklausās jauki, vai ne? Nu tā ir. Bet ir arī daži trūkumi. Apskatīsim cieši monorepo izmantošanas savvaļā precīzos plusus un mīnusus.

Monorepo priekšrocības:

• Viena vieta visu konfigurāciju un testu glabāšanai. Tā kā viss atrodas vienā repo, jūs varat vienreiz konfigurēt savu CI / CD un paketi un pēc tam vienkārši atkārtoti izmantot konfigurācijas, lai izveidotu visas paketes, pirms tās publicējat tālvadībā. Tas pats attiecas arī uz vienības, e2e un integrācijas testiem - jūsu CI varēs sākt visus testus bez papildu konfigurācijas.
• Viegli pārveidojiet globālās funkcijas ar atomu saistībām. Tā vietā, lai veiktu pieprasījumu par katru repo, noskaidrojot, kādā secībā veikt izmaiņas, jums vienkārši jāveic atomu pieprasījums, kurā būs visas saistības, kas saistītas ar funkciju, pret kuru strādājat.
• Vienkāršota paku publicēšana. Ja plānojat paketē ieviest jaunu funkciju, kas ir atkarīga no citas paketes ar koplietojamu kodu, to varat izdarīt ar vienu komandu. Tā ir funkcija, kurai nepieciešamas dažas papildu konfigurācijas, kuras vēlāk tiks apskatītas šī raksta pārskatīšanas daļā. Pašlaik ir pieejams plašs rīku klāsts, tostarp Lerna, Dzijas darbvietas un Bazel.
• Vienkāršāka atkarības pārvaldība. Tikai viens pakete.json . Katrā repo nav nepieciešams atkārtoti instalēt atkarības, kad vēlaties atjaunināt savas atkarības.
• Atkārtoti izmantojiet kodu ar koplietotām pakotnēm, vienlaikus saglabājot tās izolētas. Monorepo ļauj atkārtoti izmantot citu pakešu pakas, vienlaikus saglabājot tās izolētas viena no otras. Varat izmantot atsauci uz attālo paketi un patērēt tos, izmantojot vienu ieejas punktu. Lai izmantotu vietējo versiju, varat izmantot vietējās saites. Šo funkciju var ieviest, izmantojot bash skriptus vai ieviešot dažus papildu rīkus, piemēram, Lerna vai Yarn.

Monorepo trūkumi:

• Nekādā veidā nevar ierobežot piekļuvi tikai dažām lietotnes daļām. Diemžēl jūs nevarat koplietot tikai daļu no sava monorepo - jums būs jāpiešķir piekļuve visai koda bāzei, kas var izraisīt dažas drošības problēmas.

• Slikta Git veiktspēja, strādājot pie liela mēroga projektiem. Šis jautājums sāk parādīties tikai vietnē milzīgs lietojumprogrammas ar vairāk nekā miljonu saistību un simtiem izstrādātāju, kas katru dienu veic savu darbu vienlaikus vienā repo. Tas kļūst īpaši apgrūtinoši, jo Gits projekta vēstures atspoguļošanai izmanto virzītu aciklisko grafiku (DAG). Ar lielu skaitu saistību vēsturei padziļinoties, jebkura komanda, kas iet pa diagrammu, var kļūt lēna. Veiktspēja palēninās arī atsauču skaita (t.i., zaru vai tagu dēļ, kas atrisināmi, noņemot vairs nevajadzīgus atsauces) un izsekoto failu daudzuma (kā arī to svara) dēļ, kaut arī lielu failu problēmu var atrisināt Iet LFS ).

  Piezīme: Mūsdienās Facebook mēģina atrisināt problēmas ar VCS mērogojamību lāpot Mercurial un, iespējams, drīz tas nebūs tik liels jautājums.

• Lielāks būvēšanas laiks. Tā kā jums būs daudz avota kodu vienuviet, būs nepieciešams vairāk laika, lai jūsu CI visu palaistu, lai apstiprinātu katru PR.

Rīka pārskats

Instrumentu komplekts monorepos pārvaldīšanai nepārtraukti pieaug, un pašlaik ir ļoti viegli pazust visās monorepos celtniecības sistēmās. Izmantojot, jūs vienmēr varat būt informēts par populāriem risinājumiem šis repo . Bet tagad apskatīsim rīkus, kas mūsdienās tiek izmantoti ar JavaScript:

• Bāzelē ir Google monorepo orientēta veidošanas sistēma. Vairāk par Bazel: super-bazel
• Dzija ir JavaScript atkarības pārvaldības rīks, kas atbalsta monorepos, izmantojot darbvietas.
• Uzziniet ir rīks, lai pārvaldītu JavaScript projektus ar vairākām paketēm, kas veidots uz Dzijas.

Lielākajā daļā rīku tiek izmantota patiešām līdzīga pieeja, taču ir dažas nianses.

Mēs iegremdēsimies dziļāk Lerna darbplūsmā, kā arī citos šī raksta 2. daļas rīkos, jo tā ir diezgan liela tēma. Pagaidām tikai iegūstam pārskatu par to, kas ir iekšā:

Uzziniet

Šis rīks patiešām palīdz, strādājot ar semantiskām versijām, izveidojot darbplūsmu, virzot paketes utt. Lerna galvenā ideja ir tā, ka jūsu projektam ir pakotņu mape, kurā ir visas jūsu izolētās koda daļas. Bez paketēm jums ir galvenā lietotne, kas, piemēram, var dzīvot mapē src. Gandrīz visas Lerna operācijas darbojas, izmantojot vienkāršu kārtulu - jūs atkārtojat visas paketes un veicat dažas darbības, piemēram, palieliniet pakotnes versiju, atjauniniet visu paku atkarību, izveidojiet visas paketes utt.

Izmantojot Lerna, jums ir divas iespējas, kā izmantot paketes:

1. Nenospiežot tos uz tālvadības pulti (NPM)
2. Paku virzīšana uz tālvadības pulti

Izmantojot pirmo pieeju, jūs varat izmantot vietējās atsauces saviem pakotnēm un būtībā neuztraucas par saitēm, lai tās atrisinātu.

Bet, ja izmantojat otro pieeju, jūs esat spiests importēt paketes no tālvadības. (piemēram, import { something } from @yourcompanyname/packagename;), kas nozīmē, ka jūs vienmēr saņemsit paketes attālo versiju. Vietējai attīstībai jums mapes saknē būs jāizveido saites, lai pakete atrisinātu vietējās paketes, nevis izmantotu tās, kas atrodas jūsu node_modules/ Tāpēc pirms Webpack vai iecienītākā komplektētāja palaišanas jums būs jāpalaiž lerna bootstrap , kas automātiski saistīs visas paketes.

Dzija

Sākotnēji dzija ir NPM pakotņu atkarības pārvaldnieks, kas sākotnēji netika veidots, lai atbalstītu monorepos. Bet versijā 1.0 Dzijas izstrādātāji izlaida funkciju ar nosaukumu Darbvietas . Izlaišanas laikā tas nebija tik stabils, bet pēc kāda laika tas kļuva izmantojams ražošanas projektiem.

Darbvieta būtībā ir pakete, kurai ir savs pakete.json un tiem var būt daži īpaši veidošanas noteikumi (piemēram, atsevišķs tsconfig.json ja projektos izmantojat TypeScript.). Jūs faktiski kaut kā varat pārvaldīt bez dzijas darbvietām, izmantojot bash, un jums ir tieši tāda pati iestatīšana, taču šis rīks palīdz atvieglot paketes atkarību instalēšanas un atjaunināšanas procesu.

Īsumā, dzija ar savām darbvietām nodrošina šādas noderīgas funkcijas:

1. Viens node_modules mapē visu pakotņu saknē. Piemēram, ja jums ir packages/package_a un packages/package_b - ar saviem package.json - visas atkarības tiks instalētas tikai saknē. Tā ir viena no atšķirībām starp to, kā darbojas Dzija un Lerna.
2. Atkarības simlinkēšana, lai vietējā pakotne varētu attīstīties.
3. Viena bloķēšanas fails visām atkarībām.
4. Mērķtiecīgs atkarības atjauninājums gadījumā, ja vēlaties atkārtoti instalēt atkarības tikai vienai pakotnei. To var izdarīt, izmantojot -focus karogu.
5. Integrācija ar Lerna. Jūs varat viegli likt dzijai apstrādāt visu instalēšanu / saistīšanu un ļaut Lerna rūpēties par publicēšanu un versiju kontroli. Šī ir pagaidām vispopulārākā iestatīšana, jo tā prasa mazāk pūļu un ar to ir viegli strādāt.

Noderīgas saites:

• Dzijas darbvietas
• Kā izveidot TypeScript mono-repo projektu

Bāzelē

Bazel ir veidošanas rīks liela mēroga lietojumprogrammām, kas var apstrādāt atkarības no vairākām valodām un atbalstīt daudzas mūsdienu valodas (Java, JS, Go, C ++ utt.). Vairumā gadījumu Bazel izmantošana maziem un vidējiem JS lietojumiem ir pārspīlēta, taču lielā mērā tā veiktspējas dēļ var dot daudz labumu.

iekļaut galvenes failu c ++

Pēc savas būtības Bazel izskatās līdzīgi Make, Gradle, Maven un citiem rīkiem, kas ļauj veidot projektus, pamatojoties uz failu, kurā ir būvniecības noteikumu un projekta atkarību apraksts. Tiek izsaukts tas pats fails Bazelē BŪVĒT un atrodas Bazel projekta darba telpā. The BŪVĒT fails to izmanto Starlark , cilvēkiem lasāma, augsta līmeņa būvvaloda, kas līdzinās Python.

Parasti ar jums daudz nenodarbosies BŪVĒT jo ir daudz katlu, kurus var viegli atrast tīmeklī un kuri jau ir konfigurēti un gatavi izstrādei. Ikreiz, kad vēlaties veidot savu projektu, Bazel būtībā rīkojas šādi:

1. Slodzes BŪVĒT faili, kas attiecas uz mērķi.
2. Analīzes ievadi un to atkarības , piemēro norādītos veidošanas noteikumus un izveido darbība grafiks.
3. Izpilda būvēšanas darbības uz izejvielām, līdz tiek izveidoti galīgie būvniecības rezultāti.

Noderīgas saites:

• JavaScript un Bazel - Dokumenti Bazel projekta izveidošanai JS no jauna.
• Bazel JavaScript un TypeScript noteikumi - JS katls.

Secinājums

Monorepos ir tikai instruments. Ir daudz argumentu par to, vai tam ir nākotne, vai nav, bet patiesība ir tāda, ka dažos gadījumos šis rīks veic savu darbu un tiek ar to efektīvi galā. Dažu pēdējo gadu laikā šis rīks ir attīstījies, ieguvis daudz lielāku elastību, pārvarējis daudz problēmu un noņēmis sarežģītības slāni konfigurācijas ziņā.

Joprojām ir daudz problēmu, piemēram, slikta Git veiktspēja, bet cerams, ka tas tiks atrisināts tuvākajā nākotnē.

Ja vēlaties iemācīties izveidot stabilu CI / CD cauruļvadu savai lietotnei, iesaku Kā izveidot efektīvu sākotnējās ieviešanas cauruļvadu ar GitLab CI .

Saistīts: Pastiprināta Git plūsma

Izpratne par pamatiem

Ko nozīmē monolītā arhitektūra?

Monolītā arhitektūra programmatūras izstrādē nozīmē pieeju, kurā lietojumprogramma tiek realizēta kā cieši savienotu komponentu / funkciju kopums, kas sastāv no viena gabala. Jūs nevarat izmantot nevienu komponentu ārpus lietotnes darbības jomas.

Kas ir pirmkodu krātuves?

Repozitorijs ir vieta, kur glabāt un iegūt avota kodu, lai to instalētu / attīstītu. Repos tiek glabātas visas datu versijas ar saistītiem metadatiem, kas ļauj pārskatīt vēsturi vai strādāt pie atsevišķām viena un tā paša projekta paralēlām versijām.

Kāpēc modularitāte ir svarīga programmēšanā?

Brīvi savienots kods ir izrādījies uzticamāks, jo tas ļauj mums ieviest izmaiņas, nebaidoties salauzt lietas citās vietās. Tas padara drošāku attīstību un vienkāršo refaktorēšanu.

Kas ir saites?

Symlinks (simboliskās saites) ir faili ar atsauci uz oriģinālo mapi / failu relatīvā vai absolūtā ceļa veidā, nevis faktiskais saturs. Šajā gadījumā tie tiek izmantoti, lai ietekmētu ceļa nosaukuma izšķirtspēju tā pareizajā vietā.

Kāds ir visizplatītākais moduļu izgatavošanas veids JS?

Mūsdienās vispopulārākais veids, kā izolēt kodu atsevišķos moduļos, ir npm pakotņu izmantošana (to var izdarīt ar dziju vai npm). Tie tiek iesaiņoti mapē ar saviem konfigurācijas failiem un pēc tam tiek virzīti uz attālo serveri.