{"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\/it\/blog\/administrirovanie\/monorepozitorii-pozhalujsta-nado","title":{"rendered":"Monorepo: per favore, \u00e8 necessario","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Monorepo: per favore, \u00e8 necessario\" src=\"\/wp-content\/uploads\/2019\/05\/a973a60a06e7b336c08db26fa6d72149.JPG\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p><em>La traduzione dell'articolo \u00e8 preparata per gli studenti del corso <noindex><a rel=\"nofollow\" href=\"https:\/\/otus.pw\/g5Rz\/\">\u00abPratiche e strumenti DevOps\u00bb<\/a><\/noindex> nel progetto educativo OTUS.<\/em><\/p>\n<p>Dovete scegliere un monorepo, perch\u00e9 il comportamento che favorisce nei vostri team \u00e8 la trasparenza e la responsabilit\u00e0 collettiva, soprattutto con la crescita delle squadre. In ogni caso dovrete investire in strumenti, ma \u00e8 sempre meglio quando il comportamento di default \u00e8 quello che volete vedere nei vostri team. <noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p><\/p>\n<h1 id=\"pochemu-my-govorim-ob-etom\">Perch\u00e9 ne parliamo?<\/h1>\n<p><\/p>\n<p>Matt Klein ha scritto un articolo <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/@mattklein123\/monorepos-please-dont-e9a279be011b\">\u00abMonorepos: Please don\u2019t!\u00bb<\/a><\/noindex>\u200a (nota del traduttore: traduzione su Habr <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/435306\/\">\u00abMonorepository: per favore non fatelo\u00bb<\/a><\/noindex>). Mi piace Matt, penso che sia molto intelligente e dovete leggere il suo punto di vista. Inizialmente ha pubblicato un sondaggio su Twitter:<\/p>\n<p><\/p>\n<p><img decoding=\"async\" alt=\"Monorepo: per favore, \u00e8 necessario\" src=\"\/wp-content\/uploads\/2019\/05\/edbc65b80288045e08394821c17a77a9.JPG\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p><\/p>\n<p><em>Traduzione:<\/em><br \/>\n<em>In questo giorno di Capodanno discuter\u00f2 di quanto siano ridicoli i monorepo. Il 2019 \u00e8 iniziato in modo impercettibile. In questo spirito vi propongo un sondaggio. Chi sono i grandi fan? Sostenitori:<\/em><br \/>\n\u2014 <em>Monorepo<\/em><br \/>\n\u2014 <em>Rust<\/em><br \/>\n\u2014 <em>Sondaggio errato \/ entrambi<\/em><\/p>\n<p><\/p>\n<p>La mia risposta \u00e8 stata: \u00abSono letteralmente entrambe queste persone\u00bb. Invece di parlare di quanto sia una droga Rust, vediamo perch\u00e9 penso che si sbagli sui monorepo. Un po' su di me. Sono il direttore tecnico di Chef Software. Abbiamo circa 100 ingegneri, un codice base di circa 11-12 anni e 4 prodotti principali. Parte di questo codice \u00e8 in un polyrepo (la mia posizione di partenza), parte \u00e8 in un monorepo (la mia posizione attuale).<\/p>\n<p><\/p>\n<p>Prima di cominciare: ogni argomento che presento qui sar\u00e0 applicabile a entrambi i tipi di repository. Secondo me, non ci sono motivi tecnici per cui dovreste scegliere un tipo di repository rispetto all'altro. Potete far funzionare qualsiasi approccio. Sono felice di parlarne, ma non sono interessato a motivi tecnici artificiali per cui uno sia superiore all'altro. <\/p>\n<p><\/p>\n<p>Sono d'accordo con la prima parte del punto di vista di Matt:<\/p>\n<p><\/p>\n<p><em>Perch\u00e9 su larga scala un monorepo affronter\u00e0 tutti gli stessi problemi che affronta un polyrepo, ma vi spinger\u00e0 a una forte coesione del codice e richieder\u00e0 sforzi incredibili per aumentare la scalabilit\u00e0 del vostro sistema di controllo versione.<\/em><\/p>\n<p><\/p>\n<p>Dovrete affrontare problemi simili indipendentemente dal fatto che scegliate un monorepo o un polirepo. Come rilasciate le versioni? Qual \u00e8 il vostro approccio agli aggiornamenti? Compatibilit\u00e0 retroattiva? Dipendenze incrociate tra i progetti? Quali stili architettonici sono accettabili? Come gestite la vostra infrastruttura di build e test? La lista \u00e8 infinita. E dovrete risolverli tutti man mano che crescete. Non esiste il formaggio gratuito.<\/p>\n<p><\/p>\n<p>Penso che l'argomento di Matt somigli ai punti di vista condivisi da molti ingegneri (e manager) che rispetto. Questo avviene dal punto di vista di un ingegnere che lavora su un componente o di un team che lavora su un componente. Sentirete affermazioni del tipo:<\/p>\n<p><\/p>\n<ul>\n<li>Il codice \u00e8 ingombrante \u2014 non ho bisogno di tutta questa spazzatura.<\/li>\n<li>\u00c8 pi\u00f9 difficile da testare, perch\u00e9 devo controllare tutta questa spazzatura che non mi serve.<\/li>\n<li>\u00c8 pi\u00f9 complicato lavorare con dipendenze esterne.<\/li>\n<li>Ho bisogno dei miei sistemi di gestione delle versioni virtuali.<\/li>\n<\/ul>\n<p><\/p>\n<p>Senza dubbio, tutti questi punti sono giustificati. Questo accade in entrambi i casi \u2014 in un polirepo ho la mia spazzatura, oltre a quella necessaria per la build... Potrei aver bisogno anche di altra spazzatura. Quindi io 'semplicemente' creo strumenti che fanno il checkout dell'intero progetto. Oppure creo un finto monorepo con sottocontrolli. Potremmo discuterne per tutta la giornata. Ma penso che l'argomento di Matt trascuri la ragione principale che ho molto fortemente rovesciato a favore del monorepo:<\/p>\n<p><\/p>\n<h1 id=\"on-provociruet-obschenie-i-pokazyvaet-problemy\">Favorisce la comunicazione e mette in evidenza i problemi<\/h1>\n<p><\/p>\n<p>Quando separiamo i repository, creiamo di fatto un problema di coordinazione e trasparenza. Questo corrisponde a come pensiamo ai team (soprattutto a come li vedono i singoli membri): siamo responsabili per un componente specifico. Lavoriamo in relativa isolamento. I confini sono stabiliti nel mio team e nel (-i) componente(-i) su cui lavoriamo.<\/p>\n<p><\/p>\n<p>Completando l'architettura, un solo team non pu\u00f2 pi\u00f9 gestirla da solo. Molti pochi ingegneri riescono a mantenere l'intero sistema a mente. Supponiamo che tu stia gestendo un componente comune A, utilizzato dai team B, C e D. Il team A effettua un refactoring, migliora l'API e cambia anche l'implementazione interna. Di conseguenza, le modifiche non sono retrocompatibili. Quale consiglio daresti?<\/p>\n<p><\/p>\n<ul>\n<li>Trova tutti i posti in cui viene utilizzata la vecchia API.<\/li>\n<li>Ci sono posti in cui la nuova API non pu\u00f2 essere utilizzata?<\/li>\n<li>Puoi correggere e testare altri componenti per assicurarti che non si rompano?<\/li>\n<li>Possono questi team controllare le tue modifiche proprio ora?<\/li>\n<\/ul>\n<p><\/p>\n<p>Nota che queste domande non dipendono dal tipo di repository. Dovrai trovare i team B, C e D. Dovrai parlarne con loro, capire i tempi e le loro priorit\u00e0. Almeno speriamo che tu lo faccia.<\/p>\n<p><\/p>\n<p>In realt\u00e0, nessuno vuole occuparsene. \u00c8 molto meno coinvolgente che semplicemente sistemare una dannata API. Tutto ci\u00f2 \u00e8 umano e complicato. In un polo repository puoi semplicemente apportare modifiche, farle revisionare a chi lavora su quel componente (probabilmente non B, C o D) e andare avanti. I team B, C e D possono semplicemente rimanere sulla loro attuale versione. Si aggiorneranno quando realizzeranno la tua genialit\u00e0!<\/p>\n<p><\/p>\n<p>Nel monorepository, la responsabilit\u00e0 si sposta per default. Il team A modifica il proprio componente e, se non fa attenzione, rompe immediatamente B, C e D. Questo porta B, C e D alla porta di A, chiedendosi perch\u00e9 il team A abbia rotto la build. Questo insegna ad A che non possono ignorare la mia lista sopra. Devono parlare di ci\u00f2 che intendono fare. Possono B, C e D procedere? E se B e C possono, ma D fosse strettamente legato a effetti collaterali del comportamento del vecchio algoritmo?<\/p>\n<p><\/p>\n<p>Poi dobbiamo parlare di come uscirne:<\/p>\n<p><\/p>\n<ol>\n<li>Supporto per pi\u00f9 API interne, con l'algoritmo vecchio contrassegnato come obsoleto, finch\u00e9 D non pu\u00f2 smettere di usarlo.<\/li>\n<li>Supporto per pi\u00f9 versioni di rilascio, una con l'interfaccia vecchia, una con quella nuova.<\/li>\n<li>Ritardo del rilascio delle modifiche A finch\u00e9 allo stesso tempo B, C e D non possono accettarlo.<\/li>\n<\/ol>\n<p><\/p>\n<p>Supponiamo di aver scelto 1, diversi API. In questo caso abbiamo due pezzi di codice. Uno vecchio e uno nuovo. \u00c8 piuttosto comodo in alcune situazioni. Ritorniamo il codice vecchio, lo contrassegniamo come obsoleto (deprecated) e coordiniamo il piano per la sua rimozione con il team D. \u00c8 sostanzialmente identico sia per i mono-repository che per i poly-repository.<\/p>\n<p><\/p>\n<p>Per rilasciare diverse versioni abbiamo bisogno di un ramo. Ora abbiamo due componenti \u2014 A1 e A2. I team B e C utilizzano A2, mentre D utilizza A1. Dobbiamo assicurarci che ogni componente sia pronto per il rilascio, perch\u00e9 prima che D possa avanzare, potrebbero essere necessarie aggiornamenti di sicurezza e correzioni di altri bug. Nel poly-repository possiamo nascondere questo in un ramo a lungo termine, che si sente bene. Nel mono-repository forziamo la creazione di codice in un nuovo modulo. Il team D dovr\u00e0 comunque apportare modifiche al componente \"vecchio\". Ognuno pu\u00f2 vedere il costo che stiamo pagando qui: ora abbiamo il doppio del codice e qualsiasi correzione di bug applicata a A1 e A2 deve essere applicata a entrambi. Con l'approccio dei rami nel poly-repository, questo \u00e8 nascosto dietro il cherry-pick. Consideriamo il costo minore, perch\u00e9 non c'\u00e8 duplicazione. Da un punto di vista pratico, il costo \u00e8 lo stesso: dovrete costruire, rilasciare e mantenere due basi di codice, fondamentalmente identiche, finch\u00e9 non potrete rimuovere una di esse. La differenza \u00e8 che nel mono-repository questo dolore \u00e8 diretto e in vista. <strong>\u00c8 ancora peggio, e questo \u00e8 positivo.<\/strong><\/p>\n<p><\/p>\n<p>Finalmente, siamo arrivati al terzo punto. Ritardo nel rilascio. \u00c8 possibile che le modifiche apportate da A migliorino la vita del team A. \u00c8 importante, ma non urgente. Possiamo semplicemente ritardare? Nel monorepository stiamo spingendo per fissare l'artefatto. Ovviamente, ne parliamo con il team D. Rimanete semplicemente sulla vecchia versione fino a quando non recuperate! Questo porta a una mentalit\u00e0 imprudente. Il team A continua a lavorare sul proprio componente, ignorando il fatto che il team D utilizza una versione sempre pi\u00f9 obsoleta (\u00e8 un problema del team D, sono sciocchi). Nel frattempo, il team D parla male dell'atteggiamento irrispettoso del team A nei confronti della stabilit\u00e0 del codice, se ne parla anche. Passano mesi. Alla fine, il team D decide di esaminare la possibilit\u00e0 di un aggiornamento, ma le modifiche in A sono aumentate. Il team A ricorda a malapena quando e come hanno rotto D. L'aggiornamento \u00e8 pi\u00f9 doloroso e richieder\u00e0 pi\u00f9 tempo. Cosa che lo spinge ulteriormente verso il basso nella lista delle priorit\u00e0. Fino al giorno in cui non abbiamo un problema di sicurezza in A, cosa che ci costringe a fare un branch. Il team A deve tornare indietro nel tempo, trovare il momento in cui D era stabile, risolvere il problema e prepararlo per il rilascio. <strong>Questa \u00e8 de facto una scelta che le persone fanno, ed \u00e8 senza dubbio la peggiore.<\/strong> Sembra che questo vada bene sia per il team A che per il team D, finch\u00e9 possiamo ignorarci a vicenda.<\/p>\n<p><\/p>\n<p>In un monorepo, il terzo non \u00e8 davvero un'opzione. Sei costretto a gestire la situazione in uno dei due modi. Devi vedere i costi di avere due rami di rilascio. Imparare a proteggerti dagli aggiornamenti che rompono la compatibilit\u00e0 retroattiva. Ma la cosa principale \u00e8: <em>non puoi evitare una conversazione difficile.<\/em><\/p>\n<p><\/p>\n<p>Per la mia esperienza, quando i team crescono, non c'\u00e8 pi\u00f9 la possibilit\u00e0 di tenere a mente l'intero sistema, ed \u00e8 la parte pi\u00f9 importante. Devi migliorare la visibilit\u00e0 dei conflitti all'interno del sistema. Devi lavorare attivamente per far s\u00ec che i team stacchino lo sguardo dai propri componenti e guardino al lavoro degli altri team e dei consumatori.<\/p>\n<p><\/p>\n<p>S\u00ec, puoi creare strumenti che tenteranno di risolvere la questione dei polirepository. Ma la mia esperienza nell'apprendimento della consegna continua (continuous delivery) e nell'automazione in grandi imprese mi dice questo: il comportamento predefinito senza l'uso di strumenti aggiuntivi \u00e8 quello che ci si aspetta di vedere. <strong>Il comportamento predefinito dei polirepository \u00e8 l'isolamento, ecco il succo. Il comportamento predefinito dei monorepository \u00e8 la responsabilit\u00e0 condivisa e la trasparenza, ecco il succo.<\/strong> In entrambi i casi, intendo creare uno strumento che permetta di smussare gli angoli. Come responsabile, sceglier\u00f2 sempre un monorepository, perch\u00e9 gli strumenti devono rafforzare la cultura che desidero, e la cultura deriva da piccole decisioni e dal lavoro quotidiano del team.<\/p>\n<p class=\"for_users_only_msg\">Solo gli utenti registrati possono partecipare al sondaggio. <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/auth\/login\/\">Accedi<\/a><\/noindex>, per favore.<\/p>\n<h2 class=\"default-block__polling-title\">Chi sono i fanatici maggiori? Sostenitori:<\/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>                    Sondaggio errato \/ entrambi<\/p>\n<\/li>\n<\/ul>\n<p>    Hanno votato 33 utenti. 13 utenti si sono astenuti.<br \/>\n<br \/>Fonte: <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.1.1 - 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\/it\/blog\/administrirovanie\/monorepozitorii-pozhalujsta-nado\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\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\/it\/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\udd47Monorepository: per favore, s\u00ec | ProHoster","description":"La traduzione dell'articolo \u00e8 stata preparata per gli studenti.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/monorepozitorii-pozhalujsta-nado","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/34744","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=34744"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/34744\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/26181"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=34744"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=34744"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=34744"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}