{"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\/de\/blog\/administrirovanie\/nasha-realizatsiya-continuous-deployment-na-platformu-zakazchika","title":{"rendered":"Unsere Implementierung des Continuous Deployment auf die Plattform des Kunden","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Wir bei True Engineering haben den Prozess der kontinuierlichen Bereitstellung von Updates auf die Server des Kunden eingerichtet und m\u00f6chten diese Erfahrung teilen.<\/p>\n<p>Zu Beginn haben wir ein Online-System f\u00fcr den Kunden entwickelt und in seinem eigenen Kubernetes-Cluster bereitgestellt. Nun ist unsere hoch performante L\u00f6sung auf die Plattform des Kunden umgezogen, f\u00fcr die wir den vollst\u00e4ndig automatisierten Prozess der Continuous Deployment eingerichtet haben. Dadurch haben wir die time-to-market \u2013 die Lieferung von \u00c4nderungen in die Produktionsumgebung \u2013 beschleunigt. <\/p>\n<p>In diesem Artikel werden wir alle Schritte des Prozesses der Continuous Deployment (CD) oder der Bereitstellung von Updates auf der Plattform des Kunden beschreiben: <\/p>\n<ol>\n<li>wie dieser Prozess beginnt, <\/li>\n<li>Synchronisation mit dem Git-Repository des Kunden,<\/li>\n<li>Bau des Backends und Frontends,<\/li>\n<li>automatische Bereitstellung der Anwendung in der Testumgebung, <\/li>\n<li>automatische Bereitstellung in Prod. <\/li>\n<\/ol>\n<p>\nIm Prozess werden wir Details zur Konfiguration teilen.<\/p>\n<p><img decoding=\"async\" alt=\"Unsere Implementierung des Continuous Deployment auf die Plattform des Kunden\" 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 CD<\/h3>\n<p>\nDas Continuous Deployment beginnt damit, dass der Entwickler \u00c4nderungen in den Release-Branch unseres Git-Repositories hochl\u00e4dt. <\/p>\n<p>Unsere Anwendung basiert auf einer Microservices-Architektur, und alle ihre Komponenten werden in einem Repository gespeichert. Dadurch werden alle Microservices gesammelt und installiert, selbst wenn sich nur einer von ihnen ge\u00e4ndert hat. <\/p>\n<p>Wir haben die Arbeit \u00fcber ein einziges Repository aus mehreren Gr\u00fcnden organisiert: <\/p>\n<ul>\n<li>Entwicklungsfreundlichkeit \u2013 die Anwendung wird aktiv weiterentwickelt, daher kann sofort am gesamten Code gearbeitet werden. <\/li>\n<li>Ein einheitlicher CI\/CD-Pipeline, die gew\u00e4hrleistet, dass die Anwendung als Einheit alle Tests durchl\u00e4uft und in die Produktionsumgebung des Kunden geliefert wird. <\/li>\n<li>Verwirrung bez\u00fcglich der Versionen wird ausgeschlossen \u2013 wir m\u00fcssen keinen Versionsplan der Microservices aufbewahren und f\u00fcr jeden Microservice seine eigene Konfiguration in Helm-Skripten beschreiben.<\/li>\n<\/ul>\n<h3>2. Synchronisation mit dem Git-Repository des Kunden<\/h3>\n<p>\nDie vorgenommenen \u00c4nderungen werden automatisch mit dem Git-Repository des Kunden synchronisiert. Dort ist der Bau der Anwendung eingerichtet, der nach dem Update des Branches gestartet wird, sowie das Deployment in Prod. Beide Prozesse finden in ihrem Umfeld aus dem Git-Repository statt. <\/p>\n<p>Wir k\u00f6nnen nicht direkt mit dem Repository des Kunden arbeiten, da wir eigene Umgebungen f\u00fcr die Entwicklung und das Testen ben\u00f6tigen. Zu diesem Zweck verwenden wir unser eigenes Git-Repository, das mit ihrem Git-Repository synchronisiert ist. Sobald der Entwickler \u00c4nderungen in den entsprechenden Branch unseres Repositories hochl\u00e4dt, sendet GitLab diese \u00c4nderungen sofort an den Kunden.<\/p>\n<p><img decoding=\"async\" alt=\"Unsere Implementierung des Continuous Deployment auf die Plattform des Kunden\" src=\"\/wp-content\/uploads\/2019\/04\/9e704f112649b77f0522fa60cfcfc2bb.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nDanach muss ein Build erstellt werden. Dieser besteht aus mehreren Phasen: dem Build des Backends und Frontends, dem Testen und der Bereitstellung in der Produktion.<\/p>\n<h3>3. Build des Backends und Frontends<\/h3>\n<p>\nDer Build des Backends und Frontends sind zwei parallele Aufgaben, die im GitLab Runner durchgef\u00fchrt werden. Die Konfiguration des urspr\u00fcnglichen Builds befindet sich im selben Repository.<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"https:\/\/docs.gitlab.com\/ce\/ci\/yaml\/\">Tutorial zur Erstellung eines YAML-Skripts f\u00fcr den Build in GitLab<\/a><\/noindex>.<\/p>\n<p>GitLab Runner holt den Code aus dem ben\u00f6tigten Repository, erstellt mit dem Build-Befehl die Java-Anwendung und sendet sie in das Docker-Registry. Hier bauen wir Backend und Frontend, erzeugen Docker-Images, die wir im Repository des Kunden ablegen. Zur Verwaltung der Docker-Images verwenden wir <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/palantir\/gradle-docker\">das Gradle-Plugin<\/a><\/noindex>.<\/p>\n<p>Wir synchronisieren die Versionen unserer Images mit der Versionsnummer des Releases, das in Docker bereitgestellt wird. F\u00fcr einen reibungslosen Ablauf haben wir einige Einstellungen vorgenommen:<\/p>\n<p>1. Zwischen der Testumgebung und der Produktionsumgebung werden die Container nicht neu erstellt. Wir haben Parameterisierung vorgenommen, damit derselbe Container ohne Neuaufbau mit allen Einstellungen, Umgebungsvariablen und Services sowohl in der Testumgebung als auch in der Produktion arbeiten kann. <\/p>\n<p>2. Um die Anwendung \u00fcber Helm zu aktualisieren, muss die Versionsnummer angegeben werden. Unser Build des Backends, Frontends und die Aktualisierung der Anwendung sind drei verschiedene Aufgaben, daher ist es wichtig, \u00fcberall dieselbe Version der Anwendung zu verwenden. F\u00fcr diese Aufgabe verwenden wir Daten aus der Git-Historie, da sich die Konfiguration des K8S-Clusters und der Anwendung im selben Git-Repository befindet.<\/p>\n<p>Die Versionsnummer der Anwendung erhalten wir aus den Ergebnissen der Ausf\u00fchrung des Befehls<br \/>\n<code>git describe --tags --abbrev=7<\/code>.<\/p>\n<h3>4. Automatisierte Bereitstellung aller \u00c4nderungen in der Testumgebung (UAT) <\/h3>\n<p>\nDer n\u00e4chste Schritt in diesem Build-Skript ist die automatische Aktualisierung des K8S-Clusters. Dies erfolgt unter der Voraussetzung, dass die gesamte Anwendung gebaut wurde und alle Artefakte im Docker Registry ver\u00f6ffentlicht sind. Danach wird die Aktualisierung der Testumgebung gestartet.<\/p>\n<p>Die Aktualisierung des Clusters wird mit Hilfe von <noindex><a rel=\"nofollow\" href=\"https:\/\/helm.sh\/docs\/helm\/#helm-upgrade\">Helm-Update<\/a><\/noindex>. Wenn hierbei etwas schiefgeht, rollt Helm automatisch und selbstst\u00e4ndig alle \u00c4nderungen zur\u00fcck. Seine Arbeit muss nicht \u00fcberwacht werden. <\/p>\n<p>Wir liefern zusammen mit dem Build die Konfiguration des K8S-Clusters. Daher wird im n\u00e4chsten Schritt diese aktualisiert: configMaps, Deployments, Services, Secrets und alle anderen K8S-Konfigurationen, die wir ge\u00e4ndert haben. <\/p>\n<p>Danach startet Helm die RollOut-Aktualisierung der Anwendung in der Testumgebung. Bevor die Anwendung in der Produktion bereitgestellt wird. Dies geschieht, damit die Benutzer die von uns bereitgestellten Gesch\u00e4ftsfunktionen manuell \u00fcberpr\u00fcfen k\u00f6nnen, die wir in die Testumgebung hochgeladen haben.<\/p>\n<h3>5. Automatische Bereitstellung aller \u00c4nderungen in der Produktion <\/h3>\n<p>\nUm das Update in die Produktionsumgebung bereitzustellen, m\u00fcssen Sie nur einen Knopf in GitLab dr\u00fccken - und die Container werden sofort in die Produktionsumgebung geliefert.<\/p>\n<p>Dasselbe Anwendung kann ohne Neuaufbau in verschiedenen Umgebungen - Test und Produktion - arbeiten. Wir verwenden dieselben Artefakte, ohne etwas in der Anwendung zu \u00e4ndern, w\u00e4hrend die Parameter von au\u00dfen vorgegeben werden. <\/p>\n<p>Die flexible Parametrisierung der Anwendungsparameter h\u00e4ngt von der Umgebung ab, in der die Anwendung ausgef\u00fchrt wird. Wir haben alle Umgebungsparameter nach au\u00dfen verlagert: alles wird \u00fcber die K8S-Konfiguration und die Helm-Parameter parametriert. Wenn Helm den Build in der Testumgebung bereitstellt, werden Testparameter angewendet, und in der Produktionsumgebung - Produktionsparameter.<\/p>\n<p>Die schwierigste Aufgabe war es, alle verwendeten Dienste und Variablen zu parametrieren, die von der Umgebung abh\u00e4ngen, und sie in Umgebungsvariablen und die Beschreibung-Konfiguration der Umgebungsparameter f\u00fcr Helm zu \u00fcberf\u00fchren. <\/p>\n<p>In den Anwendungsparametern werden Umgebungsvariablen verwendet. Ihre Werte werden in den Containern mit Hilfe von K8S configmap angegeben, das mit Go-Vorlagen templatiert wird. Zum Beispiel kann die Festlegung einer Umgebungsvariablen f\u00fcr den Domainnamen so erfolgen:<\/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 dieser Variablen wird der Name der Umgebung (prod, stage, UAT) gespeichert.<br \/>\n<b>.Values.app.properties.app_external_domain<\/b> \u2013 in dieser Variablen geben wir in der Datei .Values.yaml die ben\u00f6tigte Domain an. <\/p>\n<p>Beim Update der Anwendung erstellt Helm die configmap.yaml-Dateien aus Vorlagen und f\u00fcllt den Wert APP_EXTERNAL_DOMAIN mit dem erforderlichen Wert abh\u00e4ngig von der Umgebung, in der das Update der Anwendung gestartet wird. Diese Variable wird bereits im Container gesetzt. Der Zugriff darauf erfolgt \u00fcber die Anwendung, daher hat jede Umgebung der Anwendung einen unterschiedlichen Wert f\u00fcr diese Variable. <\/p>\n<p>In Bezug auf die k\u00fcrzliche Einf\u00fchrung in Spring Cloud gibt es nun Unterst\u00fctzung f\u00fcr K8S, einschlie\u00dflich der Arbeit mit configMaps: <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/spring-cloud\/spring-cloud-kubernetes\">Spring Cloud Kubernetes<\/a><\/noindex>. Da sich das Projekt aktiv entwickelt und sich grundlegend ver\u00e4ndert, k\u00f6nnen wir es derzeit nicht in der Produktion verwenden. Wir \u00fcberwachen jedoch seinen Zustand aktiv und verwenden es in DEV-Konfigurationen. Sobald es stabil ist, werden wir auf die Verwendung von Umgebungsvariablen umschalten.<\/p>\n<h3>Insgesamt<\/h3>\n<p>\nAlso, Continuous Deployment ist eingerichtet und funktioniert. Alle Updates erfolgen mit einem einzigen Knopfdruck. Die Bereitstellung von \u00c4nderungen in die Produktionsumgebung ist automatisch. Und, was wichtig ist, die Updates unterbrechen nicht den Betrieb des Systems. <\/p>\n<p><img decoding=\"async\" alt=\"Unsere Implementierung des Continuous Deployment auf die Plattform des Kunden\" src=\"\/wp-content\/uploads\/2019\/04\/07d609d9a40f644cfdad2bdb88652af2.jpg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n <\/p>\n<h3>Pl\u00e4ne f\u00fcr die Zukunft: automatische Migration der Datenbank<\/h3>\n<p>\nWir haben \u00fcber ein Upgrade der Datenbank nachgedacht und die M\u00f6glichkeit, diese \u00c4nderungen zur\u00fcckzusetzen. Immerhin arbeiten gleichzeitig zwei verschiedene Versionen der Anwendung: die alte l\u00e4uft, w\u00e4hrend die neue hochgefahren wird. Die alte werden wir nur abschalten, wenn wir sicher sind, dass die neue Version funktioniert. Die Migration der Datenbank sollte es erm\u00f6glichen, mit beiden Versionen der Anwendung zu arbeiten. <\/p>\n<p>Deshalb k\u00f6nnen wir nicht einfach den Namen einer Spalte oder andere Daten \u00e4ndern. Aber wir k\u00f6nnen eine neue Spalte erstellen, die Daten aus der alten Spalte kopieren und Trigger schreiben, die bei Datenaktualisierungen gleichzeitig die Daten in die andere Spalte kopieren und aktualisieren. Nach dem erfolgreichen Deployment der neuen Version der Anwendung, nach einer sogenannten Post Launch Support-Phase, k\u00f6nnen wir die alte Spalte und den nicht mehr ben\u00f6tigten Trigger l\u00f6schen. <\/p>\n<p>Wenn die neue Version der Anwendung nicht korrekt funktioniert, k\u00f6nnen wir auf die vorherige Version zur\u00fccksetzen, einschlie\u00dflich der vorherigen Version der Datenbank. Kurz gesagt, unsere \u00c4nderungen erm\u00f6glichen es, gleichzeitig mit mehreren Versionen der Anwendung zu arbeiten. <\/p>\n<p>Wir planen, die Automatisierung der Datenbankmigration \u00fcber einen K8S-Job einzurichten und in den CD-Prozess einzubinden. Und wir werden diese Erfahrung definitiv auf Habr teilen.<br \/>\n<br \/>Quelle: <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.1.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.\" \/>\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\/de\/blog\/administrirovanie\/nasha-realizatsiya-continuous-deployment-na-platformu-zakazchika\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.1.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\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\/de\/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\udd47 Unsere Implementierung von Continuous Deployment auf der Plattform des Kunden | ProHoster","description":"Wir bei True Engineering haben den Prozess der kontinuierlichen Lieferung von Updates an die Server unserer Kunden eingerichtet und m\u00f6chten diese Erfahrung teilen. Zun\u00e4chst haben wir ein Online-System f\u00fcr den Kunden entwickelt und es in eigener Regie bereitgestellt.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/nasha-realizatsiya-continuous-deployment-na-platformu-zakazchika","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","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\/de\/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\/de\/wp-json\/wp\/v2\/posts\/31377","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=31377"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/31377\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/23342"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=31377"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=31377"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=31377"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}