Zunächst etwas Theorie. Was ist ?
Einfach ausgedrückt, handelt es sich um ein Dokument, das darauf abzielt, die Entwicklung von SaaS-Anwendungen zu vereinfachen, indem es Entwicklern und DevOps-Ingenieuren über häufige Probleme und Praktiken informiert, die in der modernen Anwendungsentwicklung auftreten.
Das Dokument wurde von den Entwicklern der Plattform Heroku erstellt.
Die Methodologie der zwölf Faktoren (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, Cache usw.).
Kurze Zusammenfassung der Faktoren, auf denen diese Methodologie basiert:
- Codebasis – Eine Codebasis, die in einem Versionskontrollsystem verfolgt wird, – mehrere Bereitstellungen
- Abhängigkeiten – Abhängigkeiten klar deklarieren und isolieren
- Konfiguration – Konfiguration zur Laufzeit speichern
- Externe Dienste (Backing Services) – Betrachten Sie externe Dienste (backing services) als angeschlossene Ressourcen
- Build, Release, Run – Trennen Sie strikt die Phasen von Build und Run
- Prozesse – Führen Sie die Anwendung als einen oder mehrere zustandslose Prozesse (stateless) aus
- Portbindung – Exportieren Sie Dienste über Portbindung
- Parallelismus – Skalieren Sie die Anwendung mit Prozessen
- Entsorgbarkeit – Maximieren Sie die Zuverlässigkeit durch schnelles Starten 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 das Protokoll als Ereignisfluss
- Verwaltungsaufgaben – Führen Sie Verwaltungs- und Managementaufgaben mit einmaligen Prozessen aus
Weitere Informationen zu den 12 Faktoren finden Sie in den folgenden Ressourcen:
- — unbedingt zu lesen
- — offizielle Übersetzung
- — ein neuer Blick auf die 12 Faktoren zur Verbesserung.
Was ist Blue-Green Deployment?
Blue-Green Deployment ist eine Methode zur Bereitstellung von Anwendungen auf production so dass der Endkunde keinerlei Veränderungen bemerkt. Mit anderen Worten, die Bereitstellung der Anwendung erfolgt mit null Ausfallzeiten.
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 und Projekt, sowie einen Router (Load Balancer).
- Der Router leitet anfangs alle Anfragen an einen der Servergrün).
- In dem Moment, in dem ein neues Release durchgeführt werden muss, wird das gesamte Projekt auf dem anderen Serverblauaktualisiert, der momentan keine Anfragen bearbeitet.
- Nachdem der Code auf dem blauen Server vollständig aktualisiert wurde, erhält der Router den Befehl, auf den grünen findet man blau Server.
- zu wechseln. Nun sehen alle Kunden die Ergebnisse des Codes von blauem Server.
- Für eine gewisse Zeit dient der grün Server als Backup für den Fall eines fehlerhaften Deployments auf den blau Server, und im Falle eines Fehlers oder Bugs schaltet der Router den Nutzerstrom zurück auf den grün Server mit der alten stabilen Version, während der neue Code zur Überarbeitung und Testung gesendet wird.
- Am Ende des Prozesses wird ebenso der grün Server aktualisiert. Nach seiner Aktualisierung schaltet der Router den Anfragenstrom zurück auf grün Server.
Das sieht alles sehr gut aus und auf den ersten Blick sollten damit keine Probleme auftreten.
Da wir jedoch in einer modernen Welt leben, ist die Variante mit physischen Schaltern, wie sie im klassischen Schema dargestellt ist, nicht praktikabel. Halten Sie die Informationen vorerst fest, wir werden später darauf zurückkommen.
Nützliche und schädliche Tipps
Haftungsausschluss: In den untenstehenden Beispielen sind die Werkzeuge / Methoden aufgeführt, die ich verwende; Sie können jedoch beliebige Alternativen mit ähnlichen Funktionen nutzen.
Die meisten Beispiele werden in irgendeiner Weise mit Web-Entwicklung (überraschung!) sowie mit PHP und Docker zu tun haben.
In den folgenden Punkten finden Sie eine einfache praktische Beschreibung der Nutzung von Faktoren anhand bestimmter Beispiele. Wenn Sie mehr Theorie zu diesem Thema wünschen, wenden Sie sich bitte über die obigen Links an die Originalquelle.
1. Codebasis
Verwenden Sie FTP und FileZilla, um Dateien einzeln auf Server hochzuladen. Speichern Sie den Code nirgendwo außer auf dem Produktionsserver.
In einem Projekt sollte es immer eine einheitliche Codebasis geben, das heißt, der gesamte Code stammt aus einer Quelle. Git Repository. Die Server (Production, Staging, Test1, Test2 …) verwenden Code aus den Branches eines gemeinsamen Repositories. So erreichen wir die Konsistenz des Codes.
2. Abhängigkeiten
Laden Sie alle Bibliotheken als Verzeichnisse direkt in das Hauptverzeichnis des Projekts herunter. Aktualisierungen erfolgen einfach durch das Übertragen des neuen Codes in den Ordner der aktuellen Version der Bibliothek. Installieren Sie alle benötigten Tools direkt auf dem Hostserver, wo bereits 20 Dienste laufen.
Das Projekt sollte immer eine klar definierte Liste von Abhängigkeiten haben (unter Abhängigkeiten verstehe ich auch die Umgebung). Alle Abhängigkeiten müssen eindeutig definiert und isoliert sein.
Als Beispiel nehmen wir Composer und Docker.
Composer — einen Paketmanager, der es ermöglicht, PHP-Bibliotheken zu installieren. Composer bietet die Möglichkeit, Versionen strikt oder nicht strikt anzugeben und sie eindeutig zu definieren. Auf dem Server können 20 verschiedene Projekte laufen, und jedes hat eine eigene Liste von Paketen und Bibliotheken, die unabhängig voneinander sind.
Docker — ein Werkzeug, das es ermöglicht, die Umgebung zu bestimmen und zu isolieren, in der die Anwendung ausgeführt wird. Ähnlich wie bei Composer, aber diesmal umfassender, können wir festlegen, mit was die Anwendung arbeitet. Eine bestimmte PHP-Version auswählen, nur die für das Projekt benötigten Pakete installieren und nichts Überflüssiges hinzufügen. Am wichtigsten ist, dass es keine Überschneidungen mit den Paketen und der Umgebung der Hostmaschine und anderer Projekte gibt. Das heißt, alle Projekte auf dem Server, die über Docker laufen, können völlig unterschiedliche Paketsets und Umgebungen nutzen.
3. Konfiguration
Bewahren Sie Konfigurationen als Konstanten direkt im Code auf. Separate Konstanten für den Test-Server, separate für die Produktionsumgebung. Binden Sie die Funktionsweise der Anwendung abhängig von der Umgebung direkt in die Logik 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 heißt, selbst wenn Sie mehrere Konfigurationsdateien wie .config.prod und .config.local speichern und diese beim Deployment in .config umbenennen (die Hauptkonfiguration, aus der die Anwendung Daten liest) - wäre dies kein sinnvoller Ansatz, 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 werden könnten. Alle Konfigurationen sollten direkt im Deployment-System (CI/CD) gespeichert und für verschiedene Umgebungen mit unterschiedlichen 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, nutzen Sie unterschiedliche Verbindungen für dieselben Dienste in bestimmten Umgebungen.
Tatsächlich überschneidet sich dieser Punkt stark mit dem Punkt über Konfigurationen, da ohne diesen Punkt keine ordentlichen Konfigurationsdaten erstellt werden können und die Möglichkeit zur Konfiguration insgesamt verloren geht.
Alle Verbindungen zu externen Diensten wie Warteschlangensystemen, Datenbanken und Caching-Diensten sollten sowohl für die lokale Umgebung als auch für die Produktionsumgebung einheitlich sein. Anders gesagt, ich kann jederzeit die Verbindungszeichenfolge ändern und die Zugriffe auf Datenbank #1 durch Datenbank #2 ersetzen, ohne den Anwendungscode zu ändern. Ein Beispiel hierfür ist, dass Sie beim Skalieren des Services nicht für einen zusätzlichen Cache-Server eine spezielle Verbindung angeben müssen.
5. Aufbau, Veröffentlichung, Ausführung
Halten Sie nur die finale Version des Codes auf dem Server, ohne die Möglichkeit, ein Release zurückzusetzen. Platzieren Sie keine nicht benötigten Daten auf der Festplatte. Wer denkt, dass er fehlerhaften Code in die Produktion bringen kann, ist ein schlechter Programmierer!
Alle Phasen des Deployments sollten voneinander getrennt sein.
Haben Sie die Möglichkeit, zurückzugehen. Erstellen Sie Releases und bewahren Sie ältere Kopien der Anwendung (schon erstellt und bereit für den Einsatz) in leicht zugänglichen Verzeichnissen auf, um im Falle von Fehlern zur alten Version zurückzukehren. Es gibt also den Ordner releases und den Ordner current, und nach einem erfolgreichen Deployment und Aufbau befindet sich der Ordner current verknüpft sich über einen symbolischen Link mit der neuen Version, die intern liegt. releases mit einer bedingten Bezeichnung für die Versionsnummer.
Hier kommt das Blue-Green-Deployment ins Spiel, das nicht nur den Wechsel zwischen Code ermöglicht, sondern auch das Umschalten zwischen allen Ressourcen und sogar Umgebungen erlaubt, mit der Möglichkeit, alles zurückzusetzen.
6. Prozesse
Speichern Sie die Anwendungszustände direkt in der Anwendung selbst. Verwenden Sie Sessions im Arbeitsspeicher der Anwendung. Nutzen Sie so viele gemeinsam genutzte Daten wie möglich, die zwischen externen Diensten geteilt werden können. Stellen Sie sicher, dass die Anwendung nur einen Prozess haben kann und verhindern Sie die Möglichkeit der Skalierung.
Hinsichtlich der Sitzungen sollten Sie Daten nur im Cache speichern, der von externen Diensten (memcached, redis) verwaltet wird. Dadurch kann selbst bei 20 laufenden Anwendungsprozessen jeder von ihnen über den Cache weiterhin mit dem Kunden im gleichen Zustand arbeiten, in dem der Benutzer zuvor mit der Anwendung in einem anderen Prozess gewesen ist. Dieser Ansatz gewährleistet, dass unabhängig davon, wie viele Kopien externer Dienste Sie verwenden, alles reibungslos funktioniert und der Datenzugang unproblematisch bleibt.
7. Portbindung
Nur der Webserver sollte wissen, wie man mit externen Diensten umgeht. Am besten wäre es, externe Dienste direkt innerhalb des Webservers zu betreiben, zum Beispiel als PHP-Modul in Apache.
Alle Ihre Dienste sollten über eine Adresse und einen Port (localgost:5432, localhost:3000, nginx:80, php-fpm:9000) füreinander erreichbar sein. Das bedeutet, dass ich von nginx sowohl auf php-fpm als auch auf Postgres zugreifen kann, und von php-fpm auf Postgres und nginx, sodass ich von jedem Dienst auf jeden anderen Dienst zugreifen kann. Dadurch ist die Lebensfähigkeit eines Dienstes nicht von der eines anderen abhängig.
8. Parallelität
Arbeiten Sie mit einem Prozess, denn mehrere Prozesse können möglicherweise nicht harmonieren!
Halten Sie die Möglichkeit zur Skalierung offen. Docker Swarm ist dafür hervorragend geeignet.
Docker Swarm ist ein Tool zur Erstellung und Verwaltung von Container-Clustern, sowohl über verschiedene Maschinen als auch innerhalb einer Vielzahl von Containern auf einer einzelnen Maschine.
Mit Swarm kann ich festlegen, wie viele Ressourcen ich jedem Prozess zuweisen möchte und wie viele Prozesse eines bestimmten Dienstes ich starten will. Der interne Load Balancer empfängt Daten auf einen bestimmten Port und leitet sie automatisch an die Prozesse weiter. Wenn die Last auf dem Server steigt, kann ich mehr Prozesse hinzufügen, um die Belastung bestimmter Prozesse zu verringern.
9. Entsorgbarkeit (Disposability)
Verwenden Sie keine Warteschlangen für die Arbeit mit Prozessen und Daten. Das Beenden eines Prozesses sollte die Funktionsweise der gesamten Anwendung beeinflussen. Fällt ein Dienst aus, fällt alles aus.
Jeder Prozess und Dienst kann jederzeit abgeschaltet werden, ohne dass dies andere Dienste beeinträchtigt (was hier gemeint ist, ist nicht, dass ein Dienst nicht für einen anderen Dienst verfügbar ist, sondern dass ein anderer Dienst nicht sofort daraufhin ebenfalls abgeschaltet wird). Alle Prozesse sollten sanft beendet werden, sodass beim Abschluss keine Daten verloren gehen und das System beim nächsten Start einwandfrei funktioniert. Das heißt, selbst im Falle eines Notabschaltens dürfen keine Daten verloren gehen (hier wäre ein Transaktionsmechanismus hilfreich; Datenbankanfragen funktionieren nur gruppenweise, und wenn auch nur eine Anfrage aus der Gruppe nicht erfolgreich ist oder mit einem Fehler beendet wird, wird letztendlich keine andere Anfrage aus der Gruppe ausgeführt).
10. Parität der Entwicklung/Betrieb des Anwendungsprogramms
Die Produktions-, Staging- und lokale Version der Anwendung müssen unterschiedlich sein. In der Produktion verwenden wir das Yii Lite Framework, während wir lokal Yii nutzen, damit es in der Produktion schneller läuft!
In der Praxis sollten alle Deployments und die Arbeit mit Code in nahezu identischen Umgebungen erfolgen (es geht nicht um physische Hardware). Auch das Deployment von Code in der Produktion sollte von jedem Entwicklungsteammitglied möglich sein, nicht nur von einer speziell geschulten DevOps-Abteilung, die nur durch besondere Fähigkeiten in der Lage ist, eine Anwendung in der Produktion zu starten.
Dabei hilft uns auch Docker. Wenn alle vorherigen Punkte beachtet werden, ermöglicht die Nutzung von Docker, den Prozess der Erstellung von Umgebungen sowohl in der Produktion als auch auf dem lokalen Rechner auf ein bis zwei Befehle zu reduzieren.
11. Protokollierung (Logs)
Wir schreiben Logs in Dateien und Datenbanken! Dateien und Datenbanken werden nicht von Logs bereinigt. 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 in stdout ausgegeben oder über ein Protokoll wie UDP gesendet werden, damit die Arbeit mit Logs der Anwendung keine Probleme bereitet. Hierfür eignet sich Graylog gut. Graylog empfängt alle Logs über UDP (für dieses Protokoll ist keine Bestätigung des erfolgreichen Empfangs des Pakets erforderlich), stört die Anwendung in keiner Weise und beschäftigt sich nur mit der Strukturierung und Verarbeitung der Logs. Die Logik der Anwendung ändert sich nicht, wenn man solche Ansätze verwendet.
12. Administrationsaufgaben
Um Daten, Datenbanken usw. zu aktualisieren, verwenden Sie einen separat erstellten Endpunkt in der API. Die Ausführung dieses Endpunkts zweimal hintereinander kann dazu führen, dass Sie alle Daten duplizieren. Aber Sie sind ja nicht dumm, Sie klicken nicht zweimal, und Migrationen sind uns nicht nötig.
Alle Administrationsaufgaben müssen in derselben Umgebung wie der gesamte Code und auf der Release-Ebene durchgeführt werden. Das bedeutet, wenn wir die Struktur der Datenbank ändern müssen, werden wir dies nicht manuell tun, indem wir die Spaltennamen ändern oder neue über irgendwelche visuellen DB-Management-Tools hinzufügen. Für solche Dinge erstellen wir separate Skripte – Migrationen, die überall und in allen Umgebungen mit einem gemeinsamen und eindeutigen Ergebnis ausgeführt werden. 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 auf MacOS erstellt. Der Großteil ist auch für Linux geeignet. Windows-Nutzer, entschuldigt bitte, aber mit Windows habe ich seit langem nicht mehr gearbeitet.
Stellen wir uns vor, dass auf unserem PC keine PHP-Version installiert ist und überhaupt nichts vorhanden ist.
Wir installieren die neuesten Versionen von Docker und Docker-Compose. (das findet man im Internet)
docker -v &&
docker-compose -v
1. Wir installieren
git clone https://github.com/Laradock/laradock.git &&
ls
Zu Laradock kann ich sagen, dass es ein großartiges Werkzeug ist, das viele Container und Hilfsdienste vereint. Allerdings würde ich nicht empfehlen, Laradock ohne Anpassungen in der Produktion zu verwenden, da es überladen ist. Es ist besser, eigene Container basierend auf den Beispielen in Laradock zu erstellen, da es dadurch mehr Möglichkeiten zur Optimierung gibt, denn niemand benötigt alles, was dort gleichzeitig vorhanden ist.
2. Konfigurieren Sie Laradock für den Betrieb unserer Anwendung.
cd laradock &&
cp env-example .env
2.1. Öffnen Sie das Verzeichnis habr (den übergeordneten Ordner, in den Laradock geklont wurde) in einem beliebigen Editor. (In meinem Fall PHPStorm)
An diesem Punkt legen wir nur den Projektnamen fest.
2.2. Starten Sie das Workspace-Image. (In Ihrem Fall werden die Images eine Weile gebaut.)
Das Workspace ist ein speziell vorbereitetes Image für die Arbeit mit dem Framework aus der Sicht 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 Projektverzeichnis erstellt wurde, und beenden den Compose.
ls
exit
docker-compose down
2.5. Kehren wir zurück zu PHPStorm und setzen den richtigen Pfad zu unserer Laravel-Anwendung in der .env-Datei.
3. Fügen wir den gesamten Code zu Git hinzu.
Dazu erstellen wir ein Repository auf Github (oder woanders). Wechseln wir im Terminal in das Verzeichnis habr und führen wir 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 Repository sein
git push -u origin master
git status
Überprüfen wir, ob alles in Ordnung ist.
Zur Vereinfachung empfehle ich die Nutzung einer visuellen Schnittstelle für Git, in meinem Fall ist das . (hier ist der Referenzlink)
4. Lassen Sie uns starten!
Stellen Sie vor dem Start sicher, dass auf 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 Verarbeitung von Anfragen vom Webserver
- workspace — PHP für den Entwickler
Derzeit haben wir erreicht, dass wir eine Anwendung erstellt haben, die bereits 4 Punkte von 12 erfüllt, nämlich:
1. Codebasis — der gesamte Code liegt 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 der application/composer.json und in jedem Dockerfile jedes Containers definiert.
3. Externe Dienste (Backing Services) — Jeder Dienst (php-fpm, nginx, workspace) läuft unabhängig und ist extern angebunden. Bei der Arbeit mit einem Dienst bleibt der andere unberührt.
4. Prozesse — Jeder Dienst ist ein einzelner Prozess. Jeder Dienst speichert keinen internen Zustand.
5. Portbindung
docker ps
Wie wir sehen, wird jeder Dienst auf seinem eigenen Port gestartet und ist für alle anderen Dienste zugänglich.
6. Parallelismus
Docker ermöglicht es uns, mehrere Instanzen desselben Dienstes mit automatischer Lastverteilung zu starten.
Lassen Sie uns die Container anhalten und mit dem Flag neu starten. —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 bei der Arbeit mit diesem Container nichts ändern. Wir greifen weiterhin über den Port 9000 darauf zu, während Docker die Last zwischen den Containern reguliert.
7. Entsorgbarkeit — Jeder Container kann ohne Beeinträchtigung anderer Container beendet werden. Das Stoppen oder Neustarten eines Containers hat keine Auswirkungen auf die Anwendung bei nachfolgenden Starts. Jeder Container kann auch jederzeit wieder aktiviert werden.
8. Parität zwischen Entwicklung und Betrieb der Anwendung — Alle unsere Umgebungen sind identisch. Wenn Sie ein System auf dem Server in der Produktion starten, müssen Sie nichts in Ihren Befehlen ändern. Alles basiert genau so auf Docker.
9. Protokollierung (Logs) — Alle Protokolle in diesen Containern werden an den Stream weitergeleitet und sind in der Docker-Konsole sichtbar. (In diesem Fall kann es bei anderen benutzerdefinierten Containern anders sein, wenn Sie sich nicht darum kümmern.)
docker-compose logs -f 
Es gibt jedoch ein Problem: Die Standardwerte in PHP und Nginx schreiben ebenfalls Protokolle in eine Datei. Um den 12-Faktoren-Kriterien zu entsprechen, ist es notwendig, logging die Protokollierung in Dateien in den Konfigurationen jedes Containers einzeln zu deaktivieren.
Docker bietet auch die Möglichkeit, Protokolle nicht nur an stdout zu senden, sondern auch an Dinge wie Graylog, von dem ich oben gesprochen habe. Innerhalb von Graylog können wir die Protokolle nach Belieben verarbeiten, und unsere Anwendung wird dies nicht bemerken.
10. Verwaltungsaufgaben — Alle Administrationsaufgaben werden von Laravel dank des Artisan-Tools genau so gelöst, wie es die Entwickler einer 12-Faktoren-Anwendung vorgesehen haben.
Als Beispiel zeige ich, wie einige Befehle ausgeführt werden.
Betreten Sie den Container.
docker-compose exec workspace bash
php artisan list
Jetzt können wir jeden Befehl nutzen. (Bitte beachten Sie, dass wir die Datenbank und den Cache nicht konfiguriert haben, daher werden die Hälfte der Befehle nicht korrekt ausgeführt, da sie für die Arbeit mit dem Cache und der DB gedacht sind).
11. Konfigurationen und 12. Build, Release, Run
Diesen Teil wollte ich dem Blue-Green Deployment widmen, aber es stellte sich als zu umfangreich für diesen Artikel heraus. Ich werde darüber einen separaten Artikel schreiben.
Kurz gesagt, das Konzept basiert auf CI/CD-Systemen wie Jenkins und (geschrieben in. In beiden können Umgebungsvariablen festgelegt werden, die mit einer bestimmten Umgebung verbunden sind. Entsprechend wird der Punkt mit Konfigurationen.
Und der Punkt über Build, Release, Run wird durch integrierte Funktionen in beiden Tools gelöst, die als Pipeline.
Pipeline ermöglicht es, den Deployment-Prozess in viele Phasen zu unterteilen, wobei die Phasen der Erstellung, Freigabe und Ausführung hervorgehoben werden. Auch im Pipeline können Sie Backups erstellen und überhaupt alles Mögliche erledigen. Dieses Werkzeug hat unbegrenztes 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 anderen Tools und Programmiersprachen verwendet werden. Hauptsache, der Kern bleibt unverändert.
Quelle: habr.com
