Zunächst ein wenig Theorie. Was ist ?
Einfach gesagt, ist dies ein Dokument, das die Entwicklung von SaaS-Anwendungen vereinfachen soll. Es informiert Entwickler und DevOps-Ingenieure über häufig auftretende Probleme und Praktiken in der Entwicklung moderner Anwendungen.
Das Dokument wurde von den Entwicklern der Plattform Heroku erstellt.
Die Zwölf-Faktoren-Methode (The Twelve-Factor App) kann auf Anwendungen angewendet werden, die in jeder Programmiersprache geschrieben sind und beliebige Kombinationen von externen Diensten (backing services) nutzen (Datenbanken, Nachrichtenwarteschlangen, Caches usw.).
Kurze Übersicht über die Faktoren, auf denen diese Methode basiert:
- Codebasis – Eine Codebasis, die in einem Versionskontrollsystem verfolgt wird – mehrere Deployments.
- Abhängigkeiten – Abhängigkeiten explizit deklarieren und isolieren.
- Konfiguration – Konfiguration zur Laufzeit speichern.
- Externe Dienste (Backing Services) – Betrachten Sie externe Dienste (backing services) als anpassbare Ressourcen.
- Bauen, Freigeben, Ausführen – Trennen Sie strikt die Phasen des Build- und Laufzeit.
- Prozesse – Führen Sie die Anwendung als einen oder mehrere zustandslose Prozesse aus.
- Portbindung (Port Binding) – Exportieren Sie Dienste über die Portbindung.
- Parallelität – Skalieren Sie die Anwendung mit Prozessen.
- Entsorgbarkeit (Disposability) – Maximieren Sie die Zuverlässigkeit durch schnelles Hochfahren und korrektes Herunterfahren.
- Parität zwischen Entwicklung und Betrieb der Anwendung – Halten Sie die Entwicklungs-, Staging- und Produktionsumgebungen so ähnlich wie möglich.
- Protokollierung (Logs) – Betrachten Sie Logs als einen Ereignisstrom.
- Verwaltungsaufgaben – Führen Sie Verwaltungs- / Managementaufgaben mit einmaligen Prozessen durch.
Weitere Informationen zu den 12 Faktoren finden Sie in den folgenden Ressourcen:
- – unbedingt lesenswert.
- – offizielle Übersetzung.
- – frischer Blick auf die 12 Faktoren zur Verbesserung.
Was ist Blue-Green Deployment?
Blue-Green Deployment ist eine Methode zum Bereitstellen von Anwendungen. Produktion so dass der Endkunde keine Änderungen von seiner Seite aus sieht. Mit anderen Worten, die Bereitstellung der Anwendung erfolgt ohne Ausfallzeit.
Das klassische BG Deploy-Schema sieht folgendermaßen aus, wie auf dem Bild unten dargestellt.
- Zu Beginn gibt es 2 physische Server mit absolut identischem Code, Anwendung, Projekt, und es gibt einen Router (Lastverteiler).
- Der Router leitet ursprünglich alle Anfragen an einen der Server weiter (blau).
- In dem Moment, in dem ein neuer Release durchgeführt werden muss, wird das gesamte Projekt auf dem anderen Server aktualisiert (alpha), der momentan keine Anfragen verarbeitet.
- Nachdem der Code auf dem blauen Server vollständig aktualisiert ist, erhält der Router den Befehl, auf den grünen auf alpha Server.
- Jetzt sehen alle Kunden das Ergebnis des Codes von dem blauen Server an.
- Für eine gewisse Zeit dient blau der Server als Backup für den Fall, dass das Deployment auf alpha den Server fehlschlägt, und im Falle von Fehlern schaltet der Router den Benutzerstrom zurück auf blau den Server mit der alten stabilen Version, und der neue Code wird zur Überarbeitung und Testung geschickt.
- Und am Ende des Prozesses wird ebenso der blau grüne Server aktualisiert. Und nach seiner Aktualisierung schaltet der Router den Benutzerstrom wieder auf blau Server.
Das sieht alles sehr gut aus und auf den ersten Blick sollte es dabei keine Probleme geben.
Aber da wir in der modernen Welt leben, ist die Option mit der physischen Umschaltung, wie im klassischen Schema angegeben, für uns nicht geeignet. Merken Sie sich die Informationen vor, wir kommen später darauf zurück.
Schlechte und gute Ratschläge
Haftungsausschluss: In den folgenden Beispielen sind die von mir verwendeten Tools / Methoden aufgeführt, Sie können absolut beliebige Alternativen mit ähnlichen Funktionen verwenden.
Der Großteil der Beispiele wird mehr oder weniger mit Webentwicklung (Überraschung!) sowie PHP und Docker überschneiden.
In den folgenden Punkten finden Sie eine einfache praktische Beschreibung der Verwendung von Faktoren anhand bestimmter Beispiele. Wenn Sie mehr Theorie zu diesem Thema wünschen, wenden Sie sich über die obigen Links an die Hauptquelle.
1. Codebasis
Verwenden Sie FTP und FileZilla, um Dateien einzeln auf die Server hochzuladen, speichern Sie den Code nirgendwo außer auf dem Produktionsserver.
Im Projekt sollte immer eine einheitliche Codebasis vorhanden sein, das heißt, der gesamte Code stammt aus einer Quelle. Git Repository. Die Server (Produktion, Staging, Test1, Test2 …) verwenden den Code aus den Ästen eines gemeinsamen Repositories. So erreichen wir die Konsistenz des Codes.
2. Abhängigkeiten
Laden Sie alle Bibliotheken als Ordner direkt in das Stammverzeichnis des Projekts herunter. Aktualisierungen erfolgen einfach durch das Verschieben des neuen Codes in den Ordner der aktuellen Bibliotheksversion. Installieren Sie alle erforderlichen Utilities direkt auf dem Host-Server, wo noch 20 Dienste laufen.
Das Projekt sollte immer eine klar verständliche Liste von Abhängigkeiten haben (unter Abhängigkeiten verstehe ich auch die Umgebung). Alle Abhängigkeiten müssen eindeutig definiert und isoliert sein.
Nehmen wir als Beispiel Composer und Docker.
Composer — einen Paketmanager, der es ermöglicht, PHP-Bibliotheken zu installieren. Composer gibt die Möglichkeit, Versionen streng oder nicht streng anzugeben und klar zu definieren. Auf dem Server können 20 verschiedene Projekte existieren, und jedes hat eine persönliche Liste von Paketen und Bibliotheken, die unabhängig voneinander sind.
Docker — ein Tool, das es ermöglicht, die Umgebung zu definieren und zu isolieren, in der die Anwendung ausgeführt wird. Ebenso wie bei Composer können wir hier jedoch umfassender definieren, mit was die Anwendung arbeitet. Eine bestimmte PHP-Version auswählen, nur die für das Projekt erforderlichen Pakete installieren, ohne etwas Überflüssiges hinzuzufügen. Und das Wichtigste – ohne Überschneidung mit Paketen und der Umgebung der Hostmaschine und anderer Projekte. Das heißt, alle Projekte auf dem Server, die über Docker arbeiten, können absolut jede Paket-Anzahl und völlig unterschiedliche Umgebungen verwenden.
3. Konfiguration
Bewahren Sie Konfigurationen als Konstanten direkt im Code auf. Einzelne Konstanten für den Testserver, separate für die Produktion. Binden Sie die Funktionalität der Anwendung abhängig von der Umgebung direkt in die Geschäftslogik des Projekts ein, indem Sie if-else-Konstruktionen verwenden.
Konfigurationen — das ist das Einzige, was die Bereitstellungen des Projekts (Deployment) unterscheiden sollte. Idealerweise sollten Konfigurationen über Umgebungsvariablen (env vars) übergeben werden.
Das bedeutet, dass selbst wenn Sie mehrere Konfigurationsdateien .config.prod .config.local speichern und diese beim Deployment in .config umbenennen (die Hauptkonfiguration, aus der die Anwendung Daten liest) — dies nicht der richtige Ansatz ist, da in diesem Fall die Informationen aus den Konfigurationen für alle Entwickler der Anwendung zugänglich wären und die Daten vom Produktionsserver kompromittiert würden. Alle Konfigurationen sollten direkt im Bereitstellungssystem (CI/CD) gespeichert und für verschiedene Umgebungen mit den spezifischen Werten, die für die jeweilige Umgebung erforderlich sind, genau zum Zeitpunkt des Deployments generiert werden.
4. Externe Dienste (Backing Services)
Binden Sie sich stark an die Umgebung, verwenden Sie unterschiedliche Verbindungen für dieselben Dienste in bestimmten Umgebungen.
Tatsächlich überschneidet sich dieser Punkt stark mit dem Punkt zu den Konfigurationen, denn ohne diesen Punkt lassen sich keine ordentlichen Konfigurationsdaten erstellen und die Möglichkeit zur Konfiguration würde vollständig verloren gehen.
Alle Verbindungen zu externen Diensten, wie Warteschserversysteme, Datenbanken, Caching-Dienste, sollten sowohl für die lokale Umgebung als auch für die externe / Produktionsumgebung einheitlich sein. Mit anderen Worten, ich kann jederzeit die Verbindungszeichenfolge ändern und den Zugriff auf Datenbank #1 durch Datenbank #2 ersetzen, ohne den Anwendungscode zu ändern. Oder um vorzugreifen, als Beispiel ist es so, dass Sie beim Skalieren des Dienstes für einen zusätzlichen Cache-Server nicht auf besondere Weise eine Verbindung angeben müssen.
5. Build, Release, Execute
Halten Sie auf dem Server nur die endgültige Version des Codes, ohne Möglichkeit, das Release zurückzusetzen. Es ist nicht nötig, Speicherplatz zu verschwenden. Wer denkt, er könnte fehlerhaften Code in die Produktion bringen, ist ein schlechter Programmierer!
Alle Phasen des Deployments sollten voneinander getrennt sein.
Haben Sie die Möglichkeit, zurückzukehren. Machen Sie Releases mit der Sicherung der alten Anwendungs-Kopien (bereits gebaut und kampfbereit), sodass Sie im Falle von Fehlern auf die alte Version zurückgreifen können. Das bedeutet, es gibt bedingt einen Ordner releases und einen Ordner – Strom, und nach einem erfolgreichen Deployment und Build wird der Ordner – Strom über einen symbolischen Link mit dem neuen Release verbunden, das sich innerhalb von releases mit einer bedingten Bezeichnung der Release-Nummer.
Hier denken wir an Blue-Green Deployment, das nicht nur den Wechsel zwischen Code ermöglicht, sondern auch den Wechsel zwischen allen Ressourcen und sogar Umgebungen mit der Möglichkeit, alles zurückzusetzen.
6. Prozesse
Speichern Sie Anwendungsstatusdaten direkt in der Anwendung selbst. Nutzen Sie die Sessions im Arbeitsspeicher der Anwendung. Verwenden Sie so viele zwischen externen Diensten gemeinsame Ressourcen wie möglich. Stellen Sie sicher, dass die Anwendung nur einen Prozess haben kann und verhindern Sie die Möglichkeit der Skalierung.
Bezüglich der Sessions speichern Sie Daten nur im Cache, der von externen Diensten kontrolliert wird (memcached, redis), sodass selbst wenn Sie 20 Anwendungsprozesse gleichzeitig ausführen, jeder von ihnen, der auf den Cache zugreift, mit dem Kunden im gleichen Zustand fortfahren kann, in dem der Benutzer in einem anderen Prozess mit der Anwendung gearbeitet hat. Mit diesem Ansatz gilt, dass egal wie viele Kopien von externen Diensten Sie verwenden, alles reibungslos funktioniert, ohne Probleme beim Datenzugriff.
7. Portbindung
Nur der Webserver sollte wissen, wie man mit externen Diensten umgeht. Noch besser ist es, externe Dienste direkt innerhalb des Webservers zu starten. Zum Beispiel als PHP-Modul in Apache.
Alle Ihre Dienste sollten untereinander durch den Zugriff auf eine Adresse und einen Port (localhost:5432, localhost:3000, nginx:80, php-fpm:9000) erreichbar sein, d. h. ich kann aus nginx sowohl auf php-fpm als auch auf postgres zugreifen, und aus php-fpm auf postgres und nginx, und grundsätzlich kann jeder Dienst auf jeden anderen Dienst zugreifen. So ist die Lebensfähigkeit eines Dienstes nicht von der Lebensfähigkeit eines anderen Dienstes abhängig.
8. Parallelität
Arbeiten Sie mit einem Prozess, denn sonst könnten mehrere Prozesse nicht miteinander auskommen!
Lassen Sie die Möglichkeit der Skalierung offen. Docker Swarm eignet sich dafür hervorragend.
Docker Swarm ist ein Tool zur Erstellung und Verwaltung von Container-Clustern, sowohl über verschiedene Maschinen als auch über viele Container auf einer einzigen Maschine.
Mit Swarm kann ich festlegen, wie viele Ressourcen ich jedem Prozess zuweisen möchte und wie viele Prozesse eines bestimmten Dienstes ich starten werde. Der interne Load-Balancer, der Daten über einen bestimmten Port empfängt, wird diese automatisch auf die Prozesse weiterleiten. Wenn ich also sehe, dass die Serverlast gestiegen ist, kann ich weitere Prozesse hinzufügen, um die Last auf bestimmte Prozesse zu verringern.
9. Entsorgung (Disposability)
Verwenden Sie keine Warteschlangen für die Arbeit mit Prozessen und Daten. Das Beenden eines Prozesses sollte die gesamte Anwendung beeinflussen. Wenn ein Dienst ausfällt, fällt alles aus.
Jeder Prozess und Dienst kann jederzeit beendet werden, ohne dass dies andere Dienste beeinträchtigt (es geht nicht darum, dass der Dienst nicht mehr verfügbar ist, sondern darum, dass ein anderer Dienst nicht zusammen mit diesem abgeschaltet wird). Alle Prozesse sollten sanft beendet werden, sodass beim Beenden keine Daten verloren gehen und das System beim nächsten Start korrekt funktioniert. Selbst im Falle eines Notabschaltens sollten keine Daten verloren gehen (hier kommt ein Transaktionsmechanismus ins Spiel, bei dem Datenbankabfragen nur in Gruppen ausgeführt werden, und wenn auch nur eine Abfrage aus der Gruppe fehlschlägt oder einen Fehler aufweist, wird keine der anderen Abfragen aus der Gruppe tatsächlich ausgeführt).
10. Gleichstand zwischen Entwicklung/Betrieb der Anwendung
Die Produktions-, Staging- und lokale Version der Anwendung sollten unterschiedlich sein. In der Produktion verwenden wir das Framework Yii Lite, lokal jedoch Yii, damit es in der Produktion schneller läuft!
Tatsächlich sollten alle Bereitstellungen und die Arbeit mit dem Code in nahezu identischen Umgebungen erfolgen (es geht nicht um die physische Hardware). Auch sollte jede Person in der Entwicklung in der Lage sein, den Code bei Bedarf in der Produktion bereitzustellen, und nicht nur eine speziell ausgebildete DevOps-Abteilung, die nur durch besondere Macht in der Lage ist, die Anwendung in der Produktion zu starten.
Hierbei hilft uns auch Docker. Bei Einhaltung aller vorherigen Punkte wird die Bereitstellung der Umgebung sowohl in der Produktion als auch lokal auf ein oder zwei Befehle reduziert.
11. Protokollierung (Logs)
Wir schreiben Logs in Dateien und Datenbanken! Wir bereinigen Dateien und Datenbanken von Logs nicht. Wir kaufen einfach eine Festplatte mit 9000 Petabyte und das war's.
Alle Logs sollten als Ereignisströme betrachtet werden. Die Anwendung selbst sollte sich nicht mit der Verarbeitung von Logs befassen. Logs sollten entweder auf stdout ausgegeben oder über einen Protokoll wie UDP gesendet werden, damit die Arbeit der Anwendung mit Logs keine Probleme verursacht. Dafür eignet sich Graylog gut. Graylog empfängt alle Logs über UDP (bei diesem Protokoll ist es nicht notwendig, auf eine Bestätigung des Empfangs zu warten) und stört die Anwendung in keiner Weise, während es sich nur mit der Strukturierung und Verarbeitung von Logs beschäftigt. Die Logik der Anwendung ändert sich nicht, wenn man solche Ansätze verwendet.
12. Verwaltungsaufgaben
Für die Aktualisierung von Daten, der Datenbank usw. verwenden Sie einen separat erstellten Endpunkt in der API, dessen Ausführung zweimal hintereinander dazu führen kann, dass Sie doppelte Einträge erhalten. Aber Sie sind ja nicht dumm, Sie drücken nicht zweimal, und Migrationen brauchen wir nicht.
Alle Verwaltungsaufgaben sollten in derselben Umgebung ausgeführt werden wie der gesamte Code, auf Ebene der Releases. Das heißt, wenn wir die Struktur der Datenbank ändern müssen, werden wir dies nicht manuell tun, indem wir Spaltennamen ändern und neue über irgendwelche visuellen Datenbankverwaltungstools hinzufügen. Für solche Dinge erstellen wir separate Skripte – Migrationen, die überall und in allen Umgebungen gleich ausgeführt werden und ein gemeinsames und verständliches Ergebnis liefern. Für alle anderen Aufgaben, wie das Befüllen des Projekts mit Daten, sollten ähnliche Methoden angewendet werden.
Beispielimplementierung in PHP, Laravel, Laradock, Docker-Compose
P.S. Alle Beispiele wurden unter MacOS erstellt. Der Großteil funktioniert auch für Linux. Windows-Nutzer, tut mir leid, aber mit Windows habe ich seit langem nicht mehr gearbeitet.
Stellen wir uns die Situation vor, dass auf unserem PC keine Version von PHP installiert und überhaupt nichts vorhanden ist.
Wir installieren die neuesten Versionen von Docker und Docker-Compose. (Das kann man im Internet finden.)
docker -v &&
docker-compose -v
1. Wir installieren
git clone https://github.com/Laradock/laradock.git &&
ls
Was Laradock betrifft, so ist es eine großartige Sache, die viele Container und Hilfswerkzeuge zusammenfasst. Aber ich würde nicht empfehlen, Laradock ohne Anpassungen in der Produktion zu verwenden, aufgrund seiner Überflüssigkeit. Es ist besser, eigene Container basierend auf den Beispielen in Laradock zu erstellen, da man so Optimierungsspielraum hat, denn niemand benötigt alles, was dort gleichzeitig vorhanden ist.
2. Wir konfigurieren Laradock für den Betrieb unserer Anwendung.
cd laradock &&
cp env-example .env
2.1. Öffnen Sie das Verzeichnis habr (der übergeordnete Ordner, in den laradock geklont wurde) in einem beliebigen Editor. (In meinem Fall PHPStorm)
An diesem Punkt vergeben wir nur den Projektnamen.
2.2. Starten Sie das Image workspace. (In Ihrem Fall werden die Images eine Zeit lang gebaut.)
Workspace ist ein speziell vorbereitetes Image für die Arbeit mit dem Framework aus der Perspektive des Entwicklers.
Betreten Sie den Container mit
docker-compose up -d workspace &&
docker-compose exec workspace bash
2.3. Installieren Sie Laravel
composer create-project --prefer-dist laravel/laravel application 
2.4. Nach der Installation überprüfen wir, ob das Verzeichnis mit dem Projekt erstellt wurde, und beenden den Compose.
ls
exit
docker-compose down
2.5. Kehren Sie zurück zu PHPStorm und geben Sie den richtigen Pfad zu unserer Laravel-Anwendung in der Datei .env an.
3. Fügen wir den gesamten Code zu Git hinzu.
Dazu erstellen wir ein Repository auf Github (oder woanders). Wechseln Sie im Terminal in das Verzeichnis habr und führen Sie den folgenden Code aus.
echo "# habr-12factor" >> README.md
git init
git add README.md
git commit -m "Erster Commit"
git remote add origin git@github.com:nzulfigarov/habr-12factor.git # hier wird der Link zu Ihrem Repo sein
git push -u origin master
git status
Überprüfen Sie, ob alles in Ordnung ist.
Zur Vereinfachung empfehle ich die Verwendung einer visuellen Git-Oberfläche, in meinem Fall ist das . (hier ist der referenzielle Link)
4. Lassen Sie uns starten!
Stellen Sie vor dem Start sicher, dass an den Ports 80 und 443 nichts läuft.
docker-compose up -d nginx php-fpm 
So besteht unser Projekt aus 3 separaten Diensten:
- nginx — Webserver
- php-fpm — PHP zur Entgegennahme von Anfragen vom Webserver
- workspace — PHP für den Entwickler
Bis jetzt haben wir erreicht, dass wir eine Anwendung geschaffen haben, die den Punkten 1-4 von 12 entspricht, nämlich:
1. Codebasis — Der gesamte Code befindet sich in einem Repository (eine kleine Anmerkung: Es könnte sinnvoll sein, Docker innerhalb des Laravel-Projekts zu integrieren, aber das ist nicht entscheidend).
2. Abhängigkeiten — Alle unsere Abhängigkeiten sind klar in application/composer.json und in jedem Dockerfile jedes Containers angegeben.
3. Externe Dienste (Backing Services) — Jeder Dienst (php-fpm, nginx, workspace) lebt sein eigenes Leben und ist von außen verbunden und bei der Arbeit mit einem Dienst wird der andere nicht berührt.
4. Prozesse — Jeder Dienst ist ein Prozess. Jeder Dienst speichert keinen internen Zustand.
5. Portbindung (Port Binding)
docker ps
Wie wir sehen, läuft jeder Dienst auf seinem eigenen Port und ist für alle anderen Dienste zugänglich.
6. Parallelität
Docker ermöglicht es uns, mehrere Prozesse derselben Dienste mit automatischer Lastverteilung zwischen ihnen zu starten.
Beenden wir die Container und starten wir sie mit dem Flag —scale
docker-compose down &&
docker-compose up -d --scale php-fpm=3 nginx php-fpm
Wie wir sehen, wurden Kopien des php-fpm Containers erstellt. Wir müssen in der Arbeit mit diesem Container nichts ändern. Wir greifen weiterhin über den Port 9000 auf ihn zu, während Docker die Last zwischen den Containern reguliert.
7. Entsorgbarkeit (Disposability) — Jeder Container kann ohne Schaden für einen anderen beendet werden. Das Stoppen oder Neustarten eines Containers wirkt sich nicht auf den Betrieb der Anwendung bei späteren Starts aus. Jeder Container kann zudem jederzeit hochgefahren werden.
8. Parität zwischen Entwicklung und Betrieb der Anwendung — Unsere Umgebungen sind identisch. Wenn Sie das System auf einem Server in der Produktion ausführen, müssen Sie in Ihren Befehlen nichts ändern. Alles basiert weiterhin genau auf Docker.
9. Protokollierung (Logs) — Alle Protokolle in diesen Containern laufen auf einen Stream und sind in der Docker-Konsole sichtbar. (In diesem Fall, tatsächlich, kann es mit anderen benutzerdefinierten Containern anders sein, wenn Sie sich nicht darum kümmern.)
docker-compose logs -f 
Aber hier gibt es einen Haken, denn die Standardwerte in PHP und Nginx protokollieren auch in eine Datei. Um den 12-Faktor-Anforderungen gerecht zu werden, ist es notwendig deaktivieren die Protokollierung in eine Datei in den Konfigurationen jedes Containers einzeln.
Docker ermöglicht es auch, Protokolle nicht nur in stdout zu leiten, sondern auch in so etwas wie Graylog, von dem ich oben gesprochen habe. Innerhalb von Graylog können wir mit Logdaten nach Belieben operieren, ohne dass unsere Anwendung davon etwas bemerkt.
10. Verwaltungsaufgaben — Alle Verwaltungsaufgaben werden von Laravel dank des Artisan-Werkzeugs genau so gelöst, wie sich die Schöpfer einer 12-Faktor-Anwendung das wünschen würden.
Ich zeige als Beispiel, wie einige Befehle ausgeführt werden.
Wir betreten den Container.
docker-compose exec workspace bash
php artisan list
Jetzt können wir jeden Befehl verwenden. (Bitte beachten Sie, dass wir die Datenbank und den Cache nicht konfiguriert haben, sodass die Hälfte der Befehle nicht korrekt ausgeführt wird, da sie für die Arbeit mit Cache und DB gedacht sind.)
11. Konfigurationen und 12. Bauen, Freigeben, Ausführen
Ich wollte diesen Teil dem Blue-Green Deployment widmen, aber das stellte sich als zu umfangreich für diesen Artikel heraus. Darüber werde ich einen separaten Artikel schreiben.
In Kürze basiert das Konzept auf CI/CD-Systemen wie Jenkins und Gitlab CI. In beiden können Umgebungsvariablen festgelegt werden, die mit einer bestimmten Umgebung verbunden sind. Entsprechend wird der Punkt mit Konfigurationen.
Und der Punkt über Bauen, Freigeben, Ausführen wird durch in beiden Tools integrierte Funktionen mit dem Namen gelöst. Pipeline.
Pipeline erlaubt es, den Deployment-Prozess in viele Phasen zu unterteilen, indem er die Phasen von Build, Release und Execution hervorhebt. Auch im Pipeline können Sie Backups erstellen und im Allgemeinen alles Mögliche tun. Dieses Werkzeug hat unendliches Potenzial.
Der Anwendungscode befindet sich auf .
Vergessen Sie nicht, das Submodul beim Klonen dieses Repositories zu initialisieren.
P.S.: Alle diese Ansätze können mit beliebigen anderen Tools und Programmiersprachen verwendet werden. Hauptsache, die Grundidee bleibt erhalten.
Quelle: habr.com
