{"id":31377,"date":"2019-10-31T21:40:57","date_gmt":"2019-10-31T18:40:57","guid":{"rendered":"https:\/\/prohoster.info\/blog\/nasha-realizatsiya-continuous-deployment-na-platformu-zakazchika\/"},"modified":"2019-10-31T21:40:57","modified_gmt":"2019-10-31T18:40:57","slug":"nasha-realizatsiya-continuous-deployment-na-platformu-zakazchika","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/nasha-realizatsiya-continuous-deployment-na-platformu-zakazchika","title":{"rendered":"La nostra implementazione del Continuous Deployment sulla piattaforma del cliente","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>In True Engineering abbiamo configurato il processo di consegna continua degli aggiornamenti sui server del cliente e desideriamo condividere questa esperienza.<\/p>\n<p>Innanzitutto abbiamo sviluppato un sistema online per il cliente e lo abbiamo distribuito nel nostro cluster Kubernetes. Ora la nostra soluzione ad alta capacit\u00e0 \u00e8 stata trasferita sulla piattaforma del cliente, per la quale abbiamo impostato un processo di Continuous Deployment completamente automatico. Grazie a questo, abbiamo ridotto il time-to-market \u2013 la consegna delle modifiche nell'ambiente di produzione. <\/p>\n<p>In questo articolo parleremo di tutte le fasi del processo di Continuous Deployment (CD) o di consegna degli aggiornamenti sulla piattaforma del cliente: <\/p>\n<ol>\n<li>come inizia questo processo, <\/li>\n<li>sincronizzazione con il repository Git del cliente,<\/li>\n<li>compilazione del backend e del frontend,<\/li>\n<li>distribuzione automatica dell'applicazione nell'ambiente di test, <\/li>\n<li>distribuzione automatica in produzione. <\/li>\n<\/ol>\n<p>\nDurante il processo condivideremo i dettagli della configurazione.<\/p>\n<p><img decoding=\"async\" alt=\"La nostra implementazione del Continuous Deployment sulla piattaforma del cliente\" src=\"\/wp-content\/uploads\/2019\/04\/54be580319906344a6e2f091395ea7a7.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>1. Avvio del CD<\/h3>\n<p>\nIl Continuous Deployment inizia quando lo sviluppatore pubblica le modifiche nel ramo di rilascio del nostro repository Git. <\/p>\n<p>La nostra applicazione \u00e8 basata su un'architettura a microservizi e tutti i suoi componenti sono memorizzati in un unico repository. Grazie a ci\u00f2, tutti i microservizi vengono assemblati e installati anche se uno di essi \u00e8 stato modificato. <\/p>\n<p>Abbiamo organizzato il lavoro tramite un unico repository per diverse ragioni: <\/p>\n<ul>\n<li>Comodit\u00e0 di sviluppo: l'applicazione \u00e8 in continua evoluzione, quindi \u00e8 possibile lavorare su tutto il codice contemporaneamente. <\/li>\n<li>Un'unica pipeline CI\/CD che garantisce che l'applicazione, come un sistema unico, superi tutti i test e venga consegnata nell'ambiente di produzione del cliente. <\/li>\n<li>Escludiamo confusione nelle versioni: non dobbiamo conservare una mappa delle versioni dei microservizi n\u00e9 descrivere la propria configurazione in script Helm per ciascun microservizio.<\/li>\n<\/ul>\n<h3>2. Sincronizzazione con il repository Git del codice sorgente del cliente<\/h3>\n<p>\nLe modifiche apportate vengono automaticamente sincronizzate con il repository Git del cliente. L\u00ec \u00e8 configurata la build dell'applicazione, che viene avviata dopo l'aggiornamento del ramo, e il deployment in produzione. Entrambi i processi avvengono nel loro ambiente dal repository Git. <\/p>\n<p>Non possiamo lavorare direttamente con il repository del cliente, poich\u00e9 abbiamo bisogno di ambienti propri per lo sviluppo e il testing. Utilizziamo a tal fine il nostro repository Git, che \u00e8 sincronizzato con il loro repository Git. Non appena uno sviluppatore pubblica modifiche nel ramo corrispondente del nostro repository, GitLab invia immediatamente queste modifiche al cliente.<\/p>\n<p><img decoding=\"async\" alt=\"La nostra implementazione del Continuous Deployment sulla piattaforma del cliente\" src=\"\/wp-content\/uploads\/2019\/04\/9e704f112649b77f0522fa60cfcfc2bb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDopo questo, \u00e8 necessario effettuare la costruzione. Questa consiste in diverse fasi: costruzione del backend e del frontend, testing e consegna in produzione.<\/p>\n<h3>3. Costruzione del backend e del frontend<\/h3>\n<p>\nLa costruzione del backend e del frontend \u00e8 composta da due compiti paralleli, realizzati nel sistema GitLab Runner. La configurazione della costruzione iniziale si trova nello stesso repository.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/docs.gitlab.com\/ce\/ci\/yaml\/\">Tutorial per scrivere uno script YAML per la costruzione in GitLab<\/a><\/noindex>.<\/p>\n<p>GitLab Runner preleva il codice dal repository corretto, costruisce l'applicazione Java con il comando di build e lo invia al Docker registry. Qui costruiamo il backend e il frontend, otteniamo le immagini Docker, che siamo in grado di caricare nel repository del cliente. Per gestire le immagini Docker, utilizziamo <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/palantir\/gradle-docker\">il plugin Gradle<\/a><\/noindex>.<\/p>\n<p>Sincronizziamo le versioni delle nostre immagini con la versione di rilascio che sar\u00e0 pubblicata in Docker. Per un funzionamento fluido, abbiamo apportato alcune configurazioni:<\/p>\n<p>1. Tra l'ambiente di test e quello di produzione, i container non vengono ricostruiti. Abbiamo implementato la parametrizzazione affinch\u00e9 lo stesso container possa funzionare senza ricostruzione con tutte le configurazioni, variabili ambientali e servizi sia nell'ambiente di test che in produzione. <\/p>\n<p>2. Per aggiornare l'applicazione tramite Helm \u00e8 necessario specificarne la versione. Abbiamo la build del backend, del frontend e l'aggiornamento dell'applicazione come tre compiti distinti, quindi \u00e8 importante utilizzare ovunque la stessa versione dell'applicazione. Per questo utilizziamo i dati dalla cronologia Git, poich\u00e9 la nostra configurazione del cluster K8S e dell'applicazione si trova nello stesso repository Git.<\/p>\n<p>Otteniamo la versione dell'applicazione dai risultati dell'esecuzione del comando<br \/>\n<code>git describe --tags --abbrev=7<\/code>.<\/p>\n<h3>4. Distribuzione automatica di tutte le modifiche nell'ambiente di test (UAT) <\/h3>\n<p>\nIl prossimo passo in questo script di build \u00e8 l'aggiornamento automatico del cluster K8S. Questo avviene a condizione che tutte le applicazioni siano state costruite e tutti gli artefatti pubblicati nel Docker Registry. Dopo di che, si avvia l'aggiornamento dell'ambiente di test.<\/p>\n<p>L'aggiornamento del cluster viene avviato tramite <noindex><a rel=\"nofollow\" href=\"https:\/\/helm.sh\/docs\/helm\/#helm-upgrade\">Helm Update<\/a><\/noindex>. Se qualcosa va storto, Helm annuller\u00e0 automaticamente tutte le modifiche apportate. Non \u00e8 necessario monitorarne il funzionamento. <\/p>\n<p>Forniamo insieme alla build la configurazione del cluster K8S. Pertanto, il prossimo passo \u00e8 aggiornarla: configMaps, deployments, services, secrets e qualsiasi altra configurazione K8S che abbiamo modificato. <\/p>\n<p>Successivamente, Helm avvia un aggiornamento RollOut dell'applicazione stessa nell'ambiente di test. Prima che l'applicazione venga distribuita in produzione. Questo \u00e8 fatto affinch\u00e9 gli utenti possano verificare manualmente le funzionalit\u00e0 aziendali che abbiamo rilasciato nell'ambiente di test.<\/p>\n<h3>5. Distribuzione automatica di tutte le modifiche in Prod <\/h3>\n<p>\nPer distribuire l'aggiornamento nell'ambiente di produzione, \u00e8 sufficiente premere un pulsante in GitLab \u2014 e i container vengono immediatamente inviati all'ambiente di produzione.<\/p>\n<p>La stessa applicazione pu\u00f2 funzionare senza ricompilazione in ambienti diversi \u2014 test e produzione. Utilizziamo gli stessi artefatti senza modificare nulla nell'applicazione, configurando i parametri esternamente. <\/p>\n<p>La flessibile parametrizzazione delle impostazioni dell'applicazione dipende dall'ambiente in cui l'applicazione verr\u00e0 eseguita. Abbiamo estratto tutte le impostazioni degli ambienti all'esterno: tutto viene parametrizzato attraverso la configurazione K8S e i parametri Helm. Quando Helm distribuisce la build nell'ambiente di test, vengono applicati parametri di test, mentre nell'ambiente di produzione si applicano parametri di prodotto.<\/p>\n<p>La parte pi\u00f9 difficile \u00e8 stata parametrizzare tutti i servizi e le variabili utilizzati, che dipendono dall'ambiente, e trasformarli in variabili ambientali e nella descrizione della configurazione dei parametri per Helm. <\/p>\n<p>Nei parametri dell'applicazione vengono utilizzate variabili ambientali. I loro valori vengono definiti nei contenitori tramite K8S configmap, che \u00e8 templateizzato utilizzando i template Go. Ad esempio, per assegnare una variabile ambientale per il nome del dominio, \u00e8 possibile fare cos\u00ec:<\/p>\n<p><code>APP_EXTERNAL_DOMAIN: {{ (pluck .Values.global.env .Values.app.properties.app_external_domain | first) }}<\/code><\/p>\n<p><b>.Values.global.env <\/b>\u2013 in questa variabile viene memorizzato il nome dell'ambiente (prod, stage, UAT).<br \/>\n<b>.Values.app.properties.app_external_domain<\/b> \u2013 in questa variabile definiamo nel file .Values.yaml il dominio necessario <\/p>\n<p>Durante l'aggiornamento dell'applicazione, Helm crea il file configmap.yaml dai modelli e riempie il valore di APP_EXTERNAL_DOMAIN con il valore corretto a seconda dell'ambiente in cui l'aggiornamento dell'applicazione viene avviato. Questa variabile viene impostata gi\u00e0 nel contenitore. L'accesso \u00e8 disponibile dall'applicazione, quindi in ogni ambiente dell'applicazione ci sar\u00e0 un valore diverso per questa variabile. <\/p>\n<p>Recentemente, Spring Cloud ha introdotto il supporto per K8S, inclusa la gestione dei configMaps: <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/spring-cloud\/spring-cloud-kubernetes\">Spring Cloud Kubernetes<\/a><\/noindex>. Attualmente, il progetto \u00e8 in fase di sviluppo attivo e sta subendo cambiamenti radicali, quindi non possiamo utilizzarlo in produzione. Ma monitoriamo attentamente il suo stato e lo utilizziamo nelle configurazioni DEV. Appena sar\u00e0 stabilizzato, passeremo dall'uso delle variabili d'ambiente a questo.<\/p>\n<h3>Totale<\/h3>\n<p>\nQuindi, il Continuous Deployment \u00e8 impostato e funziona. Tutti gli aggiornamenti avvengono con un solo clic. La consegna delle modifiche nell'ambiente di produzione \u00e8 automatica. E, cosa importante, gli aggiornamenti non interrompono il funzionamento del sistema. <\/p>\n<p><img decoding=\"async\" alt=\"La nostra implementazione del Continuous Deployment sulla piattaforma del cliente\" src=\"\/wp-content\/uploads\/2019\/04\/07d609d9a40f644cfdad2bdb88652af2.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n <\/p>\n<h3>Piani futuri: migrazione automatica del database<\/h3>\n<p>\nStiamo considerando di eseguire l'upgrade del database e la possibilit\u00e0 di ripristinare queste modifiche. Infatti, due versioni diverse dell'applicazione sono attive contemporaneamente: la versione precedente continua a funzionare, mentre la nuova viene implementata. Disattiveremo la versione precedente solo quando saremo certi che la nuova versione funzioni correttamente. La migrazione del database deve consentire il funzionamento di entrambe le versioni dell'applicazione. <\/p>\n<p>Pertanto, non possiamo semplicemente cambiare il nome di una colonna o altri dati. Tuttavia, possiamo creare una nuova colonna, copiare i dati dalla colonna precedente e scrivere dei trigger che, all'aggiornamento dei dati, copieranno e aggiorneranno simultaneamente le informazioni nell'altra colonna. Dopo un deploy riuscito della nuova versione dell'applicazione e dopo il periodo di supporto post-lancio, saremo in grado di rimuovere la colonna precedente e il trigger diventato superfluo. <\/p>\n<p>Se la nuova versione dell'applicazione non funziona correttamente, possiamo tornare alla versione precedente, inclusa la precedente versione del database. In altre parole, le nostre modifiche consentiranno di lavorare contemporaneamente con pi\u00f9 versioni dell'applicazione. <\/p>\n<p>Pianifichiamo l'automazione della migrazione del database tramite un job K8S, integrandola nel processo di CD. Condivideremo sicuramente questa esperienza su Habr.<br \/>\n<br \/>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/true_engineering\/blog\/447812\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041c\u044b \u0432 True Engineering \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u043b\u0438 \u043f\u0440\u043e\u0446\u0435\u0441\u0441 \u043d\u0435\u043f\u0440\u0435\u0440\u044b\u0432\u043d\u043e\u0439 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 \u043e\u0431\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u0439 \u043d\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u0430 \u0437\u0430\u043a\u0430\u0437\u0447\u0438\u043a\u0430 \u0438 \u0445\u043e\u0442\u0438\u043c \u043f\u043e\u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u044d\u0442\u0438\u043c \u043e\u043f\u044b\u0442\u043e\u043c. \u0414\u043b\u044f \u043d\u0430\u0447\u0430\u043b\u0430 \u043c\u044b \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0430\u043b\u0438 \u043e\u043d\u043b\u0430\u0439\u043d \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u0434\u043b\u044f \u0437\u0430\u043a\u0430\u0437\u0447\u0438\u043a\u0430 \u0438 \u0440\u0430\u0437\u0432\u0435\u0440\u043d\u0443\u043b\u0438 \u0435\u0451 \u0432 \u0441\u043e\u0431\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u043c \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 Kubernetes. \u0422\u0435\u043f\u0435\u0440\u044c \u043d\u0430\u0448\u0435 \u0432\u044b\u0441\u043e\u043a\u043e\u043d\u0430\u0433\u0440\u0443\u0436\u0435\u043d\u043d\u043e\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u0435 \u043f\u0435\u0440\u0435\u0435\u0445\u0430\u043b\u043e \u043d\u0430 \u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u0443 \u0437\u0430\u043a\u0430\u0437\u0447\u0438\u043a\u0430, \u0434\u043b\u044f \u0447\u0435\u0433\u043e \u043c\u044b \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u043b\u0438 \u043f\u043e\u043b\u043d\u043e\u0441\u0442\u044c\u044e \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u043f\u0440\u043e\u0446\u0435\u0441\u0441 Continuous Deployment. \u0411\u043b\u0430\u0433\u043e\u0434\u0430\u0440\u044f \u044d\u0442\u043e\u043c\u0443, \u043c\u044b \u0443\u0441\u043a\u043e\u0440\u0438\u043b\u0438 time-to-market \u2013 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":23342,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-31377","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.0.1 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041c\u044b \u0432 True Engineering \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u043b\u0438 \u043f\u0440\u043e\u0446\u0435\u0441\u0441 \u043d\u0435\u043f\u0440\u0435\u0440\u044b\u0432\u043d\u043e\u0439 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 \u043e\u0431\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u0439 \u043d\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u0430 \u0437\u0430\u043a\u0430\u0437\u0447\u0438\u043a\u0430 \u0438 \u0445\u043e\u0442\u0438\u043c \u043f\u043e\u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u044d\u0442\u0438\u043c \u043e\u043f\u044b\u0442\u043e\u043c. \u0414\u043b\u044f \u043d\u0430\u0447\u0430\u043b\u0430 \u043c\u044b \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0430\u043b\u0438 \u043e\u043d\u043b\u0430\u0439\u043d \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u0434\u043b\u044f \u0437\u0430\u043a\u0430\u0437\u0447\u0438\u043a\u0430 \u0438 \u0440\u0430\u0437\u0432\u0435\u0440\u043d\u0443\u043b\u0438 \u0435\u0451 \u0432 \u0441\u043e\u0431\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u043c \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 Kubernetes. \u0422\u0435\u043f\u0435\u0440\u044c \u043d\u0430\u0448\u0435 \u0432\u044b\u0441\u043e\u043a\u043e\u043d\u0430\u0433\u0440\u0443\u0436\u0435\u043d\u043d\u043e\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u0435 \u043f\u0435\u0440\u0435\u0435\u0445\u0430\u043b\u043e \u043d\u0430 \u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u0443 \u0437\u0430\u043a\u0430\u0437\u0447\u0438\u043a\u0430, \u0434\u043b\u044f \u0447\u0435\u0433\u043e \u043c\u044b \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u043b\u0438 \u043f\u043e\u043b\u043d\u043e\u0441\u0442\u044c\u044e \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u043f\u0440\u043e\u0446\u0435\u0441\u0441 Continuous Deployment. \u0411\u043b\u0430\u0433\u043e\u0434\u0430\u0440\u044f \u044d\u0442\u043e\u043c\u0443, \u043c\u044b \u0443\u0441\u043a\u043e\u0440\u0438\u043b\u0438 time-to-market \u2013\" \/>\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\/nasha-realizatsiya-continuous-deployment-na-platformu-zakazchika\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.0.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\u041d\u0430\u0448\u0430 \u0440\u0435\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u044f Continuous Deployment \u043d\u0430 \u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u0443 \u0437\u0430\u043a\u0430\u0437\u0447\u0438\u043a\u0430 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041c\u044b \u0432 True Engineering \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u043b\u0438 \u043f\u0440\u043e\u0446\u0435\u0441\u0441 \u043d\u0435\u043f\u0440\u0435\u0440\u044b\u0432\u043d\u043e\u0439 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 \u043e\u0431\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u0439 \u043d\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u0430 \u0437\u0430\u043a\u0430\u0437\u0447\u0438\u043a\u0430 \u0438 \u0445\u043e\u0442\u0438\u043c \u043f\u043e\u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u044d\u0442\u0438\u043c \u043e\u043f\u044b\u0442\u043e\u043c. \u0414\u043b\u044f \u043d\u0430\u0447\u0430\u043b\u0430 \u043c\u044b \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0430\u043b\u0438 \u043e\u043d\u043b\u0430\u0439\u043d \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u0434\u043b\u044f \u0437\u0430\u043a\u0430\u0437\u0447\u0438\u043a\u0430 \u0438 \u0440\u0430\u0437\u0432\u0435\u0440\u043d\u0443\u043b\u0438 \u0435\u0451 \u0432 \u0441\u043e\u0431\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u043c \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 Kubernetes. \u0422\u0435\u043f\u0435\u0440\u044c \u043d\u0430\u0448\u0435 \u0432\u044b\u0441\u043e\u043a\u043e\u043d\u0430\u0433\u0440\u0443\u0436\u0435\u043d\u043d\u043e\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u0435 \u043f\u0435\u0440\u0435\u0435\u0445\u0430\u043b\u043e \u043d\u0430 \u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u0443 \u0437\u0430\u043a\u0430\u0437\u0447\u0438\u043a\u0430, \u0434\u043b\u044f \u0447\u0435\u0433\u043e \u043c\u044b \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u043b\u0438 \u043f\u043e\u043b\u043d\u043e\u0441\u0442\u044c\u044e \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u043f\u0440\u043e\u0446\u0435\u0441\u0441 Continuous Deployment. \u0411\u043b\u0430\u0433\u043e\u0434\u0430\u0440\u044f \u044d\u0442\u043e\u043c\u0443, \u043c\u044b \u0443\u0441\u043a\u043e\u0440\u0438\u043b\u0438 time-to-market \u2013\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/nasha-realizatsiya-continuous-deployment-na-platformu-zakazchika\" \/>\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-31T18:40:57+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:40:57+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\udd47La nostra implementazione del Continuous Deployment sulla piattaforma del cliente | ProHoster","description":"In True Engineering abbiamo configurato il processo di distribuzione continua degli aggiornamenti sui server dei clienti e desideriamo condividere questa esperienza. Innanzitutto, abbiamo sviluppato un sistema online per il cliente e lo abbiamo implementato nel nostro cluster Kubernetes. Ora la nostra soluzione ad alto carico \u00e8 stata trasferita sulla piattaforma del cliente, per la quale abbiamo configurato un processo di Continuous Deployment completamente automatizzato. Grazie a questo, abbiamo accelerato il time-to-market \u2013","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/nasha-realizatsiya-continuous-deployment-na-platformu-zakazchika","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\u041d\u0430\u0448\u0430 \u0440\u0435\u0430\u043b\u0438\u0437\u0430\u0446\u0438\u044f Continuous Deployment \u043d\u0430 \u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u0443 \u0437\u0430\u043a\u0430\u0437\u0447\u0438\u043a\u0430 | ProHoster","og:description":"\u041c\u044b \u0432 True Engineering \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u043b\u0438 \u043f\u0440\u043e\u0446\u0435\u0441\u0441 \u043d\u0435\u043f\u0440\u0435\u0440\u044b\u0432\u043d\u043e\u0439 \u0434\u043e\u0441\u0442\u0430\u0432\u043a\u0438 \u043e\u0431\u043d\u043e\u0432\u043b\u0435\u043d\u0438\u0439 \u043d\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u0430 \u0437\u0430\u043a\u0430\u0437\u0447\u0438\u043a\u0430 \u0438 \u0445\u043e\u0442\u0438\u043c \u043f\u043e\u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u044d\u0442\u0438\u043c \u043e\u043f\u044b\u0442\u043e\u043c. \u0414\u043b\u044f \u043d\u0430\u0447\u0430\u043b\u0430 \u043c\u044b \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0430\u043b\u0438 \u043e\u043d\u043b\u0430\u0439\u043d \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u0434\u043b\u044f \u0437\u0430\u043a\u0430\u0437\u0447\u0438\u043a\u0430 \u0438 \u0440\u0430\u0437\u0432\u0435\u0440\u043d\u0443\u043b\u0438 \u0435\u0451 \u0432 \u0441\u043e\u0431\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u043c \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435 Kubernetes. \u0422\u0435\u043f\u0435\u0440\u044c \u043d\u0430\u0448\u0435 \u0432\u044b\u0441\u043e\u043a\u043e\u043d\u0430\u0433\u0440\u0443\u0436\u0435\u043d\u043d\u043e\u0435 \u0440\u0435\u0448\u0435\u043d\u0438\u0435 \u043f\u0435\u0440\u0435\u0435\u0445\u0430\u043b\u043e \u043d\u0430 \u043f\u043b\u0430\u0442\u0444\u043e\u0440\u043c\u0443 \u0437\u0430\u043a\u0430\u0437\u0447\u0438\u043a\u0430, \u0434\u043b\u044f \u0447\u0435\u0433\u043e \u043c\u044b \u043d\u0430\u0441\u0442\u0440\u043e\u0438\u043b\u0438 \u043f\u043e\u043b\u043d\u043e\u0441\u0442\u044c\u044e \u0430\u0432\u0442\u043e\u043c\u0430\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u0439 \u043f\u0440\u043e\u0446\u0435\u0441\u0441 Continuous Deployment. \u0411\u043b\u0430\u0433\u043e\u0434\u0430\u0440\u044f \u044d\u0442\u043e\u043c\u0443, \u043c\u044b \u0443\u0441\u043a\u043e\u0440\u0438\u043b\u0438 time-to-market \u2013","og:url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/nasha-realizatsiya-continuous-deployment-na-platformu-zakazchika","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-31T18:40:57+00:00","article:modified_time":"2019-10-31T18:40:57+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"31377","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 05:52:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 03:18:39","updated":"2026-01-21 05:52:19","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\/31377","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=31377"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/31377\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/23342"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=31377"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=31377"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=31377"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}