{"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\/da\/blog\/administrirovanie\/nasha-realizatsiya-continuous-deployment-na-platformu-zakazchika","title":{"rendered":"Vores implementering af Continuous Deployment til kundens platform","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Vi i True Engineering har opsat en proces for kontinuerlig levering af opdateringer til kundens servere, og vi \u00f8nsker at dele denne erfaring.<\/p>\n<p>For at begynde udviklede vi et online system for kunden og implementerede det i vores eget Kubernetes-kluster. Nu er vores h\u00f8jt belastede l\u00f8sning flyttet til kundens platform, for hvilket vi har opsat en fuldt automatisk proces for Continuous Deployment. Dette har gjort, at vi har forkortet time-to-market \u2013 leveringen af \u00e6ndringer til produktionsmilj\u00f8et. <\/p>\n<p>I denne artikel vil vi fort\u00e6lle om alle faserne af processen for Continuous Deployment (CD) eller levering af opdateringer til kundens platform: <\/p>\n<ol>\n<li>hvordan denne proces starter, <\/li>\n<li>synkronisering med kundens Git-repository,<\/li>\n<li>bygning af backend og frontend,<\/li>\n<li>automatisk implementering af applikationen i testmilj\u00f8et, <\/li>\n<li>automatisk implementering i produktion. <\/li>\n<\/ol>\n<p>\nI processen vil vi dele detaljer om ops\u00e6tningen.<\/p>\n<p><img decoding=\"async\" alt=\"Vores implementering af Continuous Deployment til kundens platform\" 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. Start af CD<\/h3>\n<p>\nContinuous Deployment starter med, at udvikleren l\u00e6gger \u00e6ndringer i den relevante udgivelsesgren i vores Git-repository. <\/p>\n<p>Vores applikation er bygget p\u00e5 en mikrotjenestearkitektur, og alle dens komponenter opbevares i \u00e9t repository. Dette g\u00f8r det muligt at bygge og installere alle mikrotjenester, selvom en enkelt af dem er \u00e6ndret. <\/p>\n<p>Vi har organiseret arbejdet gennem \u00e9t repository af flere grunde: <\/p>\n<ul>\n<li>Bekvemmelighed ved udvikling \u2013 applikationen udvikles aktivt, s\u00e5 der kan arbejdes med hele koden p\u00e5 \u00e9n gang. <\/li>\n<li>En enkelt CI\/CD-pipeline, der garanterer, at applikationen som et samlet system gennemg\u00e5r alle tests og leveres til kundens prod-milj\u00f8. <\/li>\n<li>Vi undg\u00e5r forvirring omkring versioner \u2013 vi beh\u00f8ver ikke at opbevare et kort over versioner af mikrotjenester og beskrive konfigurationen for hver mikrotjeneste i Helm-scripts.<\/li>\n<\/ul>\n<h3>2. Synkronisering med kundens kildekode-Git-repository<\/h3>\n<p>\nForetagne \u00e6ndringer synkroniseres automatisk med kundens Git-repository. Der er opsat en bygning af applikationen, der starter efter opdateringen af grenen, og implementering til produktion. Begge processer foreg\u00e5r i deres milj\u00f8 fra Git-repositoryet. <\/p>\n<p>Vi kan ikke arbejde direkte med kundens repository, da vi har brug for vores egne udviklings- og testmilj\u00f8er. Vi bruger vores eget Git-repository til dette form\u00e5l \u2014 det er synkroniseret med deres Git-repository. S\u00e5 snart en udvikler uploader \u00e6ndringer til den relevante gren af vores repository, sender GitLab straks disse \u00e6ndringer til kunden.<\/p>\n<p><img decoding=\"async\" alt=\"Vores implementering af Continuous Deployment til kundens platform\" src=\"\/wp-content\/uploads\/2019\/04\/9e704f112649b77f0522fa60cfcfc2bb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDerefter skal der laves en bygning. Den best\u00e5r af flere trin: bygning af backend og frontend, test og levering til produktion.<\/p>\n<h3>3. Bygning af backend og frontend<\/h3>\n<p>\nBygningen af backend og frontend er to parallelle opgaver, som udf\u00f8res i GitLab Runner-systemet. Konfigurationen af den oprindelige bygning ligger i dette samme repository.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/docs.gitlab.com\/ce\/ci\/yaml\/\">Tutorial til skrivning af YAML-script til bygning i GitLab<\/a><\/noindex>.<\/p>\n<p>GitLab Runner henter koden fra det n\u00f8dvendige repository, bygger Java-applikationen med byggekommandoen og sender den til Docker registry. Her bygger vi backend og frontend, f\u00e5r Docker-images, som vi opbevarer i kundens repository. For at styre Docker-images bruger vi <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/palantir\/gradle-docker\">Gradle-plugin<\/a><\/noindex>.<\/p>\n<p>Vi synkroniserer versionerne af vores images med versionen af den release, som skal uploades til Docker. For at sikre en glat drift har vi foretaget flere indstillinger:<\/p>\n<p>1. Mellem testmilj\u00f8et og produktionsmilj\u00f8et genopbygges containere ikke. Vi har lavet parametriseringer, s\u00e5 den samme container kan fungere uden genopbygning med alle indstillinger, milj\u00f8variabler og services b\u00e5de i testmilj\u00f8et og i produktionen. <\/p>\n<p>2. For at opdatere applikationen gennem Helm skal du angive dens version. Vi har bygning af backend, frontend og opdatering af applikationen \u2013 dette er tre forskellige opgaver, s\u00e5 det er vigtigt at bruge den samme version af applikationen overalt. Til denne opgave bruger vi data fra Git-historikken, da vores K8S-klynge- og applikationskonfiguration er i det samme Git-repository.<\/p>\n<p>Vi f\u00e5r applikationens version fra resultaterne af kommandoen<br \/>\n<code>git describe --tags --abbrev=7<\/code>.<\/p>\n<h3>4. Automatisk deployment af alle \u00e6ndringer i testmilj\u00f8et (UAT) <\/h3>\n<p>\nDet n\u00e6ste trin i dette build-script er automatisk opdatering af K8S-klyngen. Dette sker, hvis hele applikationen er bygget, og alle artefakter er offentliggjort i Docker Registry. Derefter begynder opdateringen af testmilj\u00f8et.<\/p>\n<p>Opdateringen af klyngen startes med <noindex><a rel=\"nofollow\" href=\"https:\/\/helm.sh\/docs\/helm\/#helm-upgrade\">Helm Opdatering<\/a><\/noindex>. Hvis noget gik galt, vil Helm automatisk og selvst\u00e6ndigt rulle alle sine \u00e6ndringer tilbage. Det er ikke n\u00f8dvendigt at kontrollere dens arbejde. <\/p>\n<p>Vi leverer konfigurationen af K8S-klyngen sammen med opbygningen. S\u00e5 n\u00e6ste skridt er at opdatere den: configMaps, deployments, services, secrets og andre K8S-konfigurationer, som vi har \u00e6ndret. <\/p>\n<p>Efter dette starter Helm RollOut opdateringen af selve applikationen i testmilj\u00f8et. F\u00f8r applikationen vil blive implementeret p\u00e5 produktion. Dette g\u00f8res for at brugerne manuelt kan tjekke de forretningsfunktioner, vi har lagt i testmilj\u00f8et.<\/p>\n<h3>5. Automatisk udrulning af alle \u00e6ndringer til Prod <\/h3>\n<p>\nFor at udrulle opdateringen til produktionsmilj\u00f8et, er det kun \u00e9n knap i GitLab, der skal trykkes p\u00e5 \u2014 og containerne leveres straks til produktionsmilj\u00f8et.<\/p>\n<p>Den samme applikation kan fungere i forskellige milj\u00f8er \u2014 test og produktion \u2014 uden at blive ombygget. Vi bruger de samme artefakter uden at \u00e6ndre noget i applikationen, mens parametrene angives udefra. <\/p>\n<p>Fleksibel parametrisering af applikationens indstillinger afh\u00e6nger af det milj\u00f8, hvori applikationen skal k\u00f8re. Vi har taget alle milj\u00f8indstillinger udvendigt: alt parametriseres via K8S-konfiguration og Helm-parametre. N\u00e5r Helm udruller opbygningen i testmilj\u00f8et, anvendes testparametre, og i produktionsmilj\u00f8et \u2014 produktionsparametre.<\/p>\n<p>Den st\u00f8rste udfordring var at parameterisere alle de anvendte tjenester og variabler, der afh\u00e6nger af milj\u00f8et, og overs\u00e6tte dem til milj\u00f8variabler og beskrivelse-konfiguration af milj\u00f8parametre for Helm. <\/p>\n<p>I applikationsparametrene bruges milj\u00f8variabler. Deres v\u00e6rdier angives i containerne ved hj\u00e6lp af K8S configmap, som skabeloniseres ved hj\u00e6lp af Go-skabeloner. For eksempel kan tildelingen af en milj\u00f8variabel til dom\u00e6nenavnet g\u00f8res s\u00e5dan her:<\/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 denne variabel indeholder navnet p\u00e5 milj\u00f8et (prod, stage, UAT).<br \/>\n<b>.Values.app.properties.app_external_domain<\/b> \u2013 i denne variabel angiver vi den \u00f8nskede dom\u00e6ne i filen .Values.yaml <\/p>\n<p>N\u00e5r Helm opdaterer applikationen, opretter den konfigurationer fra skabelonerne i configmap.yaml og fylder v\u00e6rdien APP_EXTERNAL_DOMAIN med den n\u00f8dvendige v\u00e6rdi afh\u00e6ngigt af det milj\u00f8, opdateringen udf\u00f8res i. Denne variabel er allerede tilg\u00e6ngelig i containeren. Den kan tilg\u00e5s fra applikationen, hvilket betyder, at hver applikation i hvert milj\u00f8 vil have en forskellig v\u00e6rdi for denne variabel. <\/p>\n<p>Nyligt er der i Spring Cloud blevet tilf\u00f8jet st\u00f8tte til K8S, herunder arbejde med configMaps: <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/spring-cloud\/spring-cloud-kubernetes\">Spring Cloud Kubernetes<\/a><\/noindex>. Da projektet aktivt udvikles og \u00e6ndres radikalt, kan vi ikke bruge det i produktion. Men vi overv\u00e5ger aktivt dets tilstand og bruger det i DEV-konfigurationer. S\u00e5 snart det stabiliserer sig, vil vi skifte fra brug af milj\u00f8variabler til det.<\/p>\n<h3>I alt<\/h3>\n<p>\nS\u00e5, Continuous Deployment er opsat og fungerer. Alle opdateringer sker med \u00e9t tryk p\u00e5 en knap. Levering af \u00e6ndringer til produktionsmilj\u00f8et er automatisk. Og vigtigt er, at opdateringerne ikke stopper systemets drift. <\/p>\n<p><img decoding=\"async\" alt=\"Vores implementering af Continuous Deployment til kundens platform\" src=\"\/wp-content\/uploads\/2019\/04\/07d609d9a40f644cfdad2bdb88652af2.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n <\/p>\n<h3>Fremtidsplaner: automatisk database-migrering<\/h3>\n<p>\nVi har overvejet at opgradere databasen og hvordan man kan rulle disse \u00e6ndringer tilbage. For der k\u00f8rer to forskellige versioner af applikationen samtidig: den gamle version fungerer, mens den nye version starter. Vi vil kun slukke for den gamle version, n\u00e5r vi er sikre p\u00e5, at den nye version fungerer. Database-migreringen skal muligg\u00f8re drift med begge versioner af applikationen. <\/p>\n<p>Derfor kan vi ikke bare \u00e6ndre kolonnenavnet eller andre data. Men vi kan oprette en ny kolonne, kopiere data fra den gamle kolonne til den nye og skrive triggere, der samtidig vil kopiere og opdatere dataene i den anden kolonne ved opdatering. Efter en vellykket deployment af den nye version af applikationen, efter en post-launch supportperiode, kan vi fjerne den gamle kolonne og den un\u00f8dvendige trigger. <\/p>\n<p>Hvis den nye version af applikationen ikke fungerer korrekt, kan vi rulle tilbage til den tidligere version, inklusive den tidligere version af databasen. Med andre ord, vores \u00e6ndringer vil muligg\u00f8re samtidig drift med flere versioner af applikationen. <\/p>\n<p>Vi planl\u00e6gger at automatisere database-migreringen gennem K8S job og integrere den i CD-processen. Og vi vil bestemt dele denne erfaring p\u00e5 Habr.<br \/>\n<br \/>Kilde: <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.3 - 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.\" \/>\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\/nasha-realizatsiya-continuous-deployment-na-platformu-zakazchika\" \/>\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\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.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/da\/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\udd47Vores implementering af Continuous Deployment p\u00e5 kundens platform | ProHoster","description":"Hos True Engineering har vi indstillet processen for kontinuerlig levering af opdateringer til kundens servere, og vi \u00f8nsker at dele denne erfaring. F\u00f8rst har vi udviklet et online system til kunden og implementeret det hos dem.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/nasha-realizatsiya-continuous-deployment-na-platformu-zakazchika","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\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.","og:url":"https:\/\/prohoster.info\/da\/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\/da\/wp-json\/wp\/v2\/posts\/31377","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=31377"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/31377\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/23342"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=31377"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=31377"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=31377"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}