Ir para o conteúdo principal

[PROPOSTA] Disponibilização de Bases de Dados utilizando Continous Deploy

CENÁRIO ATUAL

A grande maioria dos desenvolvedores não possuem a devida preocupação com a integridade estrutural da base de dados durante o desenvolvimento das aplicações. No ambiente local, os desenvolvedores modificam tabelas vazias sem se preocupar com nenhum tipo de restrição presente nos dados em produção. No ambiente de desenvolvimento, os dados são comumente apagados sempre que alguma estrutura "quebra". Ambas as ações não podem ser realizadas nos dados em produção, tornando o processo de atualização da estrutura bem mais complexo, sendo muitas vezes necessária a migração dos dados para tabelas intermediárias entre outras abordagens que demandam de tempo do time de banco de dados e acabam atrasando a disponibilização da aplicação para produção.

PROBLEMA

Da Perspectiva da Organização

  • Os times de desenvolvimento não possuem autonomia para a manutenção da modelagem dos dados;

Da Perspectiva da Gerência de Desenvolvimento

  • A entrega fica aguardando a liberação por parte da equipe de banco de dados;

Da Perspectiva da Gerência de Dados

  • As demandas para alteração da estrutura de banco de dados são serviços prioritárias, não planejadas, e normalmente custosas, prejudicando o fluxo de trabalho.

PREMISSAS

  1. A grande maioria dos sistemas da nossa organização utiliza C# + Entity FrameWork + SQLServer;
  2. A organização tem interesse em desenvolver uma cultura de Continuous Deployment;

ENVOLVIDOS

  • Baymax Business Inteligence Team
  • BlackOps - Integration Team

PROPOSTA

  1. Auto-Migrate
    Essa proposta tem como fundamento aproveitar-se dos processos de automação, hoje vigentes na organização, para estabelecer um novo fluxo de submissão, em parceria com o time de DEV-OPS. A proposta consiste em validar automaticamente se as migrações escritas não violam nenhuma restrição de integridade (proposta no modelo relacional), antes de permitir que o código seja incorporado ao QA. As etapas são descritas a seguir:
    1. Programador solicita mesclagem de código com ambiente de QA.
    2. [AUTO] Aplica-se as migrações no ambiente de Produção SEM PERSISTIR ALTERAÇÕES (ROLLBACK).
    3. [POSITIVO] [AUTO] Substitui-se a base do QA por uma cópia atualizada da base de produção.
    4. [AUTO] Aplica-se as migrações no ambiente do QA COM PERSISTÊNCIA DE DADOS (COMMIT).
    5. [POSITIVO] [AUTO] Código aprovado, continuar para a etapa de construir a aplicação.

      3. [NEGATIVO][AUTO] Em caso de falha na ETAPA 2, o relatório com os erros de migração será fornecido ao desenvolvedor. O código não será incorporado ao ambiente de QA até que sejam dadas as devidas tratativas.

      5.[NEGATIVO][AUTO] Em caso de falha na ETAPA 4, o relatório com erros será disponibilizado para o desenvolvedor, para o time de devops e para o time de banco de dados. Permitindo com que mitiguem a falha no processo.

      O desafio nesta proposta é automatizar as etapas (2 a 5) dentro do atual pipe de submissão de código fonte, sem que o processo se torne demasiadamente custo no quesito tempo e nem muito complexo.

VALIDAÇÃO

Para validação da proposta, optamos pela realização de um estudo piloto. Neste estudo, apresentaremos para um dos times de desenvolvimento a abordagem proposta e avaliaremos o desempenho dos mesmos em relação ao novo fluxo.

ETAPAS
  1. Contextualização
    Nesta etapa, os participantes serão ambientados e conscientizados sobre qual problema pretendemos apresentar a solução e qual a importância do mesmo. Pode ser interessante apresentar as dificuldades mais comuns.
  2. Apresentação
    Nesta etapa, os participantes acompanharão uma apresentação de como será o novo fluxo.
  3. Hands-On
    Nesta etapa, será efetivamente aplicada a nova abordagem, onde os participantes serão assistidos durante o processo.
  4. Consolidação
    Para consolidação, um pequeno manual em formato de guia será disponibilizado à equipe.

APLICAÇÃO

Após validação do estudo piloto, a solução será oficialmente apresentada em uma SixFire (a definir data), para que todos os times possam acompanhar as mudanças. Junto com a apresentação, serão fornecidos materiais de apoio aos usuários.

CRONOGRAMA

A aplicação do estudo piloto se iniciará na Sprint consecutiva a validação e implantação da proposta em ambiente controlado (Pipeline de 1 projeto), por parte da equipe de DEVOPS.

REFERÊNCIAS

[LINK] Altassian - "What is Continuous Deployment?"
[LINK] Opus-Software - "Entrega Contínua - O que é e como aplicar?"

https://hackernoon.com/database-changes-can-be-scary-how-r1hy2gfe
https://danianepg.medium.com/building-a-continuous-delivery-pipeline-for-database-migrations-with-gitlab-and-aws-c81b47f1a56a
https://www.infoq.com/articles/deployment-pipeline-database-changes/

[2020] https://sci-hub.se/https://ieeexplore.ieee.org/abstract/document/9054796
[2017] https://sci-hub.se/https://ieeexplore.ieee.org/abstract/document/7965438
[2015] https://sci-hub.se/https://ieeexplore.ieee.org/abstract/document/7169446

 

Nenhum comentário
Voltar ao topo