Skip to main content

Release Engineering

· 8 min read
Bruno Carneiro

Olá, neste artigo foi falar um pouco sobre Release Engineering, descrevendo alguns pontos de como é a jornada de compilação, ambiente, boas práticas e entrega de código. Esté artigo é inspirado no livro de SRE do Google, muitos conteúdos faço referëncia ao material principalmente no quesito boas práticas. Também irei apresentar como utilizar o ´github actions´ para realizar a configuração de um pipeline para deploy de uma aplicação web (não realizo de fato o deploy, apenas demonstro uma configuração para servir de exemplo).

O que é Release Engineering?​

Disciplina para elaboração e entrega de versões de software. Gerenciamento de código-fonte, compiladores, linguagens de configuração de compilação, ferramentas de compilação automatizadas, gerenciadores de pacotes e instaladores. Seu conjunto de habilidades : desenvolvimento, gerenciamento de configuração, integração de teste, administração de sistema e suporte ao cliente.

Quais são os desafios da Engenharia de Release?​

  • Escolher ferramentas
  • Gerenciamento de código fonte
  • Build lento
  • Padronização de pipeline
  • Segurança
  • Escala
  • Monitoramento
  • Multi-cloud

Quais são os principais desafios para a infraestrutura?​

  • Escolher ferramentas
  • Preço
  • Suporte
  • Integração
  • Custo de otimização
  • Utilização de recursos

O que é um Release Engineer?​

Define as melhores práticas para garantir consistência e repetibilidade dos processos de software

Atividades de um Release Engineer

Boas práticas para trabalhar com Release Engineering segundo o livro de SRE do Google​

Self-service Model​

  • As equipes devem ser autossuficientes para trabalhar em escala
  • As equipes decidem quando e com que frequência gerar uma versão
  • Os processos de liberação podem ser automatizados ao ponto de esforço mínimo
  • Os lançamentos são realmente automáticos, não apenas automatizados

High Velocity​

  • Compilações frequentes têm menos alterações entre as versões
    • Mais fácil de solucionar problemas
  • Builds reconstruídos com frequência para lançar features rapidamente.
    • Facilita os testes e a solução de problemas.
  • Algumas equipes frequentemente criam compilações e selecionam quais implantar
  • Outras equipes adotaram uma abordagem "impulsionar o verde".
    • Implante todas as compilações que passam em todos os testes

Hermetic Builds​

  • As compilações devem ser consistentes e repetíveis.
    • A mesma versão deve ser enviada sem alterações após compilação.
    • Não deve existir alterações realizadas externamente
  • Cherry picking: como corrigir um bug no software em execução.
    • Aplicar somente a correção necessária para corrigir o bug
    • Não enviar soluções que não sejam específicas ao bug em tratamento

Aplicação de Políticas e Procedimentos​

Várias camadas de segurança e controle de acesso determinam quem pode executar operações específicas (normalmente controladas por revisões de código):

  • Aprovação de alterações no código-fonte
  • Especificar as ações a serem executadas durante o processo de liberação
  • Criando uma nova versão
  • Aprovação da proposta de integração inicial e escolhas de versões/pacotes para produção
  • Como implantar uma nova versão
  • Como fazer alterações na configuração de compilação de um projeto

CI/CD Guidelines para Release Engineering​

Continuous Integration (CI):​

Manter todo o código desenvolvido em um local onde se possa realizar build e testes do projeto, além de identificar mudanças nele realizadas. Um exemplo é manter o código em um repositório (github, gitlab, codecommit, outros) com testes, build automatizado, e outras funcionalidades.

Continuous Delivery (CD):​

É uma extensão do Continuous Integration que pode ter passos de pipeline para certificar que a geração de uma release pode ir para produção.

Benefícios​

Velocidade no desenvolvimento

O feedback contínuo permite que os desenvolvedores comprometam alterações menores com mais frequência, em vez de esperar por um lançamento. Velocidade no desenvolvimento

Estabilidade e confiabilidade

Testes automatizados e contínuos garantem que as bases de código permaneçam estáveis e prontas para lançamento a qualquer momento. Estabilidade e confiabilidade

Crescimento do negócio

Livres de tarefas manuais, as organizações podem concentrar recursos em inovação, satisfação do cliente e pagamento de dívidas técnicas. Crescimento do negócio

Exemplo de Pipeline de desenvolvimento​

Boas práticas​

Assim que seu código estiver pronto para ser enviado para o ambiente de produção, a equipe do produto deve seguir alguns passos:

  • Atualização da documentação interna;
  • Atualização da documentação para o usuário final;
  • Criação de changelog para todos os produtos e ou serviços;
  • Aprovação do time de controle de qualidade. Sem a aprovação o time não deve ser enviado para produção;
  • Disponibilização do Release Notes para todos os setores interessados da empresa (marketing, suporte, produto, etc);
  • Equipe de suporte deve ser adequadamente treinada para combater quaisquer problemas que o usuário possa ter;
  • Checklist completo pelo time de Engenharia;
  • Após todos os passos deve ser feita a criação de uma Tag;
  • Utilizar versionamento semântico ou ‘Human Readable Name’;
  • Criação de monitoramento para acompanhar o a nova versão.

CI/CD Checklist​

Transparência​

Se uma compilação falhar, os desenvolvedores precisam avaliar rapidamente o que deu errado e por quê.

Velocidade​

O CI/CD contribui para o desempenho geral do DevOps, principalmente a velocidade.

Resiliência​

Quando usado com outras abordagens, como cobertura de teste, ferramentas de observabilidade e sinalizadores de recursos, o CI/CD torna o software mais resistente a erros

Segurança​

pipeline de CI/CD à prova de futuro tem verificações de código e permissões e fornece uma trilha virtual em papel para falhas de auditoria, violações de segurança e eventos de não conformidade

Estratégias para Deploy​

Recreate​

Recria a aplicação, pode ter downtime

Rolling​

Novas Pods são criadas e vão lentamente substituindo as anteriores

Blue / Green​

QA testes, após aprovação a aplicação é enviada para os usuários

Canary​

O envio da versão é controlada por percentual

A/B Testing​

Várias versões em paralelo. Captura de métricas

Shadow​

Versão A e B em paralelo, o fluxo da versão A vai para B sem afetar o tráfego em produção

Rollback​

Quando disponibilizaram uma versão do qual é necessãrio retornar para a anterior. Essa abordagem geralmente é utilizada por questões de problemas onde a nova versão não pode continuar no ar sendo assim necessário retornar para a versão anterior.

Rollback

O que é Github​

O Github é um serviço web que oferece diversas funcionalidades extras aplicadas ao git.

É como se fosse uma rede social de programadores. Nele você vai poder gratuitamente hospedar seus projetos.

Exemplos de outras ferramentas de versionamento​

  • Gitlab
  • Apache Subversion
  • AWS Codecommit
  • Mercurial
  • CVS
  • Bitbucket

O que é Controle de versão:​

Controle de versão é um sistema que te ajuda a gerenciar o seu código. Ele mantém um registro com as alterações em um arquivo ou até mesmo em um conjunto de arquivos ao longo do seu projeto. Sendo assim, se acontece um erro podemos voltar no tempo (voltar a versões anteriores) e comparar os códigos, ajudando a identificar o erro.

Hands on​

name: CI/CD

on:
  push:
    branches: [ "main" ]

jobs:
  Validation:
    runs-on: ubuntu-latest
    name: Validation
    strategy:
      fail-fast: false
      matrix:
        apps:
          - froot-loops
    defaults:
      run:
        shell: bash
        working-directory: ${{ matrix.apps }}

    steps:
      - name: Checkout
        uses: actions/checkout@v2

      - name: Use Node.js
        uses: actions/setup-node@v1
        with:
          node-version: "14"

      - name: Install packages
        run: yarn
        working-directory: ${{ env.working-directory }}

      - name: Run tests
        run: echo "Executando testes"

  Build:
    runs-on: ubuntu-latest
    needs: [Validation]
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      
      - name: Build
        run: echo "Gerando build"

  UAT:
    runs-on: ubuntu-latest
    needs: [Build]
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      
      - name: Deploy
        run: echo "Enviando para o ambiente de UAT"
  
  e2e:
    runs-on: ubuntu-latest
    needs: [Build]
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      
      - name: Tests
        run: echo "Executando testes end to end"

  Production:
    runs-on: ubuntu-latest
    needs: [e2e]
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      
      - name: Deploy
        run: echo "Enviando para o ambiente de Produção"
Current Promise version
CICD

Repositório com exemplo acima

Conclusão​

A liberação de software pode ser automática, não apenas automatizada;

Exige alinhamento entre todos as squads da empresa;

Resolver problemas de Release Engineering "em escala" torna soluções para ambientes menores mais fáceis;

Muitas empresas enfretam o mesmo dilema:

  • Como você versiona seus pacotes?
  • Com que frequência você deve liberar?
  • Você usa um modelo Push on Green?

Referências​