{"id":77783,"date":"2020-04-14T01:42:28","date_gmt":"2020-04-13T23:42:28","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/metodika-razvyortyvaniya-proektov-primenyaemaya-v-slack"},"modified":"2020-04-14T01:42:28","modified_gmt":"2020-04-13T23:42:28","slug":"metodika-razvyortyvaniya-proektov-primenyaemaya-v-slack","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/metodika-razvyortyvaniya-proektov-primenyaemaya-v-slack","title":{"rendered":"La metodologia di distribuzione dei progetti utilizzata in Slack","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

L'implementazione di una nuova release in produzione richiede un attento equilibrio tra velocit\u00e0 di distribuzione e affidabilit\u00e0 della soluzione. In Slack si apprezzano iterazioni rapide, brevi cicli di feedback e una risposta tempestiva alle richieste degli utenti. Inoltre, ci sono centinaia di programmatori in azienda che puntano a massimizzare la propria produttivit\u00e0.<\/p>\n

\"La<\/a><\/noindex><\/p>\n

Gli autori del materiale, il cui traduzione pubblichiamo oggi, affermano che un'azienda che cerca di mantenere tali valori e allo stesso tempo cresce deve costantemente migliorare il proprio sistema di distribuzione dei progetti. L'azienda deve investire nello sviluppo della trasparenza e dell'affidabilit\u00e0 dei propri processi lavorativi, affinch\u00e9 questi siano allineati alle dimensioni del progetto. Qui si parler\u00e0 dei processi di lavoro stabiliti in Slack e di alcune soluzioni che hanno portato l'azienda all'adozione dell'attuale sistema di distribuzione dei progetti.
\n<\/a><\/noindex><\/p>\n

Come funzionano oggi i processi di distribuzione dei progetti<\/h2>\n

\nOgni PR (pull request) in Slack deve essere sottoposta a revisione del codice e deve superare tutti i test con successo. Solo dopo aver soddisfatto queste condizioni, il programmatore pu\u00f2 unire il proprio codice al branch master del progetto. Tuttavia, la distribuzione di quel codice avviene solo durante l'orario lavorativo secondo il fuso orario nordamericano. Di conseguenza, grazie alla presenza dei nostri dipendenti in ufficio, siamo completamente pronti a risolvere eventuali problemi imprevisti.<\/p>\n

Ogni giorno effettuiamo circa 12 distribuzioni programmate. Durante ogni distribuzione, il programmatore incaricato come principale responsabile della distribuzione si occupa di implementare la nuova build in produzione. Questo \u00e8 un processo a pi\u00f9 fasi che garantisce una transizione fluida della build in modalit\u00e0 operativa. Grazie a questo approccio, possiamo individuare errori prima che colpiscano tutti i nostri utenti. Se gli errori sono troppi, la distribuzione della build pu\u00f2 essere annullata. Se, tuttavia, un problema specifico viene scoperto dopo il rilascio, \u00e8 facile rilasciare una correzione.<\/p>\n

\"La
\nInterfaccia del sistema Checkpoint, utilizzata in Slack per la distribuzione dei progetti<\/i><\/p>\n

Il processo di distribuzione di una nuova release in produzione pu\u00f2 essere suddiviso in quattro fasi.<\/p>\n

\u258d1. Creazione del branch di rilascio<\/h3>\n

\nOgni release inizia con un nuovo branch di rilascio, a partire da un punto nella nostra storia Git. Questo consente di assegnare tag alla release e offre uno spazio per apportare correzioni rapide agli errori riscontrati durante la preparazione della release per il rilascio in produzione.<\/p>\n

\u258d2. Distribuzione nell'ambiente di staging<\/h3>\n

\nIl passo successivo consiste nella distribuzione della build sui server di staging e nell'esecuzione di un test automatico di funzionalit\u00e0 generale del progetto (smoke test). L'ambiente di staging \u00e8 un ambiente di produzione privo di traffico esterno. In questo ambiente eseguiamo ulteriori test manuali. Questo ci fornisce maggiore fiducia nel fatto che il progetto modificato funzioni correttamente. Solo i test automatizzati non sono sufficienti per ottenere tale sicurezza.<\/p>\n

\u258d3. Distribuzione negli ambienti dogfood e canary<\/h3>\n

\nLa distribuzione in produzione inizia con l'ambiente dogfood, composto da un insieme di host che servono i nostri spazi di lavoro interni su Slack. Poich\u00e9 siamo utenti molto attivi di Slack, questo approccio ha aiutato a scoprire molti errori nelle fasi iniziali della distribuzione. Dopo aver verificato che le funzionalit\u00e0 di base del sistema non siano compromesse, procediamo a distribuire la build nell'ambiente canary. Questo rappresenta i sistemi che ricevono circa il 2% del traffico in produzione.<\/p>\n

\u258d4. Rilascio graduale in produzione<\/h3>\n

\nSe gli indicatori di monitoraggio della nuova release rimangono stabili e se dopo la distribuzione nell'ambiente canary non riceviamo lamentele, continuiamo il rilascio graduale dei server di produzione sulla nuova release. Il processo di distribuzione \u00e8 suddiviso in fasi: 10%, 25%, 50%, 75% e 100%. In questo modo possiamo trasferire lentamente il traffico di produzione alla nuova release del sistema. Allo stesso tempo, abbiamo tempo per esaminare la situazione in caso di anomalie.<\/p>\n

\u258dCosa fare se qualcosa va storto durante la distribuzione?<\/h3>\n

\nLe modifiche al codice comportano sempre dei rischi. Tuttavia, li gestiamo grazie alla presenza di esperti ben preparati nel processo di distribuzione, che guidano il lancio delle nuove versioni in produzione, monitorano le metriche di controllo e coordinano il lavoro degli sviluppatori che rilasciano il codice.<\/p>\n

Nel caso in cui qualcosa vada realmente storto, cerchiamo di identificare il problema il prima possibile. Esaminiamo il problema, troviamo il PR che causa gli errori, lo annulliamo, analizziamo attentamente e creiamo una nuova build. A volte, tuttavia, il problema non viene notato fino al lancio del progetto in produzione. In tale situazione, la cosa pi\u00f9 importante \u00e8 ripristinare il servizio. Pertanto, prima di iniziare a indagare sul problema, torniamo immediatamente alla versione precedente funzionante.<\/p>\n

Mattoni del sistema di distribuzione<\/h2>\n

\nEsaminiamo le tecnologie alla base del nostro sistema di distribuzione dei progetti.<\/p>\n

\u258dDistribuzioni rapide<\/h3>\n

\nIl workflow descritto sopra potrebbe sembrare, a posteriori, piuttosto ovvio. Tuttavia, il nostro sistema di distribuzione non \u00e8 diventato tale dall'oggi al domani.<\/p>\n

Quando l'azienda era significativamente pi\u00f9 piccola, tutta la nostra applicazione poteva funzionare su 10 istanze Amazon EC2. In questa situazione, distribuire un progetto significava utilizzare rsync per sincronizzare rapidamente tutti i server. In passato, ci voleva solo un passaggio, rappresentato dall'ambiente intermedio, per separare il nuovo codice dalla produzione. Le build venivano create e testate in quell'ambiente e poi andavano direttamente in produzione. Era molto facile capire un sistema del genere; consentiva a qualsiasi sviluppatore di distribuire il codice che aveva scritto in qualsiasi momento.<\/p>\n

Ma man mano che aumentava il numero dei nostri clienti, cresceva anche l'infrastruttura necessaria per mantenere il progetto funzionante. Presto, data la crescita costante del sistema, il nostro modello di distribuzione, basato sull'invio di nuovo codice ai server, non era pi\u00f9 in grado di svolgere il proprio compito. Infatti, aggiungere ogni nuovo server significava aumentare il tempo richiesto per completare la distribuzione. Anche le strategie che si basano sull'applicazione parallela di rsync presentano alcune limitazioni.<\/p>\n

Di conseguenza, abbiamo risolto il problema passando a un sistema di distribuzione completamente parallelo, organizzato in modo diverso rispetto al sistema precedente. Ora non inviavamo pi\u00f9 il codice ai server utilizzando uno script di sincronizzazione. Ogni server ora scaricava autonomamente la nuova build, sapendo che doveva farlo grazie al monitoraggio della modifica della chiave Consul. I server scaricavano il codice in parallelo. Questo ci ha permesso di mantenere alta la velocit\u00e0 di distribuzione anche in un contesto di crescita continua del sistema.<\/p>\n

\"La
\n1. I server di produzione monitorano la chiave Consul. 2. La chiave viene modificata, informando i server di avviare il download del nuovo codice. 3. I server caricano i file tarball con il codice dell'applicazione.<\/i><\/p>\n

\u258dDistribuzioni atomiche<\/h3>\n

\nUn'altra soluzione che ci ha aiutato a raggiungere un sistema di distribuzione multilivello \u00e8 stata la distribuzione atomica.<\/p>\n

Prima di utilizzare distribuzioni atomiche, ogni distribuzione poteva generare numerosi messaggi di errore. Infatti, il processo di copia di nuovi file sui server di produzione non era atomico. Questo portava a un breve intervallo temporale in cui il codice che chiamava nuove funzioni era disponibile prima che le stesse funzioni fossero pronte. Quando tale codice veniva chiamato, portava al ritorno di errori interni. Ci\u00f2 si manifestava in richieste API fallite e pagine web 'rotte'.<\/p>\n

Il team incaricato di questo problema lo ha risolto introducendo i concetti di directory 'calde' (hot) e 'fredde' (cold). Il codice nella directory 'calda' gestisce il traffico di produzione. Nelle directory 'fredde', il codice viene preparato per l'uso durante il funzionamento del sistema. Durante la distribuzione, il nuovo codice viene copiato in una directory 'fredda' non utilizzata. Poi, quando non ci sono processi attivi sul server, avviene il passaggio istantaneo delle directory.<\/p>\n

\"La
\n1. Estrarre il codice dell'applicazione nella directory 'fredda'. 2. Passare il sistema dalla directory 'fredda', che diventa 'calda' (operazione atomica).<\/i><\/p>\n

Risultati: spostamento dell'accento verso l'affidabilit\u00e0.<\/h2>\n

\nNel 2018, il progetto ha raggiunto dimensioni tale che un'implementazione molto rapida ha iniziato a compromettere la stabilit\u00e0 del prodotto. Avevamo un sistema di distribuzione piuttosto avanzato, in cui abbiamo investito molto impegno e tempo. Dobbiamo solo riorganizzare e perfezionare i processi di distribuzione. Siamo diventati un'azienda di dimensioni considerevoli, le cui soluzioni sono state utilizzate in tutto il mondo per garantire comunicazioni ininterrotte e risolvere problemi importanti. Pertanto, l'affidabilit\u00e0 \u00e8 diventata la nostra principale preoccupazione.<\/p>\n

Dovevamo rendere il processo di distribuzione delle nuove versioni di Slack pi\u00f9 sicuro. Questa esigenza ci ha portato a migliorare il nostro sistema di distribuzione. In effetti, abbiamo gi\u00e0 discusso di questo sistema avanzato. Nel cuore del sistema continuiamo a fare uso di tecnologie di distribuzione rapida e atomica. Ci\u00f2 che \u00e8 cambiato \u00e8 il modo in cui viene eseguita la distribuzione. Il nostro nuovo sistema \u00e8 progettato per eseguire gradualmente la distribuzione del nuovo codice a diversi livelli e in ambienti diversi. Ora utilizziamo strumenti ausiliari e risorse di monitoraggio pi\u00f9 sofisticati rispetto a prima. Questo ci consente di identificare e risolvere errori molto tempo prima che abbiano la possibilit\u00e0 di raggiungere l'utente finale.<\/p>\n

Ma non intendiamo fermarci qui. Stiamo costantemente migliorando questo sistema, applicando strumenti ausiliari e risorse di automazione pi\u00f9 avanzati.<\/p>\n

Gentili lettori!<\/b> Come funziona il processo di distribuzione delle nuove versioni dei progetti nel vostro ambiente di lavoro?<\/p>\n

\"La<\/a><\/noindex>
\n
Fonte: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u0412\u044b\u0432\u043e\u0434 \u043d\u043e\u0432\u043e\u0433\u043e \u0440\u0435\u043b\u0438\u0437\u0430 \u043f\u0440\u043e\u0435\u043a\u0442\u0430 \u0432 \u043f\u0440\u043e\u0434\u0430\u043a\u0448\u043d \u0442\u0440\u0435\u0431\u0443\u0435\u0442 \u0442\u0449\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0433\u043e \u0441\u043e\u0431\u043b\u044e\u0434\u0435\u043d\u0438\u044f \u0431\u0430\u043b\u0430\u043d\u0441\u0430 \u043c\u0435\u0436\u0434\u0443 \u0441\u043a\u043e\u0440\u043e\u0441\u0442\u044c\u044e \u0440\u0430\u0437\u0432\u0451\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u044f \u0438 \u043d\u0430\u0434\u0451\u0436\u043d\u043e\u0441\u0442\u044c\u044e \u0440\u0435\u0448\u0435\u043d\u0438\u044f. \u0412 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Slack \u0446\u0435\u043d\u044f\u0442 \u0431\u044b\u0441\u0442\u0440\u044b\u0435 \u0438\u0442\u0435\u0440\u0430\u0446\u0438\u0438, \u043a\u043e\u0440\u043e\u0442\u043a\u0438\u0435 \u0446\u0438\u043a\u043b\u044b \u043e\u0431\u0440\u0430\u0442\u043d\u043e\u0439 \u0441\u0432\u044f\u0437\u0438, \u043e\u043f\u0435\u0440\u0430\u0442\u0438\u0432\u043d\u0443\u044e \u0440\u0435\u0430\u043a\u0446\u0438\u044e \u043d\u0430 \u043e\u0431\u0440\u0430\u0449\u0435\u043d\u0438\u044f \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439. \u041a\u0440\u043e\u043c\u0435 \u0442\u043e\u0433\u043e, \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0438\u043c\u0435\u044e\u0442\u0441\u044f \u0441\u043e\u0442\u043d\u0438 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u043e\u0432, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u0442\u0440\u0435\u043c\u044f\u0442\u0441\u044f \u043a \u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u043e \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0439 \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0438\u0432\u043d\u043e\u0441\u0442\u0438. \u0410\u0432\u0442\u043e\u0440\u044b \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u0430, \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u043a\u043e\u0442\u043e\u0440\u043e\u0433\u043e \u043c\u044b \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u043f\u0443\u0431\u043b\u0438\u043a\u0443\u0435\u043c, \u0433\u043e\u0432\u043e\u0440\u044f\u0442, \u0447\u0442\u043e \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0430\u044f […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":77784,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-77783","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47La metodologia di distribuzione dei progetti utilizzata in Slack | ProHoster","description":"Il rilascio di una nuova versione di un progetto in produzione richiede un attento equilibrio tra la velocit\u00e0 di distribuzione e l'affidabilit\u00e0 della soluzione. In Slack si apprezzano iterazioni rapide, brevi cicli di feedback e una reazione tempestiva alle richieste degli utenti. Inoltre, l'azienda vanta centinaia di programmatori che mirano a una produttivit\u00e0 massima. Gli autori del materiale, la cui traduzione stiamo pubblicando oggi, affermano che l'azienda che","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/metodika-razvyortyvaniya-proektov-primenyaemaya-v-slack","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\u0435\u0442\u043e\u0434\u0438\u043a\u0430 \u0440\u0430\u0437\u0432\u0451\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u044f \u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432, \u043f\u0440\u0438\u043c\u0435\u043d\u044f\u0435\u043c\u0430\u044f \u0432 Slack | ProHoster","og:description":"\u0412\u044b\u0432\u043e\u0434 \u043d\u043e\u0432\u043e\u0433\u043e \u0440\u0435\u043b\u0438\u0437\u0430 \u043f\u0440\u043e\u0435\u043a\u0442\u0430 \u0432 \u043f\u0440\u043e\u0434\u0430\u043a\u0448\u043d \u0442\u0440\u0435\u0431\u0443\u0435\u0442 \u0442\u0449\u0430\u0442\u0435\u043b\u044c\u043d\u043e\u0433\u043e \u0441\u043e\u0431\u043b\u044e\u0434\u0435\u043d\u0438\u044f \u0431\u0430\u043b\u0430\u043d\u0441\u0430 \u043c\u0435\u0436\u0434\u0443 \u0441\u043a\u043e\u0440\u043e\u0441\u0442\u044c\u044e \u0440\u0430\u0437\u0432\u0451\u0440\u0442\u044b\u0432\u0430\u043d\u0438\u044f \u0438 \u043d\u0430\u0434\u0451\u0436\u043d\u043e\u0441\u0442\u044c\u044e \u0440\u0435\u0448\u0435\u043d\u0438\u044f. \u0412 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Slack \u0446\u0435\u043d\u044f\u0442 \u0431\u044b\u0441\u0442\u0440\u044b\u0435 \u0438\u0442\u0435\u0440\u0430\u0446\u0438\u0438, \u043a\u043e\u0440\u043e\u0442\u043a\u0438\u0435 \u0446\u0438\u043a\u043b\u044b \u043e\u0431\u0440\u0430\u0442\u043d\u043e\u0439 \u0441\u0432\u044f\u0437\u0438, \u043e\u043f\u0435\u0440\u0430\u0442\u0438\u0432\u043d\u0443\u044e \u0440\u0435\u0430\u043a\u0446\u0438\u044e \u043d\u0430 \u043e\u0431\u0440\u0430\u0449\u0435\u043d\u0438\u044f \u043f\u043e\u043b\u044c\u0437\u043e\u0432\u0430\u0442\u0435\u043b\u0435\u0439. \u041a\u0440\u043e\u043c\u0435 \u0442\u043e\u0433\u043e, \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0438\u043c\u0435\u044e\u0442\u0441\u044f \u0441\u043e\u0442\u043d\u0438 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u043e\u0432, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u0442\u0440\u0435\u043c\u044f\u0442\u0441\u044f \u043a \u043c\u0430\u043a\u0441\u0438\u043c\u0430\u043b\u044c\u043d\u043e \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0439 \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0438\u0432\u043d\u043e\u0441\u0442\u0438. \u0410\u0432\u0442\u043e\u0440\u044b \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u0430, \u043f\u0435\u0440\u0435\u0432\u043e\u0434 \u043a\u043e\u0442\u043e\u0440\u043e\u0433\u043e \u043c\u044b \u0441\u0435\u0433\u043e\u0434\u043d\u044f \u043f\u0443\u0431\u043b\u0438\u043a\u0443\u0435\u043c, \u0433\u043e\u0432\u043e\u0440\u044f\u0442, \u0447\u0442\u043e \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f, \u043a\u043e\u0442\u043e\u0440\u0430\u044f","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/metodika-razvyortyvaniya-proektov-primenyaemaya-v-slack","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":"2020-04-13T23:42:28+00:00","article:modified_time":"2020-04-13T23:42:28+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"77783","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":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 17:11:30","updated":"2022-09-28 09:37:25"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/77783","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=77783"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/77783\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/77784"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=77783"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=77783"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=77783"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}