J'ai vu beaucoup de travaux exceptionnels et de haut niveau dans plusieurs des soumissions au . Cependant, peu de personnes réfléchissent à la manière de maintenir la base de données à jour dans les tâches courantes (développement, scène, production, etc.) tout en travaillant quotidiennement. Cet article est destiné aux développeurs novices. J'ai utilisé Spring comme exemple pour démontrer une technique simple permettant d'introduire un système de migration de base de données dans le processus CI/CD. concours d'écriture DevOps Nous aurons besoin des outils CI/CD Liquibase et GitLab pour ce déploiement. Supposons pour le moment qu'une base de données soit opérationnelle. J'utiliserai PostgreSQL. GitLab CI/CD Si GitLab est déjà déployé, vous pouvez ignorer complètement cette étape. Pour déployer Gitlab, nous utiliserons la méthode Docker. Il est important de noter que nous devons créer la variable . $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 L'étape suivante consiste à installer et configurer les coureurs. Si vous avez déjà un projet de longue durée et que tout a été configuré depuis longtemps, vous pouvez ignorer la création d'un nouveau coureur. Je vais montrer la création d'un runner en utilisant la version 16.4.1 comme exemple. est enregistré en utilisant , mais l'approche est proche de celle actuelle. Tout ce qui est après 17.0 RUNNER_AUTHENTICATION_TOKEN Tout d’abord, vous devez installer la source du coureur. Afin de l'installer via bash sur votre GitLab déployé, cet exemple vous explique comment installer runner pour les systèmes basés sur Apple Silicon (autres systèmes d'exploitation que vous pouvez trouver ici) : 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 Nous pouvons maintenant créer le coureur lui-même via l'interface utilisateur en cliquant sur le bouton . New project runner Chaque coureur peut avoir une plate-forme, des balises qui apparaissent en bleu et d'autres configurations d'exécution. Lorsque nous devons définir la possibilité d'exécuter des commandes à partir du programme, les balises sont utiles. Pour l’instant, tout le reste ne nous intéresse pas. Après avoir cliqué sur , il ne vous reste plus qu'à inscrire votre coureur. Create runner # Command to register runner gitlab-runner register --url https://gitlab.devopscontest.com/ --registration-token glrt-bjyfCR5pM5wypQDdfSqU Liquibase est une plateforme gratuite et open source pour gérer les migrations de bases de données. En résumé, Liquibase vous permet de décrire les procédures de rollup et de rollback à l'aide de fichiers changset. Les scripts eux-mêmes peuvent être des commandes SQL conventionnelles ainsi que des descriptions de modifications indépendantes de la base de données qui seront transformées en un script adapté à votre base de données. La liste des . Liquibase bases de données prises en charge est disponible ici Je vais vous montrer un moyen d'effectuer des migrations dans une application Spring. Cela est nécessaire pour que vous puissiez contrôler l'exécution de tous les ensembles de modifications en tant qu'étape distincte. Projet Pour développer rapidement une application Spring, . rendez-vous ici Créons maintenant rapidement Une attention particulière doit être accordée aux options activées et de journal des modifications. La première option active et désactive Liquibase au niveau de l'application, tandis que la seconde définit le chemin d'accès au journal des modifications. 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 Que faire des variables ? C'est une bonne pratique de les insérer dans GitLab, ce qui permettra de personnaliser de manière flexible l'application entre les stands de développement/production. Nous utilisons Kubernetes dans notre projet, et ces paramètres doivent être définis par les équipes elles-mêmes lors de la construction de l'application à l'aide de fichiers de valeurs préconfigurés pour différents schémas. 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" Revenons à la personnalisation. Créer des applications complètement autonomes et prêtes à être déployées immédiatement est, à mon avis, une pratique judicieuse. Afin de construire davantage une étape distincte dans CI/CD, construisons un fichier de migration. Nous pouvons utiliser différents outils pour différentes équipes, et nous ne sommes pas limités au système de migration avec ce fichier. #!/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 Toutes les commandes possibles peuvent être trouvées dans la . Maintenant, nous n'avons besoin que , ce qui nous permet de mettre à jour vers la version actuelle à partir du fichier changelog-master.xml. documentation Liquibase update L'étape suivante consiste à créer un fichier.gitlab-ci.yml à la racine du projet qui contient des instructions sur la façon de poursuivre le processus CI/CD. Tout d'abord, je voudrais attirer pour le fichier , qui se trouve dans le projet au chemin relatif . Avant de modifier la configuration, je suggère de l'utiliser. Il est également supposé que vous savez comment travailler avec les fichiers YAML. l'attention sur l'éditeur de liens intégré gitlab-ci.yml ci/lint Étapes et travaux stages: - publish - dev .migrate: stage: publish allow_failure: true script: - ./migrate.sh Migrate: tags: - migration extends: .migrate environment: name: dev La balise demande à notre exécuteur généré précédemment de réagir à cette tâche et d'exécuter des scripts dans la section . La chaîne identifie l'étape à laquelle appartient ce travail. Si nécessaire, un même coureur peut travailler sur plusieurs projets à la fois. Le bloc environnement fait référence à l' . Il s'agit d'un type de tableau de bord où vous pouvez visualiser l'état de vos stands (développement, pré-prod, prod, etc.) et prendre des actions telles que des déploiements manuels. De plus, des variables liées à l'environnement peuvent être configurées ; cependant, je n'ai pas eu l'occasion de tester cette fonctionnalité premium. migration script stage environnement Rejet des mesures comportant des erreurs Vous pouvez arrêter la fusion correspondante en cas de problème avec la procédure de déploiement. Cela est particulièrement utile si les tests sont intégrés dans CI/CD en tant que phase indépendante. Bien que Liquibase ne dispose pas de tests dans notre exemple, il peut mal fonctionner si des chemins de fichiers incorrects sont saisis, par exemple. Toutes les fusions ne seront pas autorisées si la case n'est pas cochée après la configuration de CI/CD. Touches finales Créons un fichier de migration et activons-le. Pour ce faire, nous devons créer le fichier comme point d'entrée. changelog-master.xml Il est recommandé d'avoir plusieurs changelog.xml pour une gestion plus flexible. Vous pouvez créer une hiérarchie de journal des modifications à partir d'eux. Cependant, dans notre exemple, nous utiliserons une méthode plus simple. <?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> C'est une bonne pratique de nommer les migrations en utilisant la date et l'heure. Cela évitera de casser le tri des migrations lorsqu'une grande équipe de développement travaille en même temps. --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; Vous pouvez utiliser différents formats XML, YAML ou JSON pour décrire les migrations, mais SQL est le plus simple à lire à mon goût. Nous essayons d’exécuter et tout réussit. Consultez notre base de données et voyez l’entrée dans databasechangelog. Conclusion Dans cet article, nous avons expliqué comment déployer GitLab vous-même, télécharger et configurer les exécuteurs et, plus important encore, intégrer un système de migration de base de données dans votre processus CI/CD. J'espère que ce guide vous aidera à mettre ce guide en action.
