Tenho visto muitos trabalhos excelentes e de alto nível em vários envios para o . No entanto, poucas pessoas consideram como manter o banco de dados atualizado em standbys comuns (dev, stage, prod, etc.) enquanto trabalham todos os dias. Este artigo é destinado a desenvolvedores iniciantes. Usei Spring como exemplo para demonstrar uma técnica simples para introduzir um sistema de migração de banco de dados no processo de CI/CD. DevOps Writing Contest Exigiremos ferramentas Liquibase e GitLab CI/CD para esta implantação. Suponha por enquanto que um banco de dados está instalado e funcionando. Usarei PostgreSQL. CI/CD do GitLab Se você já tem o GitLab implantado, pode pular totalmente esta etapa. Para implantar o Gitlab, usaremos o método Docker. É importante observar que precisamos criar a variável . $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 A próxima etapa é instalar e configurar os executores. Se você já tem um projeto de longa duração e tudo está configurado há muito tempo, você pode pular a criação de um novo executor. Mostrarei a criação de um runner usando a versão 16.4.1 como exemplo. vai para registro usando , mas a abordagem é próxima da atual. Qualquer coisa após 17.0 RUNNER_AUTHENTICATION_TOKEN Primeiro, você precisa instalar a fonte do executor. Para instalá-lo via bash em seu GitLab implantado, este exemplo ajuda como você pode instalar o runner para sistemas baseados em Apple Silicon (outro sistema operacional você pode encontrar aqui): 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 Agora podemos criar o próprio executor por meio da IU clicando no botão . New project runner Cada executor pode ter uma plataforma, tags que aparecem em azul e outras configurações de tempo de execução. Quando precisamos definir a possibilidade de executar comandos do programa, as tags são úteis. Por enquanto, não estamos interessados em todo o resto. Depois de clicar em , a única coisa que falta fazer é cadastrar seu corredor. Create runner # Command to register runner gitlab-runner register --url https://gitlab.devopscontest.com/ --registration-token glrt-bjyfCR5pM5wypQDdfSqU Liquibase é uma plataforma gratuita e de código aberto para gerenciamento de migrações de banco de dados. Em resumo, o Liquibase permite descrever procedimentos de rollup e rollback usando arquivos changset. Os próprios scripts podem ser comandos SQL convencionais, bem como descrições de modificações independentes do banco de dados que serão transformadas em um script adaptado ao seu banco de dados. A lista de . Liquibase bancos de dados suportados está disponível aqui Mostrarei uma maneira de realizar migrações em uma aplicação Spring. Isso é necessário para que você possa controlar a execução de todos os conjuntos de alterações como uma etapa separada. Projeto Para desenvolver rapidamente um aplicativo Spring, . clique aqui Vamos agora criar rapidamente Atenção especial deve ser dada às opções ativadas e de registro de alterações. A primeira opção ativa e desativa o Liquibase no nível do aplicativo, enquanto a segunda define o caminho para o changelog. 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 O que fazer com as variáveis? É uma boa prática colocá-los no GitLab, o que ajudará a personalizar com flexibilidade o aplicativo entre suportes de desenvolvimento/produção. Utilizamos Kubernetes em nosso projeto, e esses parâmetros devem ser definidos pelas próprias equipes na construção da aplicação usando arquivos de valor pré-configurados para diversos 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" Voltemos à personalização. Criar aplicativos totalmente autossuficientes e preparados para implantação imediata é, na minha opinião, uma prática inteligente. Para construir ainda mais um estágio distinto em CI/CD, vamos construir um arquivo de migração. Podemos utilizar ferramentas diferentes para equipes diferentes e não estamos restritos ao sistema de migração com este arquivo. #!/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 os comandos possíveis podem ser encontrados na . Agora só precisamos , que nos permite atualizar para a versão atual a partir do arquivo changelog-master.xml. documentação do Liquibase update A próxima etapa é criar um arquivo.gitlab-ci.yml na raiz do projeto que contém instruções sobre como prosseguir com o processo de CI/CD. Em primeiro lugar, gostaria de chamar para o arquivo , que pode ser encontrado no projeto no caminho relativo . Antes de alterar a configuração, sugiro usá-la. Também pressupõe-se que você saiba trabalhar com arquivos YAML. a atenção para o vinculador integrado gitlab-ci.yml ci/lint Etapas e trabalhos stages: - publish - dev .migrate: stage: publish allow_failure: true script: - ./migrate.sh Migrate: tags: - migration extends: .migrate environment: name: dev A tag instrui nosso executor gerado anteriormente a reagir a esta tarefa e executar scripts na seção . A sequência identifica o estágio ao qual este trabalho pertence. Se necessário, o mesmo executor pode trabalhar em vários projetos ao mesmo tempo. O bloco de ambiente refere-se ao . Este é um tipo de painel onde você pode visualizar o status de seus estandes (desenvolvimento, pré-produção, produção, etc.) e realizar ações como implantações manuais. Além disso, variáveis vinculadas ao ambiente podem ser configuradas; no entanto, não tive a oportunidade de testar esse recurso premium. migration script stage ambiente Rejeição de medidas com erros Você pode interromper a mesclagem correspondente caso algo dê errado com o procedimento de implantação. Em particular, isto é útil se os testes forem integrados no CI/CD como uma fase independente. Embora o Liquibase não tenha testes em nosso exemplo, ele pode funcionar mal se forem inseridos caminhos de arquivo incorretos, por exemplo. Todas as mesclagens não serão permitidas se a caixa de seleção não estiver marcada após a configuração do CI/CD. Últimos retoques Vamos criar um arquivo de migração e habilitá-lo. Para fazer isso, precisamos criar o arquivo como ponto de entrada. changelog-master.xml É uma boa prática ter vários changelog.xml para um gerenciamento mais flexível. Você pode construir uma hierarquia de changelog a partir deles. Porém, em nosso exemplo usaremos uma forma mais simples. <?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> É uma boa prática nomear as migrações usando data e hora. Isso evitará quebrar a classificação das migrações quando uma grande equipe de desenvolvimento estiver trabalhando ao mesmo tempo. --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; Você pode usar diferentes formatos XML, YAML ou JSON para descrever migrações, mas SQL é o mais fácil de ler para meu gosto. Tentamos executar e tudo dá certo. Verifique nosso banco de dados e veja a entrada no databasechangelog. Conclusão Neste artigo, discutimos como implantar o GitLab você mesmo, baixar e configurar executores e, o mais importante, integrar um sistema de migração de banco de dados ao seu processo de CI/CD. Espero que este guia o ajude a colocá-lo em ação.
