Conheça o FLAIR DevOps
Hoje muito se fala sobre DevOps e realmente é muito importante falar desse assunto. Muitas empresas já adotaram esta cultura e muitas estão aderindo à este propósito. Normalmente, o principal ponto de partida para isso, acaba sendo mais “ferramental” do que “conceitual”, iniciando-se pela automatização do fluxo de distribuição de software, mais especificamente o fluxo de CI/CD. O grande problema é que ferramentas por si só, não resolvem problema algum. Precisamos ir além, precisamos entender de fato como criar um fluxo de entrega de software evolutivo, que nos ajude a entregar software rápido e com qualidade, hoje e amanhã.
Para isso, hoje vamos falar sobre o Flair DevOps, um novo framework, conceitual, que visa ajudar times multidisciplinares na elaboração de pipelines de excelência.
O Framework FLAIR
Flair pode ser traduzido de forma livre como “talento”, e, de certa forma, essa tradução é totalmente coerente com o seu significado: O Flair é um framework que define os cinco principais aspectos de um bom fluxo de CI/CD.
Quando aplicado na prática, os benefícios são gigantescos, incluindo uma construção reaproveitável, garantia da qualidade da release distribuída, mudanças imediatas de versões, automatização em alto nível e tudo isso em poucos instantes.
Vamos detalhar um pouco mais sobre cada um dos cinco pilares do Flair.
Fast Execution
Um pipeline, de ponta a ponta, deve ser rápido. Não existe um tempo limite para sua execução, mas o ideal é que ocorra em poucos minutos e permita sua execução diversas vezes sequenciais e em paralelo, caso necessário. O fluxo de CI deve ser o responsável pela maior parte do tempo gasto. Já o fluxo de CD, deve ser ainda mais otimizado, possibilitando uma mudança de versão em tempo recorde, seja uma nova versão ou um rollback.
Little Interaction
Em sua totalidade, a interação humana deve ser a mínima possível. Um bom fluxo deve ser iniciado automaticamente após alterações no código-fonte. No caso de falhas, em qualquer momento, o time deve ser notificado. No caso de sucesso, pode ser exigida uma autorização para que o fluxo continue, normalmente quando se trata de um ambiente produtivo. Essa deveria ser a interação humana máxima para que o fluxo ocorra em sua totalidade, sendo tolerada mais de um nível dependente de aprovação de acordo com seu pipeline.
Any Version
O princípio de um fluxo de CI é preparar o artefato e o princípio do fluxo de CD, distribuir. Qualquer versão deve ser passível de ser distribuída há qualquer momento, considerando um artefato disponibilizado anteriormente. Baseado no primeiro tópico deste acrônimo, de forma suficientemente rápida. Para a redistribuição de uma release, a construção do artefato deve ser dispensada, utilizando o artefato previamente criado. Em casos de releases “antigas” é tolerável refazer o processo do início dado possíveis políticas de expurgo e controle de storage.
Identical Context
O seu pipeline deve executar sempre as etapas da mesma forma. Algumas etapas podem ser adicionadas ou omitidas, porém, nunca “alteradas”. Se existe uma etapa de execução de testes para uma determinada ramificação do seu código fonte, para um outro conjunto de branchs, se essa etapa for necessária, deve ser executada de forma idêntica. O código que foi “construído” e “testado”, deve ser o código do artefato. O artefato distribuído no ambiente de homologação ou QA deve ser exatamente o mesmo artefato distribuído no ambiente produtivo. Distribua sempre o mesmo artefato em qualquer ambiente, com alterações somente em variáveis de ambiente, arquivos de configurações e secrets em geral. Por fim, um deploy que apenas altera configurações do seu projeto não deve gerar uma nova versão, dado que o software é o mesmo.
Replicable Flow
Softwares desenvolvidos pelo mesmo time ou até mesmo pela mesma companhia, tendem à ser parecidos na arquitetura, organização e padrões. Um bom pipeline (CI ou CD) deve ser facilmente replicável para projetos similares. Esses fluxos devem ser, preferencialmente, definidos por um arquivo de configuração (normalmente yml) ao invés de criados via interface. Se possível (e aplicável) utilize uma ferramenta para o gerenciamento e a centralização de seus pipelines e configurações.
Os conceitos aqui apresentados, se aplicados em sua totalidade, podem tornar os seus pipelines muito mais eficientes e evolutivos, além de garantir uma automatização real e a capacidade de distribuir rapidamente software de qualidade, um dos princípios da cultura DevOps.
Por se tratar de um novo termo no mercado, o framework ainda necessita de especificações mais detalhadas (prometo explorar mais do assunto em breve) e uma divulgação mais ampla pela comunidade.
Se você gostou do artigo, deixa um joinha e compartilhe com todos! 👍
