Was ist kontinuierliche Integration (CI)?

Die kontinuierliche Integration ist der nächste logische Schritt nach einem Versionskontrollsystem wie Git und ein Remote -Versionskontrollsystem wie GitLab oder GitHub für kollaborative Bemühungen. Das Problem, mit dem große Projekte konfrontiert sind, ist dies - wenn neue Pull -Anfragen kommen, müssen sie getestet und dann in den Master -Zweig integriert werden. Diese Bemühungen können je nach Größe des Projekts leicht zwischen einigen Stunden und einigen Wochen dauern. der Ort der Teammitglieder usw.

Wie bei jedem solchen Problem besteht der logische Schritt darin, das gesamte Rigmarole des Tests zu automatisieren. Wir tun dies, indem wir einen Auslöser so einrichten, dass ein Agent (z. Wenn ein Fehler auftritt.

Natürlich können Sie auch die Bereitstellung automatisieren, automatisierte A/B -Tests einrichten und die menschliche Intervention aus dem Prozess entfernen. Dies wird als kontinuierliche Lieferung und/oder als kontinuierliche Bereitstellung bezeichnet, abhängig von der Automatisierungsniveau. Aber wir würden uns nur auf die kontinuierliche Integration in dieses Tutorial konzentrieren.

Voraussetzungen

Wir konzentrieren uns auf die Einrichtung eines einfachen CI -Flusses im Tutorial mit einer Gitlab -Instanz über HTTPs, die wir in einem früheren Beitrag behandelt haben.

Darüber hinaus gehen wir davon aus, dass Sie in dieser GitLab -Instanz ein Benutzerkonto eingerichtet haben und haben ein Repository (kloniert auf Ihre lokale Maschine) verwaltet unter Ihrem Benutzernamen. Es ist dieses Repository, das wir verwenden werden, um den CI -Workflow zu demonstrieren. Im Tutorial wird sein Name sein Mein Projekt.

Um alles aufzulisten:

1. Gitlab -Instanz
2. Leeres Repository, My-Project genannt
3. Lokaler Klon dieses Repositorys
4. Ihre lokale GIT -Instanz konfiguriert, um Änderungen in die Ins " Fernbedienung.

Erstellen einer einfachen App

Lassen Sie uns in diesem Repository einen einfachen Knoten erstellen.JS -App. Diese App ist ein einfacher Express.JS -Server, der in einem Docker -Container bereitgestellt werden soll. Der Server gibt eine HTTP -Nutzlast mit der Aufschrift „Hallo Welt“ in Ihrem Browser mit der Aufschrift.

Erstellen Sie im Stamm Ihres lokalen Repositorys eine Datei App.JS und fügen Sie die folgenden Zeilen hinzu:

"Strikte";
const express = forderung ('express');
// Konstanten
const port = 8080;
const host = '0.0.0.0 ';
// App
const App = express ();
App.get ('/', (req, res) =>
res.send ('Hallo Welt \ n');
);
App.Hören Sie (Port, Host);
Konsole.log ('auf http: // $ host: $ port');

Erstellen Sie dann eine andere Datei Paket.JSON und fügen Sie Folgendes hinzu:

"Name": "Docker_Web_App",
"Version 1.0.0 ",
"Beschreibung": "Knoten.JS auf Docker ",
"Autor": "John Doe",
"Main": "Server.JS ",
"Skripte":
"Start": "Knotenserver.JS "
,
"Abhängigkeiten":
"Express": "^4.16.1 "

Zuletzt erstellen Sie eine Dockerfile und fügen Sie den folgenden Inhalt hinzu:

Vom Knoten: 8
# App -Verzeichnis erstellen
WorkDir/usr/src/App
# App -Abhängigkeiten installieren
# Mit einer Wildcard wird beide Paket sichergestellt.JSON und Paketschloss.JSON werden kopiert
Paket kopieren*.JSON ./
Führen Sie die NPM -Installation aus
# Wenn Sie Ihren Code für die Produktion erstellen
# Ausführen von NPM Install -Only = Produktion
# Bündel -App -Quelle
KOPIEREN…
8080 entdecken
CMD ["Knoten", "App"]

Der Erstellungsprozess für diese App umfasst das Erstellen eines Knotencontainers und die Installation der Abhängigkeiten (wie Express.JS -Modul). Dieser Vorgang sollte ohne Fehler auftreten. Um den Einfachheit halber werden wir in diesem Tutorial keine Tests besprechen.

GitLab Runner Pipeline

Jetzt würden wir unserem Repository eine andere Datei hinzufügen, die aufgerufen werden würde .Gitlab-ci.YML . Diese Datei würde die Anweisungen zum Erstellen unseres Projekts enthalten. Jedes Mal, wenn wir uns für die Instanz in unserer Gitlab -Instanz einsetzen, greift Gitlab einen Läufer auf, um das Projekt zu erstellen und zu testen.

Wir weisen diese Pipeline verschiedene zu, verschiedene Arbeitsplätze die alle unabhängig voneinander ausgeführt werden können, wodurch der Build -Prozess flexibler wird. Für das obige Repo ist dies gültig .Gitlab-ci.YML Erstellen Sie diese Datei im Root Ihres Repositorys:

Bild: Knoten: Neueste
Stufen:
- bauen
Zwischenspeicher:
Pfade:
- node_modules/
Install_Dependenzen:
Bühne: Build
Skript:
- NPM Installation

Wir haben nur eine Stufe bauen Und es hat nur NPM Installation als Skript. Dies ist ein Befehl, den Sie jedes Mal manuell ausführen müssten, wenn eine Änderung zu Ihrem Projekt kommt. Der Gitlab -Läufer würde dies für Sie tun. Der Läufer kann in einem Kubernetes -Cluster, einem VPS in der Cloud oder in Ihrer lokalen Workstation installiert werden, und wenn es aktiv ist, warten Sie auf Anweisungen vom GitLab -Server, um einen Build auszuführen.

Wir würden einen Läufer lokal installieren und konfigurieren, um ihn zu automatisieren.

Das Runner -Token bekommen

Öffnen Sie Ihr Repository auf GitLab und besuchen Sie die CD/CI -Einstellungen. Das ist Einstellungen → CD/CI In Ihrem Test -Repository.

Lassen Sie die Einstellung von Auto DevOps der Standardeinstellung und klicken Sie auf EXPANDIEREN Um die allgemeinen Pipeline -Einstellungen zu erweitern, wird Ihnen ein Runner -Token angezeigt. Kopieren Sie seinen Wert und halten Sie ihn natürlich privat, wenn Sie Ihr Projekt schätzen.

Mit diesem Token kann sich Ihr ausführender lokaler GitLab -Läufer sicher bei Ihrer GitLab -Instanz registrieren.

Installieren von Gitlab Runner

Gitlab-Runner ist ein kleines leichtes Programm, das in GO geschrieben wurde, das CI -bezogen ausführt Arbeitsplätze Auf Ihrer lokalen Maschine und sendet die Ergebnisse an GitLab, damit sie die Änderungen berücksichtigt. Es ist eine einzelne ausführbare Binärdatei, die auf jedem großen Betriebssystem installiert werden kann. Befolgen Sie die Anweisungen hier für Ihr bestimmtes Betriebssystem. Diese Installationen variieren stark, sodass die Auflistung aller von ihnen unmöglich ist.

Alternativ können Sie Läufer als Docker -Service verwenden, aber bleiben wir einfach bei der traditionellen Installation, da die Befehle für den Leser einfacher zu lesen und zu verstehen sind. Sobald Sie es auf Ihrer örtlichen Workstation installiert haben, müssen Sie den Befehl ausführen:

$ GitLab-Runner Register

Auf diese Weise werden Sie einige Fragen stellen, die mit Ihrem GitLab-CI-Koordinator beginnen, der Ihre Gitlab-Instanz ist:

$ GitLab-Runner Register
Bitte geben Sie die GitLab-CI-Koordinator-URL ein (e.G. https: // gitlab.com/):
https: // gitlab.Beispiel.com

Anschließend werden Sie nach Ihrem Runner -Token fragen, den wir im vorherigen Abschnitt erhalten haben:

Bitte geben Sie das GitLab-CI-Token für diesen Läufer ein:

Your_secret_token

Für einige identifizierende Beschreibung und Sie können einfach über das Hinzufügen von Tags überspringen, indem Sie Folgendes drücken:

Bitte geben Sie die Beschreibung von GitLab-CI für diesen Läufer ein:

[Hostname]: Demo zum Einrichten von CI mit Läufer

Bitte geben Sie die GitLab-CI-Tags für diesen Läufer ein (Comma getrennt):

Registrierung von Läufer… erfolgreich war

Am wichtigsten ist, dass Sie nach einem Testamentsvollstrecker fragen werden (mehr dazu). Wir werden Docker für unser Beispiel willen wählen.

Bitte geben Sie den Executor ein: Docker-SSH+Machine, Kubernetes, Parallelen, Shell, SSH, VirtualBox, Docker+Machine, Docker, Docker-SSH:

Docker

Das Basis -Docker -Bild, in dem der Build stattfinden würde, muss angegeben werden. Unsere Beispiel -App verwendet den Knoten, sodass wir ein Knotenbild angeben:

Bitte geben Sie das Standard -Docker -Bild (e) ein.G. Ruby: 2.1):

Knoten: Neueste

Läufer erfolgreich registriert. Fühlen Sie sich frei, damit zu beginnen, aber wenn es bereits ausgeführt wird, sollte die Konfiguration automatisch neu geladen werden!

Jetzt ist etwas, das hier eine kleine Erklärung braucht, was genau sind Testamentsvollstrecker? Die Art und Weise, wie CI -Arbeit fließt Arbeitsplätze und Executoren führen diese Jobs aus. Wenn Sie VirtualBox als Executor ausgewählt haben, würde sich GitLab Runner in die lokal installierte VirtualBox integrieren und die CI -Jobs in einem VM ausführen. Wenn Sie Kubernetes auswählen, würde dies in Ihrem Kubernetes -Cluster in der Cloud passieren, wenn Sie SSH auswählen können Delegieren Sie die CI -Aufgaben auf einen Remote -Server.

Unser Beispielprojekt basiert auf Docker. Daher ist es sinnvoll, Docker als unseren Testamentsvollstrecker zu verwenden. Du brauchst Docker lokal installiert dafür.

Wenn Sie mehrere Optionen für Executoren haben, wird der Läufer flexiblerer. Möglicherweise möchten Sie lokal erstellen, da die Projektdateien zu groß sind oder Sie möglicherweise auf einem Remote -Server mit 20 Kernen und einem halben Terabyte RAM ausführen möchten.

Schließlich möchten Sie in Ihrer Hülle den Läuferdienst starten:

$ GitLab-Runner Start

Sehen .Gitlab-ci.YML in Aktion

Jetzt haben wir all diese Änderungen in unserem lokalen Repo erstellt, das die gesamte App erstellt hat.JS, Paket.Json, Dockerfile und .Gitlab-ci.YML -Dateien. Vermutlich haben Sie die Änderungen an Ihrem lokalen Repository durch Ausführen begangen:

$ git Stage File_Name
$ git Commit -m "Botschaft begehen"

Lassen Sie uns die Änderungen in unserem Remote Gitlab drücken.

$ git push -u Ursprung

Sie können dann Ihr Projekt in Gitlab eröffnen, gehen Sie zu My-Project → Pipeline Und Sie werden dies ein Tag sehen, das neben dem von Ihnen gemachten Commit "bestanden" sagt. Nachfolgende Commits haben auch Tags.

Das sind also die Grundlagen von CI mit Gitlab und Läufer. Ich hoffe, Sie haben den Beitrag genossen und etwas Neues daraus gelernt.