{"id":34744,"date":"2019-10-31T22:00:10","date_gmt":"2019-10-31T19:00:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/monorepozitorii-pozhalujsta-nado\/"},"modified":"2019-10-31T22:00:10","modified_gmt":"2019-10-31T19:00:10","slug":"monorepozitorii-pozhalujsta-nado","status":"publish","type":"post","link":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/monorepozitorii-pozhalujsta-nado","title":{"rendered":"Monorepositorier: v\u00e6r venlig, n\u00f8dvendigt","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Monorepositorier: v\u00e6r venlig, n\u00f8dvendigt\" src=\"\/wp-content\/uploads\/2019\/05\/a973a60a06e7b336c08db26fa6d72149.JPG\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p><em>Overs\u00e6ttelsen af artiklen er forberedt til studerende p\u00e5 kurset <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/g5Rz\/\">\u201eDevOps praksis og v\u00e6rkt\u00f8jer\u201c<\/a><\/noindex> i uddannelsesprojektet OTUS.<\/em><\/p>\n<p>Du skal v\u00e6lge et monorepo, fordi den adf\u00e6rd, det fremmer i dine teams, er gennemsigtighed og kollektivt ansvar, is\u00e6r n\u00e5r teams vokser. Uanset hvad, vil du v\u00e6re n\u00f8dt til at investere i v\u00e6rkt\u00f8jer, men det er altid bedre, n\u00e5r standardadf\u00e6rden er den adf\u00e6rd, du \u00f8nsker at se i dine teams. <noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p><\/p>\n<h1 id=\"pochemu-my-govorim-ob-etom\">Hvorfor taler vi om dette?<\/h1>\n<p><\/p>\n<p>Matt Klein har skrevet en artikel <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/@mattklein123\/monorepos-please-dont-e9a279be011b\">\u00abMonorepos: Please don\u2019t!\u00bb<\/a><\/noindex>\u200a (note fra overs\u00e6tteren: overs\u00e6ttelse p\u00e5 Habr\u00e9 <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/435306\/\">\u00abMonorepos: please don\u2019t\u00bb<\/a><\/noindex>). Jeg kan godt lide Matt, jeg synes, han er meget intelligent, og du b\u00f8r l\u00e6se hans synspunkt. Han offentliggjorde oprindeligt en afstemning p\u00e5 Twitter:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Monorepositorier: v\u00e6r venlig, n\u00f8dvendigt\" src=\"\/wp-content\/uploads\/2019\/05\/edbc65b80288045e08394821c17a77a9.JPG\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p><em>Overs\u00e6ttelse:<\/em><br \/>\n<em>P\u00e5 denne nyt\u00e5rsdag vil jeg argumentere for, hvor absurde monorepos er. 2019 startede stille. I denne \u00e5nd vil jeg foresl\u00e5 dig en afstemning. Hvem er de store fanatikere? Tilh\u00e6ngere:<\/em><br \/>\n\u2014 <em>Monorepo<\/em><br \/>\n\u2014 <em>Rust<\/em><br \/>\n\u2014 <em>Forkert afstemning \/ begge dele<\/em><\/p>\n<p><\/p>\n<p>Mit svar var: \u00abJeg er bogstaveligt talt begge de mennesker\u00bb. I stedet for at tale om, hvorvidt Rust er en afh\u00e6ngighed, lad os unders\u00f8ge, hvorfor jeg tror, at han tager fejl med hensyn til monorepos. Lidt om mig selv. Jeg er teknisk direkt\u00f8r for Chef Software. Vi har omkring 100 ingeni\u00f8rer, en kodebase, der str\u00e6kker sig over omkring 11\u201312 \u00e5r, og 4 prim\u00e6re produkter. En del af denne kode findes i et polyrepo (min startposition), og en del i et monorepo (min nuv\u00e6rende position).<\/p>\n<p><\/p>\n<p>F\u00f8r jeg starter: hvert argument, jeg fremf\u00f8rer her, vil g\u00e6lde for begge typer af repositories. Efter min mening er der ingen tekniske grunde til, at du skal v\u00e6lge den ene eller den anden type repository. Du kan f\u00e5 enhver tilgang til at fungere. Jeg er glad for at tale om dette, men jeg er ikke interesseret i kunstige tekniske grunde til, at den ene overg\u00e5r den anden. <\/p>\n<p><\/p>\n<p>Jeg er enig i den f\u00f8rste del af Matts synspunkt:<\/p>\n<p><\/p>\n<p><em>Fordi et monorepo i stor skala vil l\u00f8se alle de samme problemer, som et polyrepo g\u00f8r, men samtidig provokerer dig til at have en st\u00e6rk sammenh\u00e6ng i din kode og kr\u00e6ver utrolig indsats for at \u00f8ge skalerbarheden af dit versionskontrolsystem.<\/em><\/p>\n<p><\/p>\n<p>Du st\u00e5r over for de samme problemer, uanset om du v\u00e6lger et monorepo eller et polyrepo. Hvordan frigiver du versioner? Hvad er din tilgang til opdateringer? Bagudkompatibilitet? Krydsafh\u00e6ngigheder mellem projekterne? Hvilke arkitekturstile er acceptable? Hvordan h\u00e5ndterer du din bygg- og testinfrastruktur? Listen er uendelig. Og du vil tackle dem alle, efterh\u00e5nden som du vokser. Der findes ikke gratis ost.<\/p>\n<p><\/p>\n<p>Jeg tror, at Matts argument minder om de synspunkter, mange ingeni\u00f8rer (og ledere) jeg respekterer, deler. Det kommer fra en ingeni\u00f8rs perspektiv, der arbejder p\u00e5 en komponent, eller et team, der arbejder p\u00e5 en komponent. Du h\u00f8rer ofte ting som:<\/p>\n<p><\/p>\n<ul>\n<li>Kodebasen er klodset - jeg har ikke brug for alt det skrammel.<\/li>\n<li>Det er sv\u00e6rere at teste, fordi jeg skal tjekke alt det skrammel, jeg ikke har brug for.<\/li>\n<li>Det er sv\u00e6rere at arbejde med eksterne afh\u00e6ngigheder.<\/li>\n<li>Jeg har brug for mine egne versionsstyringssystemer.<\/li>\n<\/ul>\n<p><\/p>\n<p>Bestemt er alle disse punkter rimelige. Det sker i begge tilf\u00e6lde - i polyrepoet har jeg mit skrammel, ud over det der er n\u00f8dvendigt for bygningen... Jeg kan ogs\u00e5 f\u00e5 brug for noget andet skrammel. Derfor skaber jeg \"bare\" v\u00e6rkt\u00f8jer, der checkout'er hele projektet. Eller jeg opretter et falsk monorepo med submoduler. Vi kunne bruge hele dagen p\u00e5 det. Men jeg tror, at Matts argument overser den grundl\u00e6ggende \u00e5rsag, som jeg har vendt kraftigt til fordel for monorepoet:<\/p>\n<p><\/p>\n<h1 id=\"on-provociruet-obschenie-i-pokazyvaet-problemy\">Det fremmer kommunikation og afsl\u00f8rer problemer.<\/h1>\n<p><\/p>\n<p>N\u00e5r vi deler repositoryer, skaber vi de facto et koordinerings- og gennemsigtighedsproblem. Det svarer til, hvordan vi t\u00e6nker p\u00e5 teams (is\u00e6r hvordan de enkelte medlemmer t\u00e6nker om dem): vi har ansvaret for en bestemt komponent. Vi arbejder i relativ isolation. Gr\u00e6nserne er fastlagt omkring mit team og den(r) komponent(er), vi arbejder p\u00e5.<\/p>\n<p><\/p>\n<p>N\u00e5r arkitekturen bliver mere kompleks, kan \u00e9t team ikke l\u00e6ngere h\u00e5ndtere det alene. Meget f\u00e5 ingeni\u00f8rer har hele systemet i tankerne. Antag, at du administrerer en f\u00e6lles komponent A, der bruges af teamene B, C og D. Team A refaktorerer, forbedrer API'et og \u00e6ndrer ogs\u00e5 den interne implementering. Som et resultat er \u00e6ndringerne bagudkompatible. Hvilket r\u00e5d vil du give?<\/p>\n<p><\/p>\n<ul>\n<li>Find alle steder, hvor det gamle API bruges.<\/li>\n<li>Er der steder, hvor det nye API ikke kan bruges?<\/li>\n<li>Kan du rette og teste de andre komponenter for at sikre, at de ikke g\u00e5r i stykker?<\/li>\n<li>Kan disse teams teste dine \u00e6ndringer lige nu?<\/li>\n<\/ul>\n<p><\/p>\n<p>Bem\u00e6rk, at disse sp\u00f8rgsm\u00e5l ikke afh\u00e6nger af typen af repository. Du bliver n\u00f8dt til at finde teamene B, C og D. Du skal tale med dem, finde ud af tidsrammen, forst\u00e5 deres prioriteter. I det mindste h\u00e5ber vi, at du g\u00f8r det.<\/p>\n<p><\/p>\n<p>I virkeligheden \u00f8nsker ingen at h\u00e5ndtere dette. Det er langt mindre sp\u00e6ndende end simpelthen at rette det forbandede API. Alt dette er menneskeligt og indviklet. I et polyrrepository kan du bare lave \u00e6ndringer, f\u00e5 dem til gennemgang af dem, der arbejder p\u00e5 denne komponent (sandsynligvis ikke B, C eller D), og komme videre. Teams B, C og D kan bare blive p\u00e5 deres nuv\u00e6rende version. De opdaterer, n\u00e5r de indser din genialitet!<\/p>\n<p><\/p>\n<p>I et monorepository skifter ansvaret som standard. Team A \u00e6ndrer sin komponent og, hvis de ikke er forsigtige, bryder de straks B, C og D. Det f\u00f8rer til, at B, C og D st\u00e5r ved d\u00f8ren til A og undrer sig over, hvorfor team A br\u00f8d bygningen. Det l\u00e6rer A, at de ikke kan springe min liste over. De skal tale om, hvad de planl\u00e6gger at g\u00f8re. Kan B, C og D bev\u00e6ge sig? Hvad hvis B og C kan, men D var t\u00e6t knyttet til de u\u00f8nskede effekter af den gamle algoritmes adf\u00e6rd?<\/p>\n<p><\/p>\n<p>S\u00e5 skal vi tale om, hvordan vi kommer ud af denne situation:<\/p>\n<p><\/p>\n<ol>\n<li>Underst\u00f8ttelse af flere interne API'er, mens den gamle algoritme m\u00e6rkes som for\u00e6ldet, indtil D ikke l\u00e6ngere kan bruge den.<\/li>\n<li>Underst\u00f8ttelse af flere versionsudgivelser, \u00e9n med det gamle interface, \u00e9n med det nye.<\/li>\n<li>Forsinkelse af A's \u00e6ndringsudgivelse, indtil B, C og D samtidigt kan acceptere det.<\/li>\n<\/ol>\n<p><\/p>\n<p>Lad os sige, vi har valgt 1, flere API'er. I s\u00e5 fald har vi to stykker kode. Den gamle og den nye. Det er ret praktisk i nogle situationer. Vi returnerer den gamle kode tilbage, markerer den som for\u00e6ldet (deprecated), og koordinerer en tidsplan for dens fjernelse med team D. I det v\u00e6sentlige er det identisk for poly og mono-repositoriet.<\/p>\n<p><\/p>\n<p>For at udgive flere versioner har vi brug for en gren. Nu har vi to komponenter \u2014 A1 og A2. Teams B og C bruger A2, mens D bruger A1. Vi har brug for, at hver komponent er klar til udgivelse, fordi f\u00f8r D kan komme videre, kan der v\u00e6re behov for sikkerhedsopdateringer og rettelser af andre fejl. I poly-repositoriet kan vi skjule dette i en langlivet gren, der fungerer godt. I mono-repositoriet skaber vi tvangsm\u00e6ssigt koden i et nyt modul. Team D skal stadig foretage \u00e6ndringer i den \u201egamle\u201c komponent. Alle kan se prisen, vi betaler her \u2014 vi har nu dobbelt s\u00e5 meget kode, og enhver fejlrettelse, der anvendes p\u00e5 A1 og A2, skal anvendes p\u00e5 begge. Med tilgangen til at bruge grene i poly-repositoriet er dette skjult bag cherry-pick. Vi betragter omkostningen som mindre, fordi der ikke er nogen duplikering. Rent praktisk set er omkostningen den samme: I vil oprette, udgive og vedligeholde to stort set identiske kodebaser, indtil I kan fjerne en af dem. Forskellen er, at smerten i mono-repositoriet er direkte og synlig. <strong>Det er endnu v\u00e6rre, og det er godt.<\/strong><\/p>\n<p><\/p>\n<p>Endelig er vi n\u00e5et til det tredje punkt. Udgivelsesforsinkelse. Det er muligt, at de \u00e6ndringer, som team A har foretaget, vil forbedre situationen for team A. Vigtigt, men ikke presserende. Kan vi bare uds\u00e6tte det? I monorepoet skubber vi dette hen imod en fastl\u00e6ggelse af artefakten. Selvf\u00f8lgelig taler vi om dette med team D. Bare hold jer til den gamle version, indtil I indhenter! Dette skaber en situation, hvor vi spiller sikkert. Team A forts\u00e6tter med at arbejde p\u00e5 deres komponent og ignorerer, at team D bruger en stadigt mere for\u00e6ldet version (det er team Ds problem, de er dumme). Imens taler team D d\u00e5rligt om det uansvarlige forhold, som team A har til stabiliteten af koden, hvis de overhovedet taler om det. M\u00e5neder g\u00e5r. Endelig beslutter team D at se p\u00e5 at opdatere, men der er kun kommet flere \u00e6ndringer i A. Team A kan n\u00e6ppe huske, hvorn\u00e5r og hvordan de \u00f8delagde D. Opdateringen bliver mere smertefuld og vil tage l\u00e6ngere tid. Hvilket sender det l\u00e6ngere ned ad prioriteringslisten. Indtil den dag, vi f\u00e5r et sikkerhedsproblem i A, der tvinger os til at lave en gren. Team A skal tilbage i tiden, finde det \u00f8jeblik, hvor D var stabilt, rette problemet der og g\u00f8re det klar til udgivelse. <strong>Dette er de facto et valg, som folk tr\u00e6ffer, og det er bestemt det v\u00e6rste.<\/strong> Det ser ud til at v\u00e6re godt for b\u00e5de team A og team D, s\u00e5 l\u00e6nge vi kan ignorere hinanden.<\/p>\n<p><\/p>\n<p>I et monorepo er det tredje reelt ikke en mulighed. Du er n\u00f8dt til at h\u00e5ndtere situationen p\u00e5 en af to m\u00e5der. Du skal forst\u00e5 omkostningerne ved at have to udgivelsesgrene. L\u00e6re at beskytte dig mod opdateringer, der bryder bagudkompatibiliteten. Men vigtigst af alt: <em>du kan ikke undg\u00e5 en sv\u00e6r samtale.<\/em><\/p>\n<p><\/p>\n<p>Efter min erfaring, n\u00e5r teams vokser, bliver det umuligt at holde hele systemet i hovedet, og det er den vigtigste del. Du skal forbedre synligheden af uoverensstemmelserne i systemet. Du skal aktivt arbejde p\u00e5 at f\u00e5 teams til at tage blikket v\u00e6k fra deres komponenter og se p\u00e5 arbejdet fra andre teams og forbrugere.<\/p>\n<p><\/p>\n<p>Ja, du kan oprette v\u00e6rkt\u00f8jer, der fors\u00f8ger at l\u00f8se problemet med polirepositorier. Men min erfaring med kontinuerlig levering og automatisering i store virksomheder fort\u00e6ller mig f\u00f8lgende: Standardadf\u00e6rden uden brug af ekstra v\u00e6rkt\u00f8jer er den adf\u00e6rd, du forventer at se. <strong>Standardadf\u00e6rden for et polirepositorium er isolation, det er hele pointen. Standardadf\u00e6rden for et monorepositorium er f\u00e6lles ansvar og gennemsigtighed, det er hele pointen.<\/strong> I begge tilf\u00e6lde vil jeg skabe et v\u00e6rkt\u00f8j, der kan glatte de skarpe kanter. Som leder vil jeg v\u00e6lge et monorepositorium hver gang, fordi v\u00e6rkt\u00f8jer skal styrke den kultur, jeg \u00f8nsker, og kulturen kommer fra de sm\u00e5 beslutninger og det daglige arbejde i teamet.<\/p>\n<p class=\"for_users_only_msg\">Kun registrerede brugere kan deltage i unders\u00f8gelsen. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/auth\/login\/\">Log ind<\/a><\/noindex>, please.<\/p>\n<h2 class=\"default-block__polling-title\">Hvem er de st\u00f8rre fanatikere? Tilh\u00e6ngere:<\/h2>\n<ul class=\"content-list content-list_polling\">\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Monorepo<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Rust<\/p>\n<\/li>\n<li class=\"content-list__item content-list__item_polling\">\n<p>                    Forkert afstemning \/ begge dele<\/p>\n<\/li>\n<\/ul>\n<p>    33 brugere stemte. 13 brugere afholdt sig.<br \/>\n<br \/>Kilde: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/otus\/blog\/453958\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0435\u0440\u0435\u0432\u043e\u0434 \u0441\u0442\u0430\u0442\u044c\u0438 \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u043b\u0435\u043d \u0434\u043b\u044f \u0441\u0442\u0443\u0434\u0435\u043d\u0442\u043e\u0432 \u043a\u0443\u0440\u0441\u0430 \u00abDevOps \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0438 \u0438 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u044b\u00bb \u0432 \u043e\u0431\u0440\u0430\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u043c \u043f\u0440\u043e\u0435\u043a\u0442\u0435 OTUS. \u0412\u044b \u0434\u043e\u043b\u0436\u043d\u044b \u0432\u044b\u0431\u0440\u0430\u0442\u044c \u043c\u043e\u043d\u043e\u0440\u0435\u043f\u043e\u0437\u0438\u0442\u043e\u0440\u0438\u0439, \u043f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u043f\u043e\u0432\u0435\u0434\u0435\u043d\u0438\u0435, \u043a\u043e\u0442\u043e\u0440\u043e\u043c\u0443 \u043e\u043d \u0441\u043f\u043e\u0441\u043e\u0431\u0441\u0442\u0432\u0443\u0435\u0442 \u0432 \u0432\u0430\u0448\u0438\u0445 \u043a\u043e\u043c\u0430\u043d\u0434\u0430\u0445 \u2014 \u044d\u0442\u043e \u043f\u0440\u043e\u0437\u0440\u0430\u0447\u043d\u043e\u0441\u0442\u044c \u0438 \u043a\u043e\u043b\u043b\u0435\u043a\u0442\u0438\u0432\u043d\u0430\u044f \u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0441\u0442\u044c, \u043e\u0441\u043e\u0431\u0435\u043d\u043d\u043e \u043f\u0440\u0438 \u0440\u043e\u0441\u0442\u0435 \u043a\u043e\u043c\u0430\u043d\u0434. \u0412 \u043b\u044e\u0431\u043e\u043c \u0441\u043b\u0443\u0447\u0430\u0435 \u0432\u0430\u043c \u043f\u0440\u0438\u0434\u0451\u0442\u0441\u044f \u0432\u043a\u043b\u0430\u0434\u044b\u0432\u0430\u0442\u044c\u0441\u044f \u0432 \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u0430\u0440\u0438\u0439, \u043d\u043e \u0432\u0441\u0435\u0433\u0434\u0430 \u043b\u0443\u0447\u0448\u0435, \u043a\u043e\u0433\u0434\u0430 \u043f\u043e\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u043f\u043e \u0443\u043c\u043e\u043b\u0447\u0430\u043d\u0438\u044e \u2014 \u044d\u0442\u043e \u043f\u043e\u0432\u0435\u0434\u0435\u043d\u0438\u0435, [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26181,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-34744","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0435\u0440\u0435\u0432\u043e\u0434 \u0441\u0442\u0430\u0442\u044c\u0438 \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u043b\u0435\u043d \u0434\u043b\u044f \u0441\u0442\u0443\u0434\u0435\u043d\u0442\u043e\u0432.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/monorepozitorii-pozhalujsta-nado\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"da_DK\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041c\u043e\u043d\u043e\u0440\u0435\u043f\u043e\u0437\u0438\u0442\u043e\u0440\u0438\u0438: \u043f\u043e\u0436\u0430\u043b\u0443\u0439\u0441\u0442\u0430, \u043d\u0430\u0434\u043e | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0435\u0440\u0435\u0432\u043e\u0434 \u0441\u0442\u0430\u0442\u044c\u0438 \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u043b\u0435\u043d \u0434\u043b\u044f \u0441\u0442\u0443\u0434\u0435\u043d\u0442\u043e\u0432.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/monorepozitorii-pozhalujsta-nado\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:00:10+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:00:10+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Monorepositorier: ja, tak | ProHoster","description":"Overs\u00e6ttelsen af artiklen er udarbejdet til studerende.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/monorepozitorii-pozhalujsta-nado","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041c\u043e\u043d\u043e\u0440\u0435\u043f\u043e\u0437\u0438\u0442\u043e\u0440\u0438\u0438: \u043f\u043e\u0436\u0430\u043b\u0443\u0439\u0441\u0442\u0430, \u043d\u0430\u0434\u043e | ProHoster","og:description":"\u041f\u0435\u0440\u0435\u0432\u043e\u0434 \u0441\u0442\u0430\u0442\u044c\u0438 \u043f\u043e\u0434\u0433\u043e\u0442\u043e\u0432\u043b\u0435\u043d \u0434\u043b\u044f \u0441\u0442\u0443\u0434\u0435\u043d\u0442\u043e\u0432.","og:url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/monorepozitorii-pozhalujsta-nado","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:00:10+00:00","article:modified_time":"2019-10-31T19:00:10+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34744","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 20:28:56","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:15:38","updated":"2026-01-21 20:28:56","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/34744","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=34744"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/34744\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/26181"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=34744"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=34744"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=34744"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}