Ich habe in mehreren Einsendungen zum viele herausragende Arbeiten auf hohem Niveau gesehen. Allerdings denken nur wenige Menschen darüber nach, wie sie die Datenbank bei der täglichen Arbeit auf gemeinsamen Standbys (Entwickler, Bühne, Produkt usw.) auf dem neuesten Stand halten können. Dieser Artikel richtet sich an unerfahrene Entwickler. Ich habe Spring als Beispiel verwendet, um eine einfache Technik zur Einführung eines Datenbankmigrationssystems in den CI/CD-Prozess zu demonstrieren. DevOps Writing Contest Für diese Bereitstellung benötigen wir die CI/CD-Tools Liquibase und GitLab. Gehen Sie zunächst davon aus, dass eine Datenbank betriebsbereit ist. Ich werde PostgreSQL verwenden. GitLab CI/CD Wenn Sie GitLab bereits bereitgestellt haben, können Sie diesen Schritt vollständig überspringen. Um Gitlab bereitzustellen, verwenden wir die Docker-Methode. Es ist wichtig zu beachten, dass wir die Variable erstellen müssen. $GITLAB_HOME sudo docker run --detach \ --hostname gitlab.devopscontest.com \ --publish 443:443 --publish 80:80 --publish 22:22 \ --name gitlab \ --restart always \ --volume $GITLAB_HOME/config:/etc/gitlab \ --volume $GITLAB_HOME/logs:/var/log/gitlab \ --volume $GITLAB_HOME/data:/var/opt/gitlab \ --shm-size 256m \ gitlab/gitlab-ee:16.4.1-ee.0 Der nächste Schritt besteht darin, Runner zu installieren und zu konfigurieren. Wenn Sie bereits ein Projekt mit langer Laufzeit haben und alles schon seit langem eingerichtet ist, können Sie das Erstellen eines neuen Runners überspringen. Ich zeige die Erstellung eines Runners am Beispiel der Version 16.4.1. erfolgt über die Registrierung mit , aber der Ansatz ähnelt dem aktuellen. Alles nach 17.0 RUNNER_AUTHENTICATION_TOKEN Zuerst müssen Sie die Runner-Quelle installieren. Um es per Bash auf Ihrem bereitgestellten GitLab zu installieren, hilft dieses Beispiel, wie Sie Runner für Apple Silicon-basierte Systeme installieren können (andere Betriebssysteme finden Sie hier): https://docs.gitlab.com/runner/install/?embedable=true # Download the binary for your system sudo curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64 # Give it permission to execute sudo chmod +x /usr/local/bin/gitlab-runner # Create a GitLab Runner user sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash # Install and run as a service sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner sudo gitlab-runner start Jetzt können wir den Runner selbst über die Benutzeroberfläche erstellen, indem wir auf die Schaltfläche klicken. New project runner Jeder Runner kann eine Plattform, blau angezeigte Tags und andere Laufzeitkonfigurationen haben. Wenn wir die Möglichkeit festlegen müssen, Befehle aus dem Programm auszuführen, sind Tags hilfreich. An allem anderen sind wir vorerst desinteressiert. Nachdem Sie auf geklickt haben, müssen Sie nur noch Ihren Läufer registrieren. Create runner # Command to register runner gitlab-runner register --url https://gitlab.devopscontest.com/ --registration-token glrt-bjyfCR5pM5wypQDdfSqU Flüssigkeitsbasis ist eine kostenlose Open-Source-Plattform zur Verwaltung von Datenbankmigrationen. Zusammenfassend lässt sich sagen, dass Sie mit Liquibase Rollup- und Rollback-Prozeduren mithilfe von Changeset-Dateien beschreiben können. Bei den Skripten selbst kann es sich sowohl um herkömmliche SQL-Befehle als auch um datenbankunabhängige Beschreibungen von Änderungen handeln, die in ein auf Ihre Datenbank zugeschnittenes Skript umgewandelt werden. Die Liste der . Liquibase unterstützten Datenbanken finden Sie hier Ich zeige Ihnen eine Möglichkeit, Migrationen in einer Spring-Anwendung durchzuführen. Dies ist notwendig, damit Sie die Ausführung aller Änderungssätze als separaten Schritt steuern können. Projekt Um schnell eine Spring-Anwendung zu entwickeln, . klicken Sie hier Lassen Sie uns jetzt schnell Besonderes Augenmerk sollte auf die Optionen „Aktiviert“ und „Änderungsprotokoll“ gelegt werden. Die erste Option aktiviert und deaktiviert Liquibase auf Anwendungsebene, während die zweite den Pfad zum Änderungsprotokoll festlegt. application.yml. server: port: 80 spring: datasource: username: ${DB_USERNAME} password: ${DB_PASSWORD} url: ${DB_HOST} liquibase: enabled: true change-log: classpath:db/changelog/db.changelog-master.xml Was tun mit den Variablen? Es empfiehlt sich, sie in GitLab zu platzieren, was dabei hilft, die Anwendung flexibel zwischen Entwicklungs-/Produktständen anzupassen. Wir verwenden Kubernetes in unserem Projekt und diese Parameter müssen von den Teams selbst festgelegt werden, wenn sie die Anwendung mithilfe von Wertedateien erstellen, die für verschiedene Schemata vorkonfiguriert sind env: - name: SPRING_PROFILES_ACTIVE value: "dev" - name: DB_HOST value: "jdbc:postgresql://127.0.0.1:5436/your_db" - name: DB_USERNAME value: "user" - name: DB_PASSWORD value: "pass" Kommen wir zurück zur Anpassung. Meiner Meinung nach ist es eine kluge Vorgehensweise, völlig autarke Apps zu erstellen, die sofort einsatzbereit sind. Um eine eindeutige Phase in CI/CD weiter aufzubauen, erstellen wir eine Migrationsdatei. Wir können unterschiedliche Tools für unterschiedliche Teams verwenden und sind mit dieser Datei nicht auf das Migrationssystem beschränkt. #!/bin/sh cd /opt/app /opt/app/liquibase \ --changeLogFile=./db/changelog/changelog-master.xml \ --url="$DB_HOST" \ --username="$DB_USERNAME" \ --password="$DB_PASSWORD" \ --logLevel=info \ --headless=true \ update Alle möglichen Befehle finden Sie in der . Jetzt brauchen wir nur noch , was uns ermöglicht, aus der Datei changelog-master.xml auf die aktuelle Version zu aktualisieren. Liquibase-Dokumentation update Der nächste Schritt besteht darin, eine.gitlab-ci.yml-Datei im Projektstammverzeichnis zu erstellen, die Anweisungen zum Fortfahren mit dem CI/CD-Prozess enthält. Zunächst möchte ich für die Datei aufmerksam machen, der im Projekt unter dem relativen Pfad zu finden ist. Bevor ich die Konfiguration durcheinander bringe, empfehle ich, sie zu verwenden. Es wird außerdem davon ausgegangen, dass Sie wissen, wie man mit YAML-Dateien arbeitet. auf den integrierten Linker gitlab-ci.yml ci/lint Etappen und Jobs stages: - publish - dev .migrate: stage: publish allow_failure: true script: - ./migrate.sh Migrate: tags: - migration extends: .migrate environment: name: dev Das -Tag weist unseren zuvor generierten Runner an, auf diese Aufgabe zu reagieren und Skripte im auszuführen. Die identifiziert die Stufe, zu der dieser Job gehört. Bei Bedarf kann derselbe Runner an mehreren Projekten gleichzeitig arbeiten. Der Umgebungsblock bezieht sich auf die . Hierbei handelt es sich um eine Art Dashboard, in dem Sie den Status Ihrer Stände (Entwicklung, Vorproduktion, Produktion usw.) anzeigen und Aktionen wie manuelle Bereitstellungen durchführen können. Darüber hinaus können umgebungsgebundene Variablen konfiguriert werden; Allerdings hatte ich keine Gelegenheit, diese Premium-Funktion zu testen. migration script stage Umgebung Ablehnung fehlerhafter Maßnahmen Sie können die entsprechende Zusammenführung stoppen, falls beim Bereitstellungsvorgang etwas schief geht. Dies ist insbesondere dann hilfreich, wenn Tests als eigenständige Phase in CI/CD integriert werden. Obwohl Liquibase in unserem Beispiel keine Tests hat, kann es zu Fehlfunktionen kommen, wenn beispielsweise falsche Dateipfade eingegeben werden. Alle Zusammenführungen sind nicht zulässig, wenn das Kontrollkästchen nach der Konfiguration von CI/CD nicht aktiviert ist. Letzter Schliff Lassen Sie uns eine Migrationsdatei erstellen und aktivieren. Dazu müssen wir die Datei als Eingabepunkt erstellen. changelog-master.xml Für eine flexiblere Verwaltung empfiehlt es sich, über mehrere changelog.xml zu verfügen. Sie können daraus eine Changelog-Hierarchie erstellen. In unserem Beispiel verwenden wir jedoch einen einfacheren Weg. <?xml version="1.1" encoding="UTF-8" standalone="no"?> <databaseChangeLog xmlns="http://www.liquibase.org/xml/ns/dbchangelog" xmlns:ext="http://www.liquibase.org/xml/ns/dbchangelog-ext" xmlns:pro="http://www.liquibase.org/xml/ns/pro" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog-ext http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-ext.xsd http://www.liquibase.org/xml/ns/pro http://www.liquibase.org/xml/ns/pro/liquibase-pro-4.1.xsd http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-4.1.xsd"> <include file="db/changelog/changeset-202310151300-create-table.sql"/> </databaseChangeLog> Es empfiehlt sich, Migrationen anhand von Datum und Uhrzeit zu benennen. Dadurch wird vermieden, dass die Sortierung der Migrationen unterbrochen wird, wenn ein großes Entwicklungsteam gleichzeitig arbeitet. --liquibase formatted sql --changeset a.tyryshkin:create-table create table if not exists table ( id bigserial primary key, name varchar(255) ); create sequence if not exists table_id_seq; Sie können verschiedene XML-, YAML- oder JSON-Formate verwenden, um Migrationen zu beschreiben, aber SQL ist für meinen Geschmack am einfachsten zu lesen. Wir versuchen es umzusetzen und alles ist erfolgreich. Überprüfen Sie unsere Datenbank und sehen Sie sich den Eintrag im Datenbank-Changelog an. Abschluss In diesem Artikel haben wir besprochen, wie Sie GitLab selbst bereitstellen, Runner herunterladen und konfigurieren und, was am wichtigsten ist, ein Datenbankmigrationssystem in Ihren CI/CD-Prozess integrieren. Ich hoffe, dass dieser Leitfaden Ihnen dabei hilft, diesen Leitfaden in die Tat umzusetzen.
