He visto muchos trabajos sobresalientes y de alto nivel en varias de las presentaciones al . Sin embargo, pocas personas consideran cómo mantener actualizada la base de datos en los recursos comunes (desarrollo, etapa, producción, etc.) mientras trabajan todos los días. Este artículo está destinado a desarrolladores novatos. Utilicé Spring como ejemplo para demostrar una técnica sencilla para introducir un sistema de migración de bases de datos en el proceso CI/CD. Concurso de redacción de DevOps Necesitaremos las herramientas Liquibase y GitLab CI/CD para esta implementación. Supongamos por el momento que una base de datos está en funcionamiento. Usaré PostgreSQL. CI/CD de GitLab Si ya tienes implementado GitLab, puedes omitir este paso por completo. Para implementar Gitlab, usaremos el método Docker. Es importante tener en cuenta que necesitamos crear 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 El siguiente paso es instalar y configurar los corredores. Si ya tiene un proyecto de larga duración y todo ha estado configurado durante mucho tiempo, puede omitir la creación de un nuevo ejecutor. Mostraré la creación de un corredor usando la versión 16.4.1 como ejemplo. se registra mediante , pero el enfoque es cercano al actual. Todo lo posterior a 17.0 RUNNER_AUTHENTICATION_TOKEN Primero, necesitas instalar la fuente del corredor. Para instalarlo a través de bash en su GitLab implementado, este ejemplo le ayuda a instalar runner para sistemas basados en Apple Silicon (puede encontrar otros sistemas operativos aquí): 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 Ahora podemos crear el corredor a través de la interfaz de usuario haciendo clic en el botón . New project runner Cada corredor puede tener una plataforma, etiquetas que aparecen en azul y otras configuraciones de tiempo de ejecución. Cuando necesitamos configurar la posibilidad de ejecutar comandos desde el programa, las etiquetas son útiles. Por el momento, todo lo demás no nos interesa. Después de hacer clic en , lo único que queda por hacer es registrar a tu corredor. Create runner # Command to register runner gitlab-runner register --url https://gitlab.devopscontest.com/ --registration-token glrt-bjyfCR5pM5wypQDdfSqU Liquibase es una plataforma gratuita y de código abierto para gestionar migraciones de bases de datos. En resumen, Liquibase le permite describir procedimientos de consolidación y reversión utilizando archivos changset. Los scripts en sí pueden ser comandos SQL convencionales, así como descripciones de modificaciones independientes de la base de datos que se convertirán en un script adaptado a su base de datos. La lista de . Liquibase bases de datos compatibles está disponible aquí Le mostraré una forma de realizar migraciones en una aplicación Spring. Esto es necesario para poder controlar la ejecución de todos los conjuntos de cambios como un paso independiente. Proyecto Para desarrollar rápidamente una aplicación Spring, . vaya aquí Ahora creemos rápidamente Se debe prestar especial atención a las opciones habilitadas y de registro de cambios. La primera opción habilita y deshabilita Liquibase a nivel de aplicación, mientras que la segunda establece la ruta al registro de cambios. 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 ¿Qué hacer con las variables? Es una buena práctica colocarlos en GitLab, lo que ayudará a personalizar de manera flexible la aplicación entre los soportes de desarrollo y producción. Usamos Kubernetes en nuestro proyecto, y estos parámetros deben ser establecidos por los propios equipos al construir la aplicación utilizando archivos de valores que están preconfigurados para varios esquemas. 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" Volvamos a la personalización. Crear aplicaciones completamente autosuficientes que estén preparadas para su implementación inmediata es, en mi opinión, una práctica inteligente. Para seguir construyendo una etapa distinta en CI/CD, construyamos un archivo de migración. Podemos usar diferentes herramientas para diferentes equipos y no estamos restringidos al sistema de migración con este archivo. #!/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 Todos los comandos posibles se pueden encontrar en la . Ahora sólo nos falta , lo que nos permite actualizar a la versión actual desde el archivo changelog-master.xml. documentación de Liquibase update El siguiente paso es crear un archivo.gitlab-ci.yml en la raíz del proyecto que contenga instrucciones sobre cómo proceder con el proceso de CI/CD. En primer lugar, me gustaría llamar para el archivo , que se puede encontrar en el proyecto en la ruta relativa . Antes de cambiar la configuración, sugiero usarla. También se supone que sabes cómo trabajar con archivos YAML. la atención sobre el vinculador integrado gitlab-ci.yml ci/lint Etapas y trabajos stages: - publish - dev .migrate: stage: publish allow_failure: true script: - ./migrate.sh Migrate: tags: - migration extends: .migrate environment: name: dev La etiqueta le indica a nuestro ejecutor generado previamente que reaccione a esta tarea y ejecute scripts en la sección . La cadena identifica la etapa a la que pertenece este trabajo. Si es necesario, el mismo corredor puede trabajar en varios proyectos a la vez. El bloque de entorno se refiere al . Este es un tipo de panel donde puede ver el estado de sus stands (desarrollo, preproducción, producción, etc.) y realizar acciones como implementaciones manuales. Además, se pueden configurar variables vinculadas al entorno; sin embargo, no he tenido la oportunidad de probar esta función premium. migration script stage medio ambiente Rechazo de medidas con errores Puede detener la fusión correspondiente en caso de que algo salga mal con el procedimiento de implementación. En particular, esto es útil si las pruebas se integran en CI/CD como una fase independiente. Aunque Liquibase no tiene pruebas en nuestro ejemplo, puede funcionar mal si, por ejemplo, se ingresan rutas de archivos incorrectas. No se permitirán todas las fusiones si la casilla de verificación no está marcada después de configurar CI/CD. Toques finales Creemos un archivo de migración y habilítelo. Para hacer esto necesitamos crear el archivo como punto de entrada. changelog-master.xml Es una buena práctica tener varios changelog.xml para una gestión más flexible. Puede crear una jerarquía de registro de cambios a partir de ellos. Sin embargo, en nuestro ejemplo usaremos una forma más sencilla. <?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 una buena práctica nombrar las migraciones usando fecha y hora. Esto evitará interrumpir la clasificación de las migraciones cuando un gran equipo de desarrollo esté trabajando al mismo tiempo. --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; Puede utilizar diferentes formatos XML, YAML o JSON para describir las migraciones, pero SQL es el más fácil de leer para mi gusto. Intentamos ejecutar y todo es exitoso. Consulte nuestra base de datos y vea la entrada en el registro de cambios de la base de datos. Conclusión En este artículo, analizamos cómo implementar GitLab usted mismo, descargar y configurar ejecutores y, lo más importante, integrar un sistema de migración de bases de datos en su proceso de CI/CD. Espero que esta guía le ayude a ponerla en práctica.
