Gestão de Configuração e Mudanças

Prévia do material em texto

GESTÃO DE CONFIGURAÇÃO E MUDANÇAS
Gestão de Configuração e Mudanças (GCM) é um conjunto de processos, técnicas e ferramentas que ajudam a gerenciar e controlar as alterações feitas durante o ciclo de vida do desenvolvimento de software.
Itens de configuração são partes individuais de um sistema gerenciadas durante o ciclo de vida de um projeto:
· Código Fonte: 
· Artefatos de Design: 
· Documentação: 
· Dados de Configuração:
· Ferramentas de Construção: 
· Binários e Releases: 
· Testes e Dados de Teste:
Processo de Gerenciamento de Configuração e Mudança, possui 5 atividades principais
1. Identificação dos itens
2. Controle de Versão
3. Controle de Mudança 
4. Auditoria
5. Status
1. Identificação de Itens de Configuração: A identificação é o primeiro passo na GCM. Aqui, os itens de configuração que precisam ser gerenciados são identificados. Inclui código-fonte, documentação, artefatos de design, dados de configuração, ferramentas de construção, binários, testes e dados de teste. Cada item de configuração é então rotulado de forma única para garantir a rastreabilidade.
2. Controle de Versão: O controle de versão é a prática de gerenciar diferentes versões de itens de configuração. Isso envolve o rastreamento e o controle de alterações nos itens de configuração ao longo do tempo, de forma que as versões específicas possam ser recuperadas conforme necessário. Muitas vezes é realizado usando ferramentas de controle de versão como Git ou SVN.
3. Controle de Mudança: O controle de mudança envolve o gerenciamento das alterações nos itens de configuração. Inclui a avaliação e aprovação de propostas de mudança, a implementação de mudanças aprovadas e a revisão das mudanças após a implementação. O objetivo é minimizar o impacto das mudanças na qualidade do software e na continuidade do projeto.
4. Auditoria de Configuração: A auditoria de configuração é o processo de verificar se a configuração atual do software está de acordo com as informações documentadas sobre a configuração. Compreende a verificação da consistência e completude dos itens de configuração e o cumprimento das políticas e procedimentos de GCM.
5. Relatório de Status: O relatório de status envolve o fornecimento de informações atualizadas sobre o estado dos itens de configuração e as mudanças que foram feitas. Abrange informações sobre quais mudanças foram implementadas, quais estão pendentes e quais foram rejeitadas, além do status atual de cada item de configuração.
Plano/Planejamento e Implementação de Gestão de Configuração e Mudanças
O desenvolvimento do Plano de Gestão de Configuração e Mudanças descreve as políticas, procedimentos e responsabilidades para o gerenciamento de itens de configuração e mudanças durante o ciclo de vida do projeto. O Plano de GCM geralmente inclui os seguintes componentes:
Introdução: É o ponto de partida do plano de GCM. Deve incluir uma breve descrição do projeto e o propósito do plano de GCM.
Definição de Itens de Configuração: Quais elementos do projeto serão tratados como itens de configuração. 
Processos de GCM: Processos específicos que serão usados para gerenciar os itens de configuração e controlar as mudanças. Abrange processos de identificação, controle de versão, controle de mudança, auditoria de configuração e relatório de status.
Responsabilidades e Recursos: As responsabilidades de diferentes partes interessadas no processo de GCM são definidas. Compreende desenvolvedores, gerentes de projeto, equipes de qualidade, entre outros. Além disso, os recursos necessários para implementar o plano de GCM são identificados.
Ferramentas de GCM: Descreve quais ferramentas serão usadas para suportar os processos de GCM. Pode incluir ferramentas de controle de versão como Git, ferramentas de rastreamento de problemas como Jira, e outras
Procedimentos de Auditoria e Revisão: O plano deve definir como as auditorias de configuração e as revisões serão conduzidas para garantir que o plano de GCM está sendo seguido e que os itens de configuração estão sendo devidamente gerenciados.
Treinamento e Educação: O plano deve descrever qualquer treinamento ou educação necessária para garantir que todos os envolvidos no projeto compreendam e possam seguir o plano de GCM.
Ferramentas
Gestão de Mudanças: O objetivo da gestão de mudanças em projetos de software é garantir que todas as mudanças sejam rastreadas e controladas, para evitar problemas que podem surgir de mudanças não controladas, como a introdução de novos defeitos ou a reaparecimento de defeitos antigos, em sistema de informação e de software.
O processo envolve várias etapas, tais como:
1. Identificar
2. Registrar
3. Analisar
4. Decidir 
5. Planejar
6. Implementar
7. Verificar
8. Revisar
1. Identificação da Mudança: Uma alteração é identificada, geralmente por uma parte interessada no projeto, como um membro da equipe, cliente ou usuário.
2. Registro da Mudança: A mudança é documentada em um sistema de rastreamento de mudanças. Detalhes como a descrição da mudança, o motivo da mudança, e a pessoa que a identificou são incluídos.
3. Análise da Mudança: A mudança é avaliada em termos de seu impacto nos negócios, custos, tempo, recursos e riscos envolvidos.
4. Decisão: O Comitê de Controle de Mudanças (CCM) toma uma decisão sobre a mudança - seja para aprovar, rejeitar ou pedir mais informações.
5. Planejamento: Se a mudança for aprovada, um plano é desenvolvido para implementá-la. O plano incluiauditoria:
· tarefas, 
· recursos, 
· prazos e 
· medidas de sucesso.
6. Implementação: A mudança é implementada conforme planejado.
7. Verificação: Após a implementação, a mudança é testada e verificada para garantir que tenha sido implementada corretamente e esteja funcionando conforme esperado.
8. Revisão: A eficácia da mudança é avaliada. Se a mudança não atender aos critérios de sucesso, pode ser necessário voltar à fase de planejamento ou análise.
Avaliação de Impacto:
A avaliação de impacto envolve a análise do impacto potencial que uma mudança proposta terá em um projeto ou sistema. Isso inclui o impacto no cronograma do projeto, nos custos, nos recursos necessários, na funcionalidade do sistema, na experiência do usuário e em outros fatores. A avaliação também deve considerar o risco associado à mudança, incluindo o potencial para introduzir novos bugs ou problemas de desempenho.
Aprovação de Mudanças:
Após a avaliação de impacto, a mudança proposta é submetida para aprovação. Em muitas organizações, isso é feito por um Comitê de Controle de Mudanças (CCM), que é um grupo de partes interessadas que têm a autoridade para aprovar ou rejeitar mudanças. O CCM irá considerar a avaliação de impacto e quaisquer outros fatores relevantes, como as prioridades do negócio e a estratégia geral do projeto, ao tomar sua decisão.
Implementação de Mudanças: 
Se a mudança for aprovada, o próximo passo é a implementação. Isso envolve a realização das alterações necessárias no sistema. Dependendo da natureza da mudança, isso pode envolver a codificação de novas funcionalidades, a correção de bugs, a alteração da arquitetura do sistema, a modificação da documentação, entre outras. Durante a implementação, é importante seguir todas as práticas de desenvolvimento de software relevantes para garantir que a mudança seja implementada corretamente. Isso pode incluir a realização de revisões de código, a execução de testes automatizados e a documentação adequada da mudança.
Controle de GCM
O controle de GCM envolve a monitoração e ajuste do processo de GCM para garantir que ele continue a atender às necessidades da organização. Abrange a análise de métricas de GCM, como o número de mudanças implementadas, o tempo médio para processar mudanças, o número de problemas encontrados durante as auditorias de GCM, entre outros.
Git
Controle de Versão Distribuído: O Git permite que cada desenvolvedor tenha uma cópia completa do histórico de desenvolvimento em sua máquina local. Isso significa que a maioria das operações pode ser feita localmente sem a necessidade de uma conexãocom a rede. Isso torna o Git muito rápido e permite que os desenvolvedores trabalhem offline.
Git tem Integridade: Tudo no Git passa por uma soma de verificações (checksum) antes de ser armazenado e é referenciado por esse checksum. Isto significa que é impossível mudar o conteúdo de qualquer arquivo ou pasta sem que Git saiba. Esta funcionalidade está incorporada no Git nos níveis mais baixos e é parte integrante de sua filosofia. Você não perderá informação durante a transferência e não receberá um arquivo corrompido sem que o Git seja capaz de detectar. O mecanismo que o Git utiliza para esta soma de verificação é chamado um hash SHA-1. Esta é uma sequência de 40 caracteres composta de caracteres hexadecimais (0-9 e-f) e é calculada com base no conteúdo de uma estrutura de arquivo ou diretório no Git. Um hash SHA-1 é algo como o seguinte:
24b9da6552252987aa493b52f8696cd6d3b00373, O Git armazena tudo em seu banco de dados não pelo nome do arquivo, mas pelo valor de hash do seu conteúdo. O checksum do Git é um valor de verificação de integridade calculado para tudo o que é armazenado na ferramenta de controle de versão Git. 
Branching e Merging: Git oferece funcionalidades para criação de branches (ramificações) e merging (fusão de arquivos). Isso permite que desenvolvedores trabalhem em diferentes funcionalidades ou bugs simultaneamente sem afetar o código principal. O processo de Merging costuma ser relativamente fácil no Git.
Estados do Git
O Git tem um modelo de manipulação de dados que pode ser pensado como três "áreas" ou "estados" principais, que são:
1 - Modified (Modificado): Neste estágio, as alterações foram feitas nos arquivos, mas ainda não foram preparadas para commit. Isso significa que o Git reconheceu que o arquivo foi alterado no diretório de trabalho, mas as alterações ainda não foram confirmadas para serem permanentes no repositório. Essas alterações ainda não estão na área de preparo (staging area).
2 - Staged (Preparado): Neste estágio, o Git sabe que você modificou os arquivos e quer incluir essas modificações em seu próximo commit. Você informa ao Git que quer incluir as atualizações em um determinado arquivo para o próximo commit adicionando esses arquivos à área de preparo. O comando 'git add' é usado para adicionar um arquivo da área de trabalho para a área de preparo. As alterações neste estágio não serão "commitadas" até que o usuário decida fazê-lo.
3 - Commit (Committed): Este estágio representa os dados que foram salvos ou "commitados" no diretório .git, que é o diretório onde o Git armazena metadados e histórico do objeto para o repositório. Uma vez que um usuário commita suas alterações, todas as modificações são armazenadas neste local. Esta é a versão final do projeto e o Git a usa para saber o que exatamente mudou desde o último commit. 
Isso nos leva a três seções principais de um projeto Git: o diretório Git, o diretório de trabalho e área de preparo.
O diretório Git (.git directory / Repository)é onde o Git armazena os metadados e o banco de dados de objetos de seu projeto. Esta é a parte mais importante do Git, e é o que é copiado quando você clona um repositório de outro computador.
O diretório de trabalho (Working Directory)é uma simples cópia de uma versão do projeto. Esses arquivos são pegos do banco de dados compactado no diretório Git e colocados no disco para você usar ou modificar.
A área de preparo (Staging Area) é um arquivo, geralmente contido em seu diretório Git, que armazena informações sobre o que vai entrar em seu próximo commit. É por vezes referido como o “índice”, mas também é comum referir-se a ele como área de preparo (staging area).
O fluxo de trabalho básico Git é algo assim:
1. Você modifica arquivos no seu diretório de trabalho.
2. Você prepara os arquivos, adicionando imagens deles à sua área de preparo.
3. Você faz commit, o que leva os arquivos como eles estão na área de preparo e armazena essas imagens de forma permanente para o diretório do Git.
O arquivo .gitignore
O arquivo .gitignore é um arquivo de texto que diz ao Git quais arquivos ou diretórios ignorar no projeto. Ou seja, arquivos listados no .gitignore não serão rastreados pelo Git e não aparecerão na lista de arquivos que foram modificados ou não estão sendo rastreados.
Comandos Git
git init: Criar novo repositório
git status: Verificar estado dos arquivos/diretórios
git commit meu_arquivo.txt: Comitar um arquivo
git commit meu_arquivo.txt meu_outro_arquivo.txt: Comitar vários arquivos
Git add: Adicionar todos os arquivos/diretórios
git add meu_arquivo.txt: Adicionar um arquivo em específico((staged area)
git add meu_diretorio : Adicionar um diretório em específico 
Git push -u origin master: Enviar arquivos/diretórios para o repositório remoto.
Git pull: Atualizar os arquivos no branch atual. 
Git log: exibir histórico
Git send-e-mail: envia um e-mail.
GitHub
GitHub (https://github.com) é um serviço de hospedagem de repositórios Git baseado na web que facilita o controle de versão e a colaboração. Embora Git seja um sistema de controle de versão que pode ser usado localmente, o GitHub fornece uma interface fácil de usar e baseada na web, e adiciona muitos recursos que facilitam o trabalho colaborativo em projetos de todos os tamanhos.
Colaboração em tempo real: desenvolvedores trabalhando juntos em projetos de qualquer lugar do mundo.
Contribuição para projetos de código aberto: O site hospeda milhões de repositórios de código aberto. Qualquer pessoa pode contribuir para esses projetos ou usar o código para os seus próprios projetos.
Rastreamento de Problemas: GitHub possui um sistema de rastreamento de problemas que permite aos usuários relatar bugs ou solicitar novos recursos. 
Documentação: O serviço permite que os repositórios incluam arquivos de documentação, como READMEs, para explicar o projeto. Isso torna mais fácil para os outros entenderem o propósito de um projeto e como contribuir para ele.
Integração com outras ferramentas: O repositório pode ser integrado com muitas outras ferramentas de desenvolvimento, como sistemas de integração contínua (CI/CD), e pode automatizar o teste e a implantação de seu código.
Revisão de Código e Pull Requests: O GitHub introduziu a ideia de Pull Requests, que é uma maneira de propor mudanças que podem ser revisadas e discutidas antes de serem integradas ao projeto. Isso incentiva a revisão de código e a colaboração.
GitHub Pages: Você pode hospedar sites estáticos diretamente de um repositório no GitHub. Esta é uma boa maneira de criar sites para projetos, currículos, blogs e muito mais.
Controle de Versão: E, claro, o GitHub fornece todos os benefícios do controle de versão do Git, como a capacidade de rastrear mudanças, criar branches, fazer merge de código e muito mais.
Algumas Funcionalidades/conceitos do GitHub
Forks: Um "fork" é uma cópia de um repositório original que reside na sua conta do GitHub. Isso permite que você modifique um projeto sem afetar o original. Forks são usados para propor mudanças no projeto original através de Pull Requests.
Pull Requests (PRs): No GitHub, uma Pull Request (PR) é a maneira de você propor modificações no código de um repositório. Você faz isso criando um "fork" do repositório, fazendo suas alterações nesse fork, e então pedindo que o mantenedor do repositório original "puxe" suas alterações para o repositório original. As PRs são locais onde revisões de código acontecem. Uma vez que uma PR é aprovada, as alterações podem ser mergeadas no projeto.
Issues: Issues no GitHub são como tarefas, sugestões ou bugs relatados para um projeto. Qualquer pessoa pode criar uma issue em um repositório público para relatar um bug ou sugerir novos recursos. As issues podem ser atribuídas a colaboradores, ter etiquetas anexadas para fácil organização, e serem referenciadas em PRs.
GitHub Actions: GitHub Actions é uma ferramenta de automação de CI/CD (Integração Contínua / Implantação Contínua) que permite automatizar fluxos de trabalho diretamente dentro de seu repositório no GitHub.Gitlab
O GitLab é uma plataforma de DevOps completa e de código aberto que permite que desenvolvedores colaborem em projetos de software. Assim como o GitHub, o GitLab usa o Git como seu sistema de controle de versão. No entanto, o GitLab se destaca por fornecer um conjunto mais amplo de ferramentas integradas para o ciclo de vida completo do desenvolvimento de software.
Instalação e Hospedagem: O GitLab oferece a possibilidade de hospedagem na nuvem (GitLab.com) semelhante ao GitHub. No entanto, uma das principais diferenças é que o GitLab também permite que você hospede seu próprio servidor GitLab em suas próprias instalações (GitLab Self-Hosted). Isso é útil para empresas que desejam manter seu código fonte e dados de projeto em seus próprios servidores por razões de segurança ou conformidade. O GitHub também oferece uma opção semelhante chamada GitHub Enterprise Server, mas o GitLab é mais conhecido por sua solução self-hosted.
Ferramentas de DevOps integradas: Ambas as plataformas fornecem integração com várias ferramentas de terceiros. No entanto, o GitLab tem uma gama mais ampla de ferramentas de DevOps integradas, como a integração contínua / implantação (CI / CD), monitoramento de aplicativos, gerenciamento de segurança e outras coisas mais.
Interface do usuário: A interface do usuário entre as duas plataformas é uma questão de preferência pessoal. Alguns podem achar que o GitHub tem uma interface mais limpa e fácil de usar, enquanto outros podem preferir o GitLab por seus recursos adicionais e personalização.
Importância da Comunidade: O GitHub tem uma grande comunidade de desenvolvedores e é o lar de uma infinidade de projetos de código aberto. Isso faz do GitHub a escolha preferencial para colaboração e contribuição em projetos de código aberto.
Visibilidade dos Projetos: Você pode ter repositórios públicos e privados, no GitHub e GitLab. Mas o GitLab também oferece a opção de ter projetos com visibilidade "interna", que são acessíveis a qualquer usuário logado na instância do GitLab, fornecendo um nível intermediário de privacidade
CONTROLE DE VERSÃO (VERSIONAMENTO
A imagem ilustra os conceitos de troncos, branches, merges e tags no controle de versão.
Trunks (Troncos): Representados pelos blocos verdes (1 e 4), o tronco é a linha principal de desenvolvimento onde o código mais estável reside;
Branches (Ramificações): Indicados pelos blocos amarelos (2, 3, 5, 6, 7, 8, 10), são ramificações para desenvolver novas funcionalidades ou corrigir bugs sem afetar o tronco;
Merges (Mesclagens): As setas vermelhas mostram onde as alterações das branches são integradas de volta ao tronco (3 em 4, 7 em 9). O merge é um processo de integrar as mudanças de uma branch de volta ao tronco ou outra Branch;
Tags: Marcadores para versões específicas do código, representados pelos blocos azuis (T1, T2). Os marcadores que representam versões específicas do código, geralmente usados para releases;
Discontinued Development Branch: Representada pelo bloco rosa (10), é uma ramificação de desenvolvimento que foi descontinuada.
Sistemas de Controle de Versão
Existem dois principais tipos de sistemas de controle de versão: centralizado (SVN) e distribuído ( Git).
Centralizado: Subversion (SVN), Perforce: Neste modelo, existe um único servidor central que contém todas as versões dos arquivos do projeto. Os desenvolvedores podem fazer check-out de arquivos deste servidor central, mas geralmente apenas um desenvolvedor por vez pode fazer mudanças em um arquivo específico. Após as alterações, eles fazem check-in/commit das atualizações de volta ao servidor central.
Distribuído: Git, Mercurial: Neste modelo, cada desenvolvedor tem uma cópia local do repositório inteiro, incluindo todo o histórico de versões. Isso significa que os desenvolvedores podem fazer muitas operações (como commits e diffs) localmente, sem necessidade de conexão de rede. Quando os desenvolvedores querem compartilhar suas alterações, eles as "empurram" (push) para um repositório compartilhado. A vantagem é a maior resiliência e flexibilidade, pois cada cópia é um backup completo do repositório.
A comunicação entre o servidor principal e as áreas de trabalho funciona com outras duas operações, para atualizar e mesclar o projeto, chamadas de pull (puxar) e push (empurrar).
Pull: Permite que você pegue a versão do projeto de um repositório remoto e a mescle com a sua cópia local. É usada para atualizar seu repositório local com as mudanças feitas por outros desenvolvedores.
Push: É o inverso do pull. Com o push, você envia suas alterações locais para o repositório remoto, compartilhando suas atualizações com outros desenvolvedores.
Baseline: Pode ser entendida como uma "fotografia" ou um estado estável e aprovado de um sistema em um determinado momento do ciclo de vida do projeto. Cada baseline é uma versão especificada de um sistema durante o seu ciclo de vida e serve como um ponto de partida para futuras mudanças.
Existem três tipos comuns de baselines em gestão de configuração:
1.Baseline Funcional: Estabelecida após a fase de requisitos. Reflete todos os requisitos do cliente e é usada como uma base para o desenvolvimento de software.
2. Baseline de Alocação: Estabelecida após a fase de projeto e inclui uma arquitetura de software aprovada que detalha a estrutura e as relações dos componentes do sistema.
3. Baseline de Produto: Estabelecida após a fase de implementação e inclui o código-fonte final, dados, documentação do usuário e de sistema, e outros entregáveis necessários.
DATA BASE MIGRATIONRATION S
Database Migrations, ou Schema Migrations, são processos que gerenciam e aplicam mudanças na estrutura de um banco de dados de maneira organizada e controlada. Essa prática assegura que a estrutura do banco de dados evolua em sincronização com o código da aplicação, permitindo que todos os ambientes (desenvolvimento, teste, produção) mantenham consistência na estrutura do banco de dados.
Assim como o código-fonte, o esquema do banco de dados é versionado. Cada alteração é registrada como uma “migration” (migração), que descreve as mudanças específicas a serem aplicadas no banco de dados. Ferramentas de migrations automatizam a aplicação dessas mudanças, reduzindo a possibilidade de erros humanos e assegurando que as alterações sejam aplicadas de forma consistente.
Todas as mudanças no esquema são registradas e podem ser revertidas se necessário, o que facilita a auditoria e o diagnóstico de problemas. As migrations garantem que todos os ambientes estejam sempre em sincronia, evitando discrepâncias entre as diferentes instâncias do banco de dados. Os desenvolvedores escrevem scripts que descrevem as alterações necessárias, como criar ou alterar tabelas e colunas. Estes scripts são organizados de forma sequencial para assegurar a ordem correta de aplicação.
As migrations são aplicadas ao banco de dados em ordem cronológica. Ferramentas como Flyway, Liquibase e Entity Framework gerenciam a aplicação das migrations, registrando cada passo para garantir que todas as mudanças sejam realizadas corretamente.
Em um estado estável, uma versão de uma aplicação compreende apenas uma versão do esquema do banco de dados.
A estratégia mais simples para realizar uma migração de esquema é interromper a aplicação, executar a migração e reiniciar a aplicação com a nova versão. Embora simples, essa abordagem causa downtime, o que pode ser aceitável dependendo da criticidade do sistema e dos padrões de uso. No entanto, em alguns casos, nenhum downtime pode ser tolerado. Para esses cenários, estratégias de zero downtime:
Dual Writing: Estratégia utilizada durante migrações de esquema de banco de dados para evitar downtime. Nessa abordagem, o esquema do banco é preparado para suportar dados nos formatos antigo e novo simultaneamente. A aplicação é então atualizada para ESCREVER DADOS EM AMBOS OS FORMATOS, garantindo consistência entre eles. Após essa etapa, é executado um processo de backfill, que copia os dados existentes no formato antigo parao novo formato. Assim, o banco de dados passa a ter uma réplica completa dos dados em ambos os formatos. Posteriormente, a aplicação é atualizada para ler dados apenas no novo formato e parar de escrever no formato antigo. Finalmente, os dados no formato antigo são removidos do esquema.
Dual Reading: Envolve a preparação do esquema para suportar dados nos formatos antigo e novo, assim como no dual writing. No entanto, a aplicação é atualizada para LER dados de ambos os formatos e operar com qualquer formato presente. Depois disso, a aplicação é ATUALIZADA para PARAR DE ESCREVER NO FORMATO ANTIGO e começar a ESCREVER APENAS NO NOVO FORMATO. Um backfill é executado para migrar todos os dados do formato antigo para o novo. Após essa etapa, a aplicação é modificada novamente para parar de ler dados no formato antigo, e os dados no formato antigo são removidos do esquema.
A combinação de dual reading e dual writing é uma abordagem mais robusta que usa ambas as estratégias. A aplicação é modificada para ler e escrever em ambos os formatos, o que permite maior flexibilidade e controle sobre o processo de migração. Essa combinação permite que o backfill seja realizado em lotes menores, utilizando flags de funcionalidade para alternar entre os caminhos de leitura e escrita de forma independente.
Embora essa abordagem ofereça maior controle e reduza os riscos de inconsistências, ela também adiciona complexidade ao processo de migração.
FLYWAY
A biblioteca Flyway é uma ferramenta de migração de banco de dados baseada em Java, amplamente utilizada em ambientes de desenvolvimento para gerenciar mudanças na estrutura de bancos de dados (como MySQL, PostgreSQL, SQL Server, entre outros). Ela permite controlar e versionar scripts de migração SQL ou Java, aplicando atualizações incrementais ao banco de dados de forma automatizada. Isso é especialmente útil para projetos que exigem colaboração e controle rigoroso de versões, pois Flyway garante que todas as instâncias do banco estejam sempre na mesma versão. 
Características do Flyway
1. Migrador incremental: O Flyway gerencia alterações de esquema de forma incremental, aplicando migrações na sequência e evitando conflitos.
2. Baseado em convenções: Ele usa convenções de nomeação para versionamento, facilitando a identificação de cada migração.
3. Compatibilidade com múltiplos bancos de dados: É compatível com uma ampla variedade de SGBDs (Sistemas de Gerenciamento de Banco de Dados), incluindo:
· MySQL, PostgreSQL, Oracle, SQL Server, SQLite, H2, entre outros.
4. Suporte a scripts SQL e Java: Permite escrever migrações tanto com scripts SQL quanto em Java, sendo flexível para diferentes necessidades.
5. Compatível com CI/CD: O Flyway se integra facilmente a pipelines de CI/CD e ferramentas de DevOps, como Jenkins, GitLab CI, e CircleCI.
6. Desenvolvimento declarativo: É fácil para desenvolvedores declararem mudanças no banco de dados, mantendo um controle versionado das alterações.
Principais Funcionalidades do Flyway
1. Controle de versão: Armazena um histórico de todas as migrações já aplicadas ao banco de dados.
2. Migrações incrementais: Permite aplicar mudanças gradativamente, gerando um histórico das atualizações.
3. Rollback: Em caso de erro, você pode desfazer uma migração, caso isso tenha sido configurado.
4. Suporte a scripts SQL e Java: O Flyway permite escrever migrações tanto em SQL quanto em Java, adaptando-se a diferentes necessidades.
5. Configuração e integração: Pode ser facilmente configurado em várias ferramentas de CI/CD e utilizado com Spring Boot, Maven, Gradle, e outros frameworks de desenvolvimento.
Como funciona o Flyway?
O Flyway trabalha em torno de um diretório de migrações que contém scripts organizados de forma cronológica ou incremental. Estes scripts devem seguir uma convenção de nome que o Flyway utiliza para determinar a ordem de aplicação das migrações. Cada migração é executada em sequência, permitindo que mudanças estruturais e de dados sejam aplicadas progressivamente.
Comandos do Flyway
1. migrate: Aplica todas as migrações pendentes ao banco de dados, criando uma tabela de metadados (flyway_schema_history) onde cada migração é registrada.
2. clean: Apaga todos os objetos do banco de dados gerenciados pelo Flyway. Geralmente, usado em ambientes de desenvolvimento.
3. info: Mostra o estado atual do banco de dados em relação às migrações, listando as que já foram aplicadas e as pendentes.
4. validate: Verifica a consistência das migrações aplicadas com o estado atual do banco de dados. Útil para garantir que as versões estejam alinhadas.
5. baseline: Marca o banco de dados existente com um ponto de partida (baseline), para integrá-lo ao controle do Flyway.
6. repair: Corrige entradas corrompidas na tabela de metadados (flyway_schema_history).
Vantagens e Desvantagens do Flyway
Vantagens
· Controle automatizado de versões: Reduz a complexidade da gestão de mudanças no banco.
· Integração CI/CD: Suporte nativo a ferramentas de CI/CD.
· Simplicidade: A configuração é leve, e a curva de aprendizado é curta.
· Estabilidade e suporte: Flyway é amplamente usado e bem documentado, com uma grande comunidade de suporte.
Desvantagens
· Sem rollback automático: É necessário desenvolver scripts manuais para revertê-las.
· Gerenciamento manual de conflitos: Não possui um sistema de merge de migrações, portanto, é preciso cuidar de conflitos manualmente.
· Limitado para grandes alterações: Pode ser mais desafiador para projetos que exigem grandes refatorações ou atualizações de esquema.
Boas Práticas com o Flyway
· Defina um baseline: Especialmente útil ao introduzir o Flyway em um banco de dados já existente, um baseline define um ponto inicial para que o Flyway gerencie as próximas migrações.
· Crie scripts de rollback manualmente: Em caso de mudanças sensíveis, crie scripts reversíveis que podem ser usados caso uma migração falhe.
· Use versões pequenas e frequentes: É uma prática recomendada aplicar pequenas alterações de forma incremental, facilitando a detecção e solução de problemas.
· Integre ao CI/CD: Automatize a execução do Flyway nos pipelines de CI/CD para garantir que as migrações sejam consistentes entre os ambientes.
Conclusão
O Flyway é uma ferramenta eficaz para o controle de versão e migração de banco de dados, ideal para projetos em ambientes de desenvolvimento ágil e para equipes que buscam automação e rastreabilidade no gerenciamento de esquemas de banco de dados. 
image1.png
image2.png
image3.png
image4.png