DEV Community: Stephann

A maravilha dos pull requests pequenos

Stephann — Tue, 09 Jan 2024 13:03:39 +0000

Uma funcionalidade nova é solicitada e é passada ao time de desenvolvimento, uma pessoa pega essa atividade e começa a trabalhar nela. Nas primeiras das famigeradas daily meetings/standup meetings são reportados os avanços esperados: “Ontem criei os modelos e hoje vou fazer a tela de listagem” ou “Ontem implementei os testes da tela de cadastro e hoje vou integrar o novo editor de texto”. Passam duas semanas, três semanas, um mês, ou até meses (sim, meses) e os relatórios diários se tornam repetitivos, algo como “Ontem eu continuei investigando o problema no editor, e hoje vou continuar nessa investigação, mas tá perto, falta só isso e aquilo, acho que próxima semana termino”. Essa próxima semana nunca chega e a gestão vive perguntando no canal de comunicação: “Como tá essa atividade? Tem algum prazo?”. Finalmente quando a atividade é finalizada, é aberto um pull request/merge request de dezenas (até centenas) de arquivos, com as modificações mais abrangentes possíveis misturando novas funcionalidades, refatorações e correções. A revisão de código se arrasta por mais alguns dias ou semanas, e em muitos casos só é aprovado porque daria um trabalho imenso apontar onde e como melhorar e também ficaria feio falar “Joga fora e faz de novo totalmente diferente”, que talvez fosse até a melhor opção.

Já presenciei as cenas narradas acima algumas vezes e acredito que a maioria de nós que trabalha com desenvolvimento de software já passou por uma situação similar em algum momento da carreira ou ainda vai passar, seja como a pessoa que desenvolve, seja como colega de time, líder dessa pessoa, gerente de projeto, scrum master e etc. Os motivos pra situações como essa acontecerem podem ser vários, pode ser que a tarefa era ambiciosa demais, que a pessoa não tinha capacidade técnica pra executá-la, que a pessoa estava assistindo vídeo fingindo que estava trabalhando, a pessoa estava passando por problemas, que o escopo não era claro e mudava muito durante a implementação, que as prioridades mudavam constantemente, a base de código estava deteriorada, enfim, há inúmeras possíveis causas.

Pra evitar passar por mais situações como essa, eu venho incentivando os times em que trabalho a encararem as atividades recebidas como projetos e quebrar ao máximo essas atividades em atividades menores. Apesar do título do artigo falar em pull requests, isso vai além, é toda uma cultura de trabalho, é um processo de entrega que envolve o time de produto e tecnologia, e que traz benefícios amplos. A adoção de pequenas tarefas tem se provada uma ótima decisão pra todos os envolvidos e explico meus pontos a seguir.

Revisão de código mais eficiente

Com pull requests com menos arquivos, e com mudanças mais focadas, as revisões ficam mais rápidas e, principalmente, ganham qualidade, pois é mais fácil entender as mudanças e sugerir novas ideias. Em um PR muito grande, a qualidade exigida durante a revisão de código cai bastante. Há um ditado que fala: A qualidade de uma revisão é inversamente proporcional ao tamanho do pull request.

Facilidade no QA/Homologação

Seguindo a mesma ideia do ponto anterior, uma mudança menor é mais fácil de ser testada e homologada, e caso algum erro apareça, mais rápido o erro será corrigido.

Facilidade no deploy/rollback

Uma mudança menor também tem menos chances de causar problema, por alterar menos arquivos, por ter passado por uma revisão mais criteriosa de código e de funcionamento, e caso aconteça algum problema, na maioria dos casos é mais fácil reverter a mudança.

Menos tempo com PR aberto

Com as revisões sendo mais rápidas, as mudanças têm menos chances de terem conflitos com as mudanças de outras atividades, e a pessoa que está executando tem menos troca de contexto. Quando uma pessoa tem vários outros PRs abertos, ela vai precisar ficar indo e voltando neles durante vários dias para corrigir comentários, conflitos, erros de homologação e etc.

Melhor planejamento

Para quebrar um projeto em atividades menores, a pessoa vai precisar raciocinar e ter pelo menos uma visão mais ampla do que será necessário fazer para entregar aquele objetivo, levando a um planejamento prévio antes de sair escrevendo código.

Melhora ritmo de entrega

A pessoa quando está executando uma atividade muito longa, ela tem maior facilidade de perder o ritmo e a produtividade, pois ela está afundada em vários arquivos que ela modificou há dias, sem saber fácil o que foi feito e o que falta fazer. Com atividades pequenas, todo dia a pessoa está iniciando e entregando uma, duas, três atividades ou até mais.

Facilita o acompanhamento do progresso

A gerência não precisa ficar mais jogando mensagem no canal de comunicação: "Como tá essa atividade?", "Conseguimos entregar essa semana?". Aliando esse melhor planejamento com um quadro de tarefas atualizado, é fácil acompanhar como está o progresso de uma entrega, pois dará para ver que, por exemplo, das 9 atividades, 6 já foram concluídas e que outras duas estão em andamento.

Facilita detectar problemas individuais

Nem todo mundo está 100% em 100% do tempo, há períodos de baixa e é necessário entender isso. Adotando as atividades pequenas, é fácil entender quando uma pessoa do time está repetidamente demorando várias semanas para entregar duas ou três atividades, enquanto o resto do time entrega 5 a 10 atividades por semana. Isso ajuda a liderança detectar situações assim e iniciar conversas para entender o que a pessoa está passando e ter uma alinhamento mais claro.

Mas como dividir melhor as atividades?

Primeiro é importante entender o que é necessário pra colocar isso em prática e eu penso que há 4 pontos:

Capacidade de planejamento

A pessoa que vai executar a tarefa, precisa saber dividir, ordenar e priorizar bem as atividades. Essa habilidade é possível aprender praticando no dia a dia e com ajuda do time que vai revisar suas entregas. A própria pessoa também vai saber quando um pull request ficou grande e tentará melhorará na próxima oportunidade. Também é possível durante a execução de uma atividade, perceber que algo ficou muito extenso, dividir o que foi feito em duas ou mais atividades e criar pull requests pra cada uma e isso servirá de aprendizado para os próximos planejamentos.

Boa estratégia de deploy

Adotando essa estratégia, muitas vezes uma atividade não estará completa a ponto de ser disponbilizada aos usuários, então é necessário escondê-la e tomar cuidado para ela não impactar as coisas que estão funcionando corretamente. Isso pode ser feito com a estratégia de feature flag, por exemplo. Também é importante termos um deploy pra produção e staging facilitado, pois aumenta o volume de entregas, e qualquer atrito nesse processo pode não dar os resultados esperados.

Contornar gargalos

Como pode acontecer de uma atividade depender da outra, por exemplo: A atividade de listagem pode depender da atividade de criação do modelo, é importante saber sinalizar e contornar essas dependências, seja tendo outras atividades na fila pra serem iniciadas, seja priorizando a entrega da atividade dependente.

Alinhamento com as pessoas de produto

O time de produto precisa estar alinhado com essa estratégia, sabendo que nem toda atividade entregará valor ao usuário final. Também aproveitar que a atividade está bem dividida pra colocar em prática a redução de escopo quando os prazos não forem possíveis de ser alcançados.

Exemplo

Agora vou mostrar um exemplo de como gosto de fazer o planejamento de uma atividade/projeto. Vamos supor que eu preciso entregar a funcionalidade de permitir que o usuário publique uma newsletter para os seus seguidores, os requisitos são:

O usuário pode listar, criar, editar e apagar posts
O usuário pode editar o corpo do post com um editor de texto avançado
O usuário pode salvar um post como rascunho
As modificações feitas no corpo devem ser salvas automaticamente
O post deve ser enviado aos seguidores do usuário por e-mail
O post deve estar visível publicamente na página do usuário

Geralmente eu vejo as pessoas fazendo isso em uma, duas, três atividades, mas eu dividiria isso em pelo menos umas 20 atividades, sem exagero. Resumindo um pouco, ficaria algo mais ou menos assim:

Criar modelo Post
Criar componente do design system para ser usado na listagem de posts
Criar tela de listagem de posts
Criar tela de cadastro de post (com um textarea simples para o corpo)
Criar tela de edição de post
Permitir apagar um post
Enviar post para os seguidores após a criação
Criar tela pública de listagem de post
Permitir que um post possa ser salvo como rascunho
Aplicar editor de texto avançado na criação/edição de post
Permitir upload de imagens no editor de texto avançado
Configurar salvamento automático no editor de texto
etc..

Perceba que com essas atividades bem divididas, eu já consigo entregar a funcionalidade pro usuário com as 8 primeiras atividades finalizadas, facilitando a diminuição do escopo de entrega e entregando valor mais rápido, permitindo validar a ideia e iterar em cima dela com as demais atividades. E voltando pros pull requests, vai ser melhor revisar a criação do modelo, com suas validações e relacionamentos, do que revisar essa mesma coisa mas junto e misturado com 4, 5 telas, controllers, testes e etc.

E uma forma que não recomendo fazer, que já vi dividirem as atividades assim e NÃO funcionou porque não conseguiu tirar os proveitos listados nesse texto:

Implementar modelos
Implementar use cases
Implementar controllers
Implementar páginas
Implementar testes

Conclusão

Adotar essa divisão de atividades em atividades bem menores é uma mudança que no começo é difícil, por ainda estar em fase de adaptação, não ter certeza se está dividindo as atividades da forma certa, se as atividades estão grandes ou pequenas demais, mas com o tempo essa prática ficará confortável e trará os benefícios esperados.

Também é necessário uma mudança de mentalidade de todos que fazem parte do processo de entrega, não adianta quebrar as atividades em atividades menores, e essas atividades demorarem uma vida pra serem revisadas, aprovadas e integradas, pois ao invés de facilitar, só criará gargalos no processo.

Mesmo que no fim, o tempo de entrega não se altere, ou até aumente um pouco, essa prática não é apenas sobre isso, tem toda uma questão de manter-se num ritmo contínuo de entrega, que em atividades longas, esse ritmo é muito mais fácil quebrar, mais difícil de detectar que quebrou e entender as causas.

E claro, isso é só um relato das minhas observações do que funcionou pra mim, mas pra você algo não pode funcionar, então é bom ficar atento pra fazer os ajustes necessários pra se adaptar ao seu contexto.

Seus testes não deveriam ser DRY, mas sim WET

Stephann — Tue, 26 Sep 2023 16:59:09 +0000

Bom, primeiro é bom deixar claro que o que vou escrever aqui não é nada novo, mas como comecei a aplicar esses conceitos nos últimos 2 anos nos projetos em que trabalhei e vi que tem sido realmente bem mais vantajoso do que a forma que eu fazia até então, resolvi escrever sobre. Se quiser ler/assistir outras pessoas falando sobre o assunto, seguem os links:

DRY x WET

DRY e WET são mais uns desses acrônimos que adoram colocar em princípios de desenvolvimento. DRY corresponde a Don't Repeat Yourself, traduzindo seria: Não se repita, que prega que você deve evitar ficar replicando um mesmo código em vários lugares da sua aplicação. Já o WET é o inverso disso, descreve códigos repetidos e pode ser traduzido como "Nós amamos digitar" (We Enjoy Typing) ou "Escreva tudo duas vezes/três vezes" (Write Everything Twice/Thrice).

O consenso é que DRY é bom, e WET é ruím. Isso prega na sua cabeça principalmente quando você está saindo do nível júnior e indo para o nível pleno. Não é incomum encontrar aqueles conteúdos "Entenda o conceito do SOLID e deixe de ser Jr. e suba de nível", e fala superficialmente que não repetir código é uma das habilidades necessárias para ser uma boa pessoa desenvolvedora.

Gosto de pensar que Júnior é o nível onde a pessoa aprende a desenvolver e consegue aplicar esses conhecimentos em aplicações reais, já o Pleno é o nível onde você entende e aplica de forma errada todos os princípios e boas práticas que colocam na sua frente, e você começa a se tornar senior quando vai aprendendo em quais contextos esses princípios são benéficos ou fazem mais mal do que bem.

O RSpec

Como o consenso é que DRY é bom, acabamos aplicando essa prática em todo o código, inclusive nos nossos testes, e o RSpec, uma das principais ferramentas de testes utilizadas pela comunidade Ruby, ajuda a perpetuar essa prática. Ele fornece vários mecanismos para secar seu código, evitando duplicações, alguns desses mecanismos são os #let, #subject, #before, #around, #after e os shared examples. Um exemplo de código:


describe Foo do
  describe "#bar" do
    subject(:foo) { Foo.new(x, y, z)

    let(:x) { 10 }
    let(:y) { 20 }
    let(:z) { x * y }
    let(:calc_result) { true }

    before do
      allow(Calculator).to receive(:calc)
        .with(z)
        .and_return(calc_result)
    end

    context "when x is greater than y" do
      let(:x) { 20 }
      let(:y) { 10 }

      it "returns something nice" do
        expect(foo.bar).to eq ...
      end
    end

    context "when y is greater than x" do
      it "returns something great" do
        expect(foo.bar).to eq ...
      end
    end

    context "when calc result returns false" do
      let(:calc_result) { false }

      it "..." do
        expect(foo.bar).to eq ...
      end
    end

    context "when calculator raises error" do
      before do
        allow(Calculator).to receive(:calc)
          .with(z)
          .and_raise("Some error")
      end

      it "..." { ... }
    end
  end
end

Esse código está seguindo as boas práticas do DRY, e provavelmente se você não se incomodou com ele é porque você já deve estar acostumado a escrever código assim e ou acha que esse é a única forma de escrever testes com o RSpec.

Eu acredito que é um código problemático a longo prazo, pois você olha para um exemplo de teste (o it) e não consegue ver claramente como aquele teste está configurado, pois tem dependências no subject, nas variáveis let, nos before, e tudo isso pode ter sido ou não sobrescrito num escopo de context ou describe.

Então basicamente você precisa mapear mentalmente todo o arquivo de teste para entender como um teste está funcionando. Além disso, se você precisar modificar/adicionar um cenário, você sempre estará numa batalha entre adaptar as declarações existentes e quebrar os demais testes sem relação com sua atividade, e/ou acabar tendo que criar mais let/subject/before. Então o DRY nessa situação me parece uma furada.

Mas apesar de tudo, não é o RSpec o vilão, podemos aproveitar de vários benefícios da ferramenta mas sem utilizar as que consideramos problemáticas. Se a gente não quiser seguir o DRY, e deixar nosso código molhadinho, ele poderia ficar assim:

describe Foo do
  describe "#bar" do
    context "when x is greater than y" do
      it "returns something nice" do
        foo = Foo.new(20, 10, 200)

        expect(foo.bar).to eq ...
      end
    end

    context "when y is greater than x" do
      it "returns something great" do
        foo = Foo.new(10, 20, 200)

        expect(foo.bar).to eq ...
      end
    end

    context "when calc result returns false" do
      it "..." do
        foo = Foo.new(10, 20, 200)

        allow(Calculator).to receive(:calc)
          .with(200)
          .and_return(false)

        expect(foo.bar).to eq ...
      end
    end

    context "when calculator raises error" do
      it "..." do
        foo = Foo.new(10, 20, 200)

        allow(Calculator).to receive(:calc)
          .with(200)
          .and_raise("Some error")

        expect(foo.bar).to eq ...
      end
    end
  end
end

O que eu fiz: Removi os before, os let e o subject, e deixei tudo que um teste precisa dentro dele próprio, ou seja, ele está contido e não tem nada externo que está influenciando na sua execução. Isso facilita a criação de novos testes e a adaptação de testes existentes, você olha para um exemplo e entende o que está acontecendo, sem surpresas.

Esse código até ficou com menos linhas do que o exemplo anterior, mas não é sobre isso que se trata essa prática, o normal ao aplicar essa prática é ter testes com mais linhas, e isso não pode ser encarado com algo negativo, eu penso que é melhor ter algo mais fácil de ler, entender e modificar mesmo que seja mais extenso do que ter um arquivo compacto que torna a vida do time de desenvolvimento mais difícil.

Enxugando um pouquinho

Claro, nem toda prática deve ser seguida cegamente, em 100% de todas as situações. Haverá situações onde reaproveitar código será a melhor saída do que replicar em todos os testes. A diferença é que você poderá fazer isso de forma discreta, apenas quando necessitar, não será sua atitude padrão para cada um dos testes. Por exemplo, em um teste de sistema você precisa reaproveitar uma série de passos que está se repetindo muito no arquivo, você pode criar um método Ruby comum ao invés de utilizar o before:

describe "Create product" do
  context "with valid form" do
    it "creates product" do
      store = create(:store)

      visit_new_product_page(store)

      fill_in "Title", "My product"
      ...
    end
  end

  context "with invalid form" do
    it "displays errors" do
      store = create(:store)

      visit_new_product_page(store)

      fill_in "Title", ""
      ...
    end
  end

  def visit_new_product_page(store)
    user = create(:user)
    user.add_role(:admin, store)

    sign_in user

    visit store_products_path(store)

    click_on "New product"
  end
end

Você mais ranzinza pode estar pensando "é basicamente a mesma coisa de usar um before", mas é diferente, aqui você definiu um método auxiliar, ele só é executado se você precisar, no momento que você precisar, com os dados que você quer que ele receba, podendo retornar ou não os dados que você precisa, e se precisar de algo diferente você consegue criar um novo método com um novo comportamento.

Uma outra situação que acho tranquilo enxugar código: Você precisa de um mesmo objeto em testes simples e contidos:

describe Product do
  describe "validations" do
    subject(:product) { build(:product) }

    it { is_expected.to validate_presence_of(:title) } 
    it { is_expected.to validate_presence_of(:price) } 
    it { is_expected.to validate_uniqueness_of(:title) } 
    ... 
  end
end

Ou seja, você vai sentir quando aplicar o DRY será vantajoso e quando repetir código estiver prejudicando a leitura daqueles testes. Então não é como se fosse proibido utilizar certas coisas, é como se agora você precisasse realmente de um motivo forte, e não só fazer porque foi assim que você aprendeu.

Conclusão

O código de teste deve ser considerado código da aplicação, mas é um código com um propósito diferente, e nem sempre as práticas utilizadas no código da regra de negócio podem ser vantajosas ao serem aplicadas nos testes.

Se você estiver fazendo uma nova aplicação, ou tem liberdade pra aplicar essa técnica numa aplicação existente, faça uma experiência e passe um tempo escrevendo testes WET. No início vai parecer que tem algo errado por conta da duplicação de código, mas depois você vai sentir a produtividade ao ter que adicionar e modificar testes existentes, sem precisar brigar com o RSpec e suas variáveis bagunçadas.

Seu trabalho é sobre código sim

Stephann — Mon, 25 Sep 2023 14:41:52 +0000

Introdução

O trabalho do desenvolvedor não é sobre código, é sobre entregar valor/resolver o problema do cliente.

Essa é uma daquelas frases que qualquer pessoa pode soltar num meio de uma reunião e essa pessoa parecerá inteligente, pois é uma frase que dificilmente pode ser contradita, mas não diz muita coisa.

Algumas vezes as pessoas querem passar a ideia de "seu código não importa, mas sim se a dor do usuário foi solucionada ou não", e outras vezes quem ouve/lê é quem entende a frase dessa forma. Mas como a maioria dessas afirmações pra ganhar engajamento, essa é uma afirmação superficial e não entra no principal (ou seja, não gera valor hehe), que é "o que é entregar valor?".

O que é entregar valor?

Até entendo as pessoas ficarem só na superfície dessa frase feita, porque entregar valor é algo que varia bastante em cada contexto. A resposta pode mudar se levar em consideração pra quem você está gerando valor, o momento da empresa e os seus objetivos, a sua função e etc.

Por exemplo, em uma startup em estágio embrionário, gerar valor seria colocar um produto rápido no mercado e que solucione os problemas do público alvo. Já numa empresa em crescimento rápido, talvez gerar valor seja tornar o produto escalável, ou diminuir custos.

Esses são exemplos clichês e fáceis de dizer que geraram valor porque são métricas facilmente mensuráveis, entregar em 3 meses, aguentar 5000 usuários simultâneos, custos de infraestrutura diminuir em 20.000 reais. Mas tem muita coisa que gera valor e que não é fácil medir o valor gerado, que não temos como afirmar se o impacto causado aconteceu por alguma atitude tomada e consequentemente é mais difícil de vender a ideia para quem toma decisões. Pra exemplificar, vou citar 2 atividades: Escrever código de qualidade e melhorar a developer experience do projeto.

Gerando valor invisível

Escrever código de qualidade já é algo difícil de afirmar se está sendo feito ou não, constatar se isso gerou valor é mais difícil ainda. Pro cliente final não parece ter uma relação entre a maior qualidade do código e maior satisfação com o produto, mas pode ser que tenha, posso afirmar que um código com mais qualidade significa um produto com menos bugs pois é mais fácil de manter, e um produto com novas funcionalidades mais cedo pois o código é fácil de modificar e evoluir.

Melhorar a developer experience também não parece afetar diretamente o cliente final, mas ajuda os desenvolvedores a começar a trabalhar no projeto mais cedo, a solução de problemas é mais rápida por conta de melhores ferramentas pra investigação, menos tempo perdido com reuniões e dúvidas, mais segurança na entrega, mais qualidade de vida, e tudo isso pode afetar também o número de bugs e novas funcionalidades presentes no produto.

Há vários outros hábitos que parecem ser apenas firula ou perda de tempo, mas que ajudam de alguma forma no processo de desenvolvimento e entrega de um valor visível, da mesma forma como decisões equivocadas e ausências de certos hábitos interferem na entrega de valor mas que também não é fácil mostrar que foram a causa dessa improdutividade.

Você é responsável pelo código

É por isso que a afirmação no começo do artigo é superficial. Seu trabalho como desenvolvedor, em muito dos casos, não é saber se o que você está fazendo gera valor diretamente ou não pro cliente, pra isso há diferentes times pra realizar entrevistas com clientes, pra gerenciar projeto, pra analisar métricas, pra definir estratégia, e etc. Se você estiver se preocupando com tudo isso, quem está se preocupando com o código? Ninguém, e é assim sua base de código fica deteriorada, e o trabalho do time de desenvolvimento era não deixar isso acontecer.

Dá pra fazer uma analogia com a engenharia civil, já que uma pessoa dev pode ser considerada uma pedreira do mundo digital =p. O valor que um pedreiro entrega é uma estrutura boa, resistente, durável, alinhada com as definições do projeto. Outros times que irão definir ou já definiram cores, lugar dos móveis, repartição dos cômodos, iluminação, revestimentos, gerenciamento do projeto. Então como desenvolvedor você deve estar comprometido com o código, outros times estarão comprometidos com prazo, outros com o cliente e etc.

Seja um pouco flexível

Mas claro, estar comprometido com o código não é ignorar todo o contexto, você e o time de desenvolvimento não trabalham sozinhos numa ilha, há todo um esforço coletivo na construção de um produto. Então deve haver uma flexibilidade, às vezes é necessário abrir mão de certos processos que seriam "os mais corretos" em prol de um benefício maior.

Uma situação clássica onde isso deveria acontecer: Há um bug em produção que está gerando prejuízo para a empresa ou para o cliente, o ideal é que isso seja resolvido o mais rápido possível. O processo "correto" seria corrigir o problema, abrir pull request, solicitar revisão, aguardar CI passar, realizar testes de QA e daí realizar deploy. Mas talvez para um ganho de todos, esse fluxo pode ser ignorado e a correção ir direto para produção. Não é o correto em condições normais, mas condições anormais acontecem, você pode minimizar isso registrando uma atividade pra revisar, refatorar e testar o que foi feito. Tenha sempre processos para voltar aos trilhos.

Agora se isso se torna algo cotidiano, você estiver sempre tendo que comprometer a qualidade do seu trabalho para apagar incêndios, isso pode ser sintoma de uma falta de organização da empresa, falta de maturidade nos processos, e daí você pode tentar corrigir mas se for algo cultural, é melhor partir pra outra ou dançar conforme a música.

Conclusão

Resumindo, diferente da frase que motivou esse artigo, o seu trabalho como desenvolvedor/a é sobre código sim, você focando na qualidade do seu trabalho, numa empresa organizada, você estará contribuindo para um melhor produto e consequentemente gerando mais valor. Quando as pessoas responsáveis pelo código não ligam para ele ou não tomam as melhores decisões, o produto está condenado a uma estagnação e a uma constante correria pra apagar incêndio.

Entendendo webhooks

Stephann — Fri, 23 Jun 2023 12:35:45 +0000

Introdução

Se você já assistiu Shrek, deve lembrar da cena onde o Burro fica perguntando de tempos em tempos "A gente já chegou?", e isso é basicamente a mesma estratégia muitas plataformas utilizam para se comunicar com outras plataformas, elas ficam "tem informação nova aí pra mim?" de forma recorrente até encontrar o que procura, isso é chamado de polling. Isso pode trazer algumas consequências como:

Necessidade implementar e observar o funcionamento de uma rotina para buscar dados de tempos em tempos, definindo um intervalo entre suas execuções.
Esse intervalo pode não ser o ideal, fazendo consultas em um intervalo menor ou maior que o necessário.
Essas rotinas podem sobrecarregar a plataforma que pergunta e/ou a plataforma que responde, dependendo do volume de dados que precisam ser conferidos e da frequência das perguntas.

Isso pode ser evitado com Webhooks.

O problema

Pra contextualizar, vamos imaginar o seguinte cenário: Você está desenvolvendo um e-commerce, e precisa processar o pagamento de um usuário. Você utilizará uma plataforma provedora de pagamento (Stripe, Pagar.me, Iugu e etc.). A forma de pagamento escolhida foi Pix, então quando você consome o serviço da provedora de pagamento, ela te devolve um QR Code e você exibe esse QR Code pro usuário conseguir pagar. Nesse momento você não tem como saber se o usuário pagou, se ele vai pagar em 10 minutos, em 1 hora, em 5 horas ou se vai deixar o Pix expirar, mas você precisa saber o que vai acontecer com esse Pix para poder atualizar o status do pedido na sua plataforma.

Uma possível solução para esse problema acima: Criar uma rotina pra consumir a API da provedora de pagamento e verificar se o status do pagamento saiu de "Aguardando Pagamento" para "Pago" ou "Vencido". Daí é necessário decidir o intervalo dessa rotina. Se for de hora em hora, você pode criar um problema, pois o pix é instantâneo e o usuário vai ficar preocupado porque a plataforma não mudou o status do pedido dele mesmo depois de 30, 40 minutos após o pagamento.

Então você muda pra rotina executar a cada minuto, e percebe isso está sobrecarregando sua plataforma e a provedora de pagamento, pois agora você tem 1000 pagamentos pra conferir. Depois você descobre que uma transação de cartão de crédito pode ser estornada até 6 meses depois da data do pagamento e que sua plataforma precisará passar 6 meses conferindo se o status da transação mudou.

Assim como na cena do Shrek, o ideal para ambas as partes nessa situação seria seu e-commerce parar de perguntar com tanta frequência, ao mesmo tempo que a provedora de pagamento te garantisse que te avisará quando houver alterações nos dados. Uma forma de fazer esse "acordo" entre plataformas é utilizando Webhooks

Os webhooks

Webhooks basicamente invertem o conceito de API, podemos pensar como uma API inversa, ao invés do e-commerce consumir um serviço da provedora de pagamento, a provedora de pagamento é que vai consumir o serviço do e-commerce enviando os novos dados.

Na prática funciona assim: você implementa uma rota para receber as requisições relacionadas à mudança de status dos pagamentos, ex.: minhaloja.com.br/webhooks, e informa essa URL nas configurações da provedora de pagamento. Com isso configurado, toda vez que um pagamento mudar de status, a provedora de pagamentos irá enviar para a sua aplicação os dados atualizados dos pagamentos sem você precisar pedir de tempos em tempos. Um exemplo de dados que a provedora poderia enviar:

{
  id: "405", // id do webhook
  event: "status_changed", // tipo do evento
  transaction_id: "125095", // id do pagamento
  old_status: "pending", // status antigo
  status: "paid", // status atual
  ...
}

Mas e a segurança?

Agora você deverá estar se perguntando: "Mas se alguém descobrir essa rota e enviar requisições se passando pela provedora de pagamento?". É uma dúvida bem pertinente, de fato você precisa proteger essa URL para que sua aplicação não processe dados de desconhecidos. Uma prática comum no uso de webhooks pra garantir que a requisição é confiável, é implementar a troca de códigos onde apenas duas plataformas saibam como gerar esses códigos.

Um exemplo dessa estratégia seria utilizar um algoritmo de chave simétrica: A provedora de pagamento envia no corpo ou no cabeçalho da requisição o código, por exemplo: 1213e67a3b34c2848f8317d29bcb8cbc9e0979b8, e pra você garantir que foi a provedora de pagamento mesmo que enviou essa requisição, você precisa criptografar o corpo do webhook com algum algoritmo específico utilizando sua chave da API, caso o resultado da criptografia seja igual ao do código enviado na requisição significa que a requisição é confiável e pode ser processada.

E se minha aplicação sair do ar?

Outra dúvida que pode ter surgido na sua cabeça: "E se minha aplicação ficar fora do ar no momento que a provedora de pagamento estiver enviando webhooks?". Também há soluções pra isso e a mais comum são as retentativas. Caso a aplicação A falhe em receber os webhooks da aplicação B, a aplicação B tentará enviar o webhook outras vezes. Normalmente o que se considera "enviado/recebido com sucesso" é a plataforma devolver um status HTTP de sucesso (status 200, por exemplo) ao receber o webhook.

O que varia de plataforma para plataforma são as políticas de retentativas. Tem plataforma que vai tentar 3 vezes no máximo (o que considero pouco e não muito confiável), outras vão tentar 30 vezes (🥰 pra mim é o ideal). E também algumas plataformas mudam o intervalo entre retentativas, por exemplo: As 5 primeiras tentativas têm intervalo entre elas de 1 minuto, as 20 próximas tentativas serão de hora em hora, as 5 últimas serão 1 vez ao dia. Isso ajuda a nenhum webhook ficar perdido num eventual problema de comunicação, porque não adiantaria a plataforma fazer 30 retentativas num mesmo minuto, e calhar da sua aplicação ficar fora do ar justamente nesse minuto específico.

Algumas plataformas também disponibilizam uma API para você consultar os webhooks e dispará-los novamente. Eu encaro essa opção como uma última saída, caso você desconfie de ter perdido o recebimento de algum webhook.

Tratando os webhooks

Uma estratégia que venho testando e parece funcionar bem é: Não processar o webhook no momento do seu recebimento. Ou seja, no exemplo do e-commerce, não vá mudar o status do pedido durante o processamento da requisição do webhook, pois pode haver um erro na sua lógica e sua plataforma devolver um status de erro na requisição (status 500, por exemplo). Isso fará a provedora de pagamento enviar várias vezes o webhook desnecessariamente, talvez até causando alguma inconsistência nos seus dados dependendo de como foi implementado.

A ideia é armazenar esse webhook numa estrutura (numa tabela, por exemplo) e processá-lo posteriormente de forma assíncrona (como um job no Sidekiq). Dessa forma você retorna de forma rápida um status 200 pra plataforma parceira pois você não precisou processar naquele momento, e você tem os dados necessários pra posteriormente processar esse webhook. Caso dê algum problema no processamento, você consegue reprocessar, investigar, debugar aquele webhook com mais calma.

Qualidade de vida

Outro ponto que considero que ajudo bastante a utilização dos webhooks, principalmente durante a fase de desenvolvimento e manutenção, é que a URL que vai receber os webhooks e que você informa para a plataforma, possam ser configuradas de maneira automatizada e de forma individualizada.

Configuração de maneira automatizada significa que você não precisa ir manualmente nas configurações da plataforma pra alterar a URL de recebimento de webhook, isso pode ser feito via código, configuração do projeto, parâmetro na requisição e etc. Isso ajuda nos casos de ter muitas pessoas trabalhando na integração e não precisar ficar alterando manualmente a URL para uma URL de ambiente dev.

Já a configuração de forma individualizada permite que você defina uma URL pra diferentes recursos que você estiver lidando. No exemplo da provedora de pagamento, essa funcionalidade me permitiria, no momento que eu criar uma transação, enviar algo como "webhook_url": "someurl.com", e os webhooks relacionados àquela transação seriam enviados pra essa URL específica. Isso ajuda tanto no ponto anterior de configuração automatizada, quanto em casos de migração e refatoração, onde pros pagamentos novos você consegue apontar os webhooks pra uma nova rota ou nova plataforma sem interferir nos webhooks dos pagamentos antigos.

Conclusão

Os webhooks são um ótimo recurso para dar mais possibilidades de integração entre plataformas, otimizando o poder computacional e garantindo uma melhor consistência e agilidade na atualização dos dados, e em determinados tipos de plataforma são essênciais.

Se você estiver desenvolvendo uma plataforma que seja necessário utilizar webhooks ou planejando se integrar com alguma que forneça esse recurso, eu recomendo conferir todos os pontos que mencionei no artigo para garantir uma melhor developer experience (pro seu time ou pra quem vai se integrar com seu produto). Os pontos que considero principais são:

Política de segurança. Prover uma forma pra garantir que as requisições são de quem deveriam ser.
Política de retentativas. Idealmente com um número alto de retentativas intervaladas de forma progressiva.
Disponbilização de API para listagem e disparo de webhooks, principalmente se puder filtrar por status (ex.: listar webhooks pendentes) ou por recurso (ex.: listar os webhooks relacionados a pagamento XYZ).

Com esses pontos garantidos, todo mundo sai ganhando, ALEGRIA!!!

Os benefícios de componentizar as views do Rails

Stephann — Mon, 27 Feb 2023 11:35:44 +0000

Introdução

Uma coisa que contribui bastante para um código bagunçado e confuso no Ruby on Rails, principalmente em aplicações que crescem e passam pelas mãos de diversas pessoas, é a forma como o Rails lida com o seu front-end, suas views, helpers e partials, e todo o processo de escrever código para gerar o HTML. E nesse artigo eu proponho uma solução para esse problema utilizando as views como objetos.

Qual o problema com o front-end do Rails?

Antes de tudo, quero iniciar deixando claro que eu adoro escrever aplicações full stack com o Ruby on Rails. É muito mais fácil resolver certos problemas utilizando o Rails completo do que criar uma aplicação Rails API e construir um SPA (Single Page Application) com um framework javascript. Coisas como autenticação, autorização, SEO, deploy, e outras coisas que devo ter esquecido de mencionar, são horríveis de implementar em aplicações SPA. Mas por alguns motivos, houve um movimento da comunidade na direção de utilizar o Rails apenas para construir as APIs REST mesmo quando isso não era um requisito do produto, e talvez um dos motivos que auxiliou esse movimento tenha sido a facilidade de fazer bagunça na construção do HTML com o Ruby on Rails.

Pra exemplificar, vou utilizar esse código simples pra expor alguns problemas, é um código em uma partial app/views/layouts/_menu.html.erb:

<%= badge(color: :red, text: @notifications.count) %>

Se alguém quisesse saber de onde veio esse método bagde, a pessoa teria que buscar nos app/helpers/**/*.rb, que inclusive poderia estar definido mais de uma vez em múltiplos helpers sem ninguém notar, ou poderia até estar definido em um controller, com o método helper. Aqui fica evidente um problema, que os helpers são globais por padrão, então qualquer método definido na pasta helpers estará disponível para ser utilizado em qualquer lugar da view. Pra resolver isso, há a configuração config.action_controller.include_all_helpers = false, que vai adicionar apenas no controller apenas o helper correspondente ao recurso, mas, apesar de ajudar a resolver o problema mencionado, não resolve a tendência dos helpers ficarem inchados com o passar do tempo para comportar os métodos das views e partials daquele recurso.

Outro problema com o código: De onde esse @notifications veio? Você procura no controller da tela em questão, por exemplo ArticlesController, olha nas ações, nos métodos privados, nos callbacks *_action, e não encontra, depois procura no ApplicationController, também não encontra, mas descobre que foi incluído o concern app/controllers/concern/notifications_concern.rb que tinha o seguinte código:

module NotificationsConcern
  included do
    after_action do
      @notifications = Notification.where(
        user: current_user,
        read: false
      )
    end
  end
end

Isso expõe o problema, há muitos vetores de entrada de dados nas views. Um callback que instancia uma variável, foi definido num concern, que foi incluído no ApplicationController, e que uma partial renderizada na view terá acesso direto a essa variável, sem nenhum contrato explícito. Fica mentalmente confuso de entender o código, debuggar, saber do que uma tela precisa pra ser construída, entender o fluxo de dados. Uma solução pra isso seria: Fazer um acordo com o time para que esse tipo de coisa não seja feita, mas não seria tão fácil garantir que a aplicação nunca tenha um código assim.

E não vou nem me aprofundar na dificuldade de testar código relacionado ao front-end. Mas há como amenizar todos esses problemas mencionados relacionados às views, partials e helpers. Eu penso que tratar as páginas como objetos é um grande começo.

Tratando as páginas como objetos

Até um tempo atrás, as partials do Rails eram a única forma de componentizar pedaços da sua tela, os helpers também ajudavam nesse ponto, mas como mencionei na seção anterior, esses recursos têm um potencial de conter código insustentável. Recentemente as bibliotecas de componentização têm ganhado seu espaço na comunidade, com a ViewComponent sendo a principal biblioteca utilizada para isso, mas há várias alternativas, uma delas é o Phlex, que já testei e recomendo.

Mas enquanto a maioria dessas bibliotecas focam em componentes (pedaços da tela) e na reutilização desses componentes como um dos grandes benefícios, não há um incentivo ao uso da mesma estratégia para a criação de páginas. Inclusive ao expor que estou utilizando componentes para a criação de páginas, recebi alguns comentários assim: "Utilizar componentes para páginas seria a última coisa que eu faria, pois páginas não são reutilizáveis e não faria sentido componentizá-las", sim isso foi um comentário real no Twitter, não são vozes da minha cabeça, eu juro. Mas será que comentários assim fazem sentido? Talvez, pode ser que sim, realmente as páginas não precisam ser reutilizáveis, mas aplicar a "componetização" nelas traz todos os demais benefícios dessa estratégia, e pra reforçar isso, podemos ler a seguir, de forma resumida, o que o site do ViewComponent lista como vantagens na sua utilização:

Por que utilizar o ViewComponent?

Responsabilidade única: As lógicas relacionadas às views geralmente estão espalhadas entre modelos, controllers e helpers, diluindo suas reponsabilidades. Com o ViewComponent essa lógica fica encapsulada em suas próprias classes, facilitando o entendimento.

Testes: Os componentes são testados individualmente. Dessa forma os testes de integração servem pra testar a aplicação de ponta a ponta, enquanto as variações do conteúdo renderizado são testadas com testes unitários.

Fluxos de dados: Os templates do rails (views/partials) têm uma interface implítica, tornando difícil de enxergar as dependências. Com ViewComponent, os componentes tem um construtor que identifica fácilmente o que é necessário para a sua renderização.

Qualidade de código: Geralmente os templates (views/partials) falham nos padrões de qualidade básico, pois têm métodos longos e condicionais aninhadas em múltiplos níveis. ViewComponents são objetos Ruby, facilitando e garantindo a escrita de código com qualidade.

Pode parecer uma grande loucura o que vou escrever agora, mas eu quero essas vantagens pra minhas páginas também. A seguir explico como estou fazendo isso com o ViewComponent nas aplicações que escrevo:

Utilizando o ViewComponent para criar páginas

Como falei anteriormente, as bibliotecas de componentização não focam muito na criação de páginas, mas nada impede que você utilize um componente como uma página. Quando utilizo a ViewComponent eu prefiro criar uma pasta dedicada para as páginas, e deixar a pasta padrão app/components que a gem sugere para os componentes em si. Minha abordagem é a seguinte:

Crio a pasta app/pages
Modularizo as classes pelo seu recurso, ou seja, se é uma página de listagem de contatos, ela ficará dentro do módulo Contacts
Adiciono o sufixo Page às classes pra ficar claro o que aquela classe representa

Então uma listagem de contatos ficaria mais ou menos assim:

# app/pages/contacts/index_page.rb

module Contacts
  class IndexPage < ViewComponent::Base
    attr_reader :contacts

    def initialize(contacts:)
      @contacts = contacts
    end

    private

    def emergency_badge(contact)
      if contact.emergency?
        render BagdeComponent.new(color: :red) do
          "Emergency"
        end
      end
    end
  end
end

<%# app/pages/contacts/index_page.html.erb %>

<h1>Contacts</h1>
<% contacts.each do |contact| %>
  ...
  <%= emergency_badge(contact)
<% end %>

# app/controllers/contacts_controllers.rb

class ContactsController < ApplicationController
  def index
    contacts = Contacts.all

    render Contacts::IndexPage.new(contacts: contacts)
  end
end

# spec/pages/contacts/index_page_spec.rb

RSpec.describe Contacts::IndexPage do
  ...

  context "when some contact is an emergency contact" do
    it "renders emergency bagde" do
      contact = Contact.new(
        name: "John", 
        email: "x@y.z", 
        emergency: true
      )

      render_inline(described_class.new(contacts: [contact]))

      expect(page).to have_css(
        "span.bg-red-200", text: "Emergency"
      )
    end
  end
end

Com esse código podemos ver os problemas mencionados nas seções anteriores sendo resolvidos:

Fluxo de dados: No controller, fica claro o que é necessário para renderizar a página, nenhuma variável de instância, ex.: @something, irá "vazar" e ser acessada pelo objeto da página.
Qualidade de código: A lógica de renderização é extraída para a classe da página, tornando o template mais simples de ler e manter em comparação com os if, elses e um monte de código ruby dentro dos .html.erb.
Responsabilidade única e a bagunça dos helpers é evitada: A lógica de renderizar a badge de contato de emergência está bem próxima de onde está sendo utilizada, ou seja, no próprio objeto da página, e não perdida em algum helper, método no controller, modelo e etc.
Testes: Conseguimos testar as variações da página com testes unitários, deixando os testes de integração mais simples e focados no que devem fazer.

Claro, você ainda precisará fazer algumas coisinhas pra melhorar a developer experience, como criar um ApplicationPage pra compartilhar comportamentos gerais, criar um gerador rails g page contacts/show pra facilitar a criação de páginas, ajustar a questão das traduções, já que o t(".my_key") não vai funcionar tão bem por padrão, quando quiser um comportamento compartilhado entre algumas poucas telas/componentes vai ter que extrair pra um módulo e incluir nas respectivas classes, mas nada de outro mundo que não valha a pena a adoção dessa estratégia.

Conclusão

Tenho utilizado essa estratégia nas últimas aplicações que trabalhei e tem funcionado bem, também ando testando a gem Phlex com outras formas de organização e também tem funcionado, e no momento não tenho sentido falta de nada do jeito padrão do Rails trabalhar com seus templates, pelo contrário, tem ajudado a manter uma organização e padronização que eu não tinha anteriormente.

Inclusive acredito que isso deveria ser uma evolução no Rails, já vir com uma solução dessa disponível embutida no próprio framework, com documentação, com scaffold sendo gerado assim, pois pode até parecer mais verboso no princípio, mas é uma troca que acho que vale muito a pena. As mágicas do Rails são incríveis quando você está vindo de um outro framework e te encantam, mas conforme você enxerga os problemas que algumas mágicas trazem, você passa a querer as coisas da forma mais explícita o possível, mas a gente só aprende isso depois de sofrer um pouco.

Mas o que eu trouxe aqui não é uma ideia nova, inclusive inspirado no Hanami e no Lucky foi que resolvi fazer algo parecido no Rails. O Hanami tem suas views como objetos e o Lucky (esse é um framework web utilizando a linguagem Crystal) também adota a mesma estratégia, e alguns frameworks javascript, como é o caso do Nuxt têm coisas parecidas. Quem sabe numa versão 8.0 o Rails também entra nesse time.

Falha de cobertura: Divagações sobre testes de software

Stephann — Sun, 11 Dec 2022 23:00:25 +0000

Introdução

Uma métrica que recebe bastante atenção no mundo do desenvolvimento é a porcentagem de cobertura dos testes, e quem está entrando na área de desenvolvimento e testes costuma não entender bem o que ela representa. "Nossa base de código está com 100% de cobertura de testes", "Não aceitamos pull requests que diminuam a taxa de código coberto" são frases ditas com orgulho quando alguém vai falar da cultura do seu time de desenvolvimento. E devem ser valorizadas mesmo, pois ter o código 100% coberto com testes é um grande feito na missão de ter uma base de código saudável, que faz o que foi especificado para ser feito e que dá confiança para ser modificado pelas pessoas que mexem nele. O que pretendo trazer nesse texto são algumas situações onde mostro que olhar apenas a porcentagem de cobertura de software não é uma boa ideia, ao mesmo tempo que tento jogar uma luz em como o código deve ser visualizado, entendido, pros comportamentos poderem ser entendidos plenamente, auxiliando na implementação dos testes. Na minha experiência ao ajudar pessoas júniors, uma das maiores dificuldades que elas têm é conseguir saber o que deve ser testado e como deve ser testado, e é o que vou tentar simplificar a seguir.

A armadilha dos 100%

A armadilha de ter 100% de cobertura é utilizar essa métrica como referência pra se confiar que o código está bem testado. Um código pode estar com os 100% de cobertura e não estar testado apropriadamente. Explico logo a seguir, mas antes quero deixar o aviso que tudo que vou falar aqui é na minha experiência de testes com Ruby (RSpec/Minitest/Sus) e o Simplecov (ferramenta para analisar a cobertura dos testes), e vou utilizá-los para exemplificar o que quero demonstrar, mas acredito que os mesmos conceitos se encaixam facilmente pra maioria das outras linguagens e ferramentas de testes, então vale a pena continuar lendo.

Vamos supor que uma aplicação tem o seguinte código:

class Products::Create
  def call(attributes)
    product = Product.new(attributes)

    product.save!

    Products::NotifyUsersJob.perform_later(product)
  end
end

A classe acima é uma operação de criação de produto com um método #call, que recebe os atributos do produto, salva esse produto e depois envia notificação para os usuários sobre o lançamento daquele produto.

Um possível teste para essa operação seria:

RSpec.describe Products::Create do
  it "creates new product" do
    operation = Products::Create.new

    expect do
      operation.call({ title: "My product", price: 50.00 })
    end.to change(Product, :count).by(1)
  end
end

A estratégia do teste está sendo: Instanciar a operação, depois executá-la passando parâmetros válidos e verificar se a contagem de produtos aumentou em 1. O teste deverá passar com tranquilidade, mas pra nossa surpresa, a cobertura de teste ficará 100%.

Isso deveria ser uma surpresa pra quem não conhece o funcionamento de ferramentas como o Simplecov, pois o código utilizado como exemplo tem 2 funcionalidades: a criação de produto e envio de notificação aos usuários, mas o arquivo de testes está testando apenas o trecho da criação de produto, então na teoria não era pro código estar com 100% de cobertura, mas na prática foi isso que aconteceu. Pra entender melhor esse comportamento precisamos entender o funcionamento do Simplecov.

Como o Simplecov funciona?

O Simplecov (https://github.com/simplecov-ruby/simplecov) é uma gem que analisa a cobertura de código dos testes. Ao final da execução da bateria de testes da aplicação, o Simplecov fornece um relatório informando a porcentagem de linhas cobertas e uma visualização das linhas cobertas e não cobertas dos arquivos. Algo assim:

Na imagem acima, as linhas verdes são as linhas cobertas com testes, e a linha vermelha indica que não está coberta. Mas entender o que o Simplecov (e essas ferramentas de análise de cobertura) considera "coberto" e "não coberto" é a chave pra entender porque ele considerou aquele código anterior 100% coberto.

Pro Simplecov, uma linha de código está coberta quando um teste "passa" por ali, e não está coberta quando um teste "não passa" por ali. O "passar" entenda como executar o código em questão. Pra entender melhor vamos olhar para o código a seguir, é uma função de divisão que recebe 2 argumentos, a é o dividendo e b é o divisor, e que retorna o quociente. Mas caso o divisor seja 0, é lançado um erro. Também já tem logo na sequência o arquivo de teste, que está testando apenas a situação quando o divisor é diferente de zero:

class Calculator
  def divide(a, b)
    if b != 0
      a / b
    else
      raise "Division by zero error"
    end
  end
end

# Arquivo de teste
RSpec.describe Calculator do
  describe "#divide" do
    it "returns the division of two numbers" do
      calculator = Calculator.new
      result = calculator.divide(10, 2)

      expect(result).to eq 5
    end
  end
end

Testando apenas o caminho feliz, que é quando o divisor não é zero, ao executar os testes o Simplecov mostrou, corretamente, que a linha com raise "Division by zero error" não está coberta de testes. Isso está correto porque nos nossos testes, não criamos nenhum cenário onde o divisor era zero, e por isso o lançamento de erro nunca foi executado, ou seja, os testes "não passaram" por ali.

Então pra ter uma cobertura total do método de divisão, seria necessário criar esse cenário, esse contexto, onde o divisor seja zero e assim os testes consigam "passar" pelo lançamento de erro:

RSpec.describe Calculator do
  describe "#divide" do
    context "when b is different from zero" do
      it "returns the division of two numbers" do
        calculator = Calculator.new
        result = calculator.divide(10, 2)

        expect(result).to eq 5
      end
    end

    # Novo contexto 
    context "when b is equal to zero" do
      it "raises 'Division by zero error'" do
        calculator = Calculator.new
        expect do
          calculator.divide(10, 0) # <= dividindo por 0
        end.to raise_error("Division by zero error")
      end
    end
  end
end

Então agora já entendemos que o Simplecov sabe se a linha de código está coberta verificando se aquela linha foi executada durante a bateria de testes. Isso explica porque ele considerou aquela operação de criação de produtos coberta 100%, pois ao fazer operation.call({ title: "My product", price: 50.0 }) dentro do teste, a linha Products::NotifyUsersJob.perform_later(product) foi executada, e consequentemente ficou marcada como coberta. E isso pode ser um grande problema.

O problema em se apoiar na % de cobertura

As ferramentas de cobertura se baseiam na execução das linhas de código e não se o comportamento foi testado

Como explicado, as ferramentas de cobertura se baseiam na execução das linhas de código e não se o comportamento foi testado. Então é possível ter 100% de cobertura sem ter algo testado apropriadamente. Aproveitando o exemplo já fornecido anteriormente mas alterando a implementação do teste:

class Products::Create
  def call(attributes)
    product = Product.new(attributes)

    product.save!

    Products::NotifyUsersJob.perform_later(product)
  end
end

# Arquivo de teste
RSpec.describe Products::Create do
  it "works" do
    operation = Products::Create.new
    operation.call({ title: "My product", price: 50.00 })
  end
end

O teste deixou de verificar que era criado um produto, e agora só está executando o método sem fazer nenhuma verificação pra garantir o comportamento correto do método. Mesmo esse teste dessa forma, o relatório do Simplecov mostrará 100% de cobertura de testes.

Aí que mora o perigo de se confiar na métrica de cobertura de testes, pois como não é sobre os comportamentos testados, e sim sobre as linhas executadas, alguém pode remover uma linha por engano e ao executar a bateria de testes nenhum teste quebrará, e ainda assim a cobertura se manterá em 100%. No caso da operação de criação de produto, alguém pode refatorar o código, esquece de colocar de volta a linha que envia notificações aos usuários, e como não tem nenhum teste garantindo esse comportamento, estará tudo bem na bateria de testes, mas será um problema se esse código for pra produção, pois os usuários deixarão de receber os avisos de lançamento de produtos e, consequentemente, pode baixar a receita da empresa.

Pra corrigir essa falha de cobertura, é necessário testar também o envio de notificações aos usuários, e uma forma de testar poderia ser a seguinte:

RSpec.describe Products::Create do
  it "creates new product" do
    ...
  end

  # Novo teste
  it "notifies users" do
    expect(Products::NotifyUsersJob).to receive(:perform_later).with(any_instance_of(Product))

    operation = Products::Create.new
    operation.call({ title: "My product", price: 50.00 })
  end
end

O novo teste está verificando que o job de notificar usuários está sendo executado recebendo uma instância de produto. Talvez ainda não seja o teste ideal mas para a intenção do artigo já serve, pois o comportamento do envio de notificações. E se mesmo antes desse teste a cobertura estava 100%, com a adição do teste o cenário não mudou, continua 100%. Mas achou que finalmente a bateria de testes estava cobrindo todos os comportamentos do código? Achou errado, otário. É necessário enxergar os contextos implícitos.

Contextos implícitos

O exemplo do método #divide da calculadora tinha dois contextos bem claros, estava na cara: "Quando o divisor é zero" e "Quando o divisor não é zero". Isso é facilmente visível pela presença do if e else (o unless e elsif também ajudam a enxergar esses contextos). Pra facilitar a visualização desses contextos, podemos rascunhar um fluxograma, ficaria algo como:

Com o fluxograma conseguimos enxergar mais facilmente uma divisão de caminhos no comportamento desse método. Ao tomar uma decisão, que é verificar se o divisor é zero, o código segue por um caminho ou outro. Esses são os contextos. Quando sentir dificuldade de visualizar os contextos, você pode criar esses diagramas numa folha de papel, num programa ou mentalmente, todo código que você escreve é um processo e pode ser traduzido num fluxograma, e cada decisão que o código toma, pode ser entendido como um contexto, e esses contextos devem ser testados, ou pelo menos deveriam ser testados. Um exemplo mais complexo de código e seu fluxograma correspondente:

def shipping_label
  if product.digital? 
    "Delivery via email"
  elsif product.shipping_fee == 0
    "Free shipping"
  elsif current_user.premium?
    "Free shipping (Premium subscriber)"
  else
    product.shipping_fee
  end
end

Pelo fluxograma podemos enxergar que o código toma várias decisões e tem um fluxo bem ramificado. Então o teste desse código teria vários contextos, por exemplo: "Quando o produto é digital", "Quando o produto é físico e tem frete grátis", "Quando o produto é físico com taxa de frete e o usuário é assinante premium" e etc. Se os testes não refletirem esses cenários, grandes chances do código não estar testado apropriadamente.

Mas beleza, se esses contextos não eram fáceis de enxergar antes, com a explicação deve ter ficado um pouco mais claro. Mas tem os contextos que são "invisíveis", são implícitos, não tem um if/else ajudando a detectar. Por exemplo, começando por um fácil:

class User
  def avatar_url
    profile_picture_url || placeholder_avatar_picture_url
  end
end

O código acima retorna a foto de perfil do usuário caso exista, e caso não exista será retornada uma url de uma placeholder pra não deixar o avatar vazio. Ao explicar o funcionamento do método já foi possível detectar dois contextos: "Quando o usuário tem foto de perfil" e "Quando o usuário não tem foto de perfil". Isso se deve porque o código anterior pode ser traduzido em:

def avatar_url
  if profile_picture_url.present?
    profile_picture_url
  else
    placeholder_avatar_picture_url
  end
end

Os testes poderiam ser organizados assim:

describe "#avatar_url" do
  context "when profile picture url is present" do
    it "returns profile picture url" do
      ...
    end
  end

  context "when profile picture url is blank" do
    it "returns placeholder avatar picture url" do
      "..."
    end
  end
end

Outro exemplo de um contexto implícito:

class User
  def company_name
    company&.name # ou company.try(:name)
  end
end

O &. no Ruby é o safe navigation operator (no Rails pode ser utilizado o #try), serve pra executar o método apenas quando o objeto em questão estiver presente, evitando a chamada de um método numa referência nula. Então podemos entender que o #company_name tem 2 contextos: "Quando a empresa está presente" e "Quando a empresa não está presente". O código anterior poderia ser escrito também assim:

class User
  def company_name
    if company.present?    
      company.name 
    else
      nil
    end
  end
end

E os testes em ambos os casos seriam:

describe "#company_name" do
  context "when company is present" do
    it "returns company name" do
      ...
    end
  end

  context "when company is blank" do
    it "returns nil" do
      "..."
    end
  end
end

Agora contextos um pouco mais difíceis de enxergar:

class Posts::Publish
  def call(id)
    post = Post.find(id)

    post.update(state: :published, published_at: Time.zone.now)
  end
end

Um fluxograma mais descuidado poderia ser feito assim:

O fluxo acima está parcialmente correto porque está registrando apenas o caminho feliz da execução, mas caso a atualização do post falhe o que acontece? O fluxo não está considerando isso, e esse é um dos contextos implícitos. Vamos corrigir o fluxograma:

Agora o fluxo considera que a atualização pode falhar e assim tem dois contextos: "Quando a atualização é bem sucedida" e "Quando a atualização falha". Mas ainda tem outro contexto implícito que é: E se o post não existir na base de dados? Vamos atualizar o fluxograma pra incluir esse cenário:

Agora o fluxo está completo, e podemos perceber que mesmo o método tendo apenas 2 linhas, sem nenhuma condicional, é representado por um fluxo com 3 caminhos diferentes. Isso é devido aos contextos implícitos, que diferente dos if/else, você precisa entender o funcionamento interno dos métodos utilizados pra saber, por exemplo, se uma exceção será lançada e se o método retorna diferentes coisas dependendo da execução, que é o caso do find e do update, mas poderia ser qualquer outro método.

Com os contextos detectados, poderíamos escrever os testes pra esse método da seguinte forma:

RSpec.describe Posts::Publish do
  context "when post with given id cannot be found" do
    it "raises ActiveRecord::RecordNotFound error" ...
  end

  context "when update is successful" do
    it "publishes post" ...
    it "returns true" ...
  end

  context "when update fails" do
    it "doesn't publish post" ...
    it "returns false"
  end
end

Se o fluxo não tivesse sido destrinchado e fossémos utilizar a primeira versão pra implementar nossos testes, teria ficado algo assim:

RSpec.describe Posts::Publish do
  it "publishes post" ...
end

E no Simplecov, ambos os testes resultariam em 100% de cobertura do método. Mas qual você abordagem você acha que garante melhor o funcionamento do código? Pra mim é o teste com os três contextos. Por isso reforço que a % cobertura de teste por si só não é relevante pra medir a qualidade dos testes, é necessário um melhor entendimento do que está sendo testado por parte da pessoa que está escrevendo código e por parte das pessoas que vão revisar aquele código, assim os testes "meia boca" podem ser detectados e melhorados.

E ainda há outros tipos de contexto implícito, tipo esse:

def call
  ActiveRecord::Base.transaction do
    Customer.create!(...)
    Store.find(...).update(...)
  end
end

O código acima cria um cliente e depois atualiza a loja. O contexto implícito além do create!, que pode gerar uma exceção, é que caso ocorra uma falha na atualização da loja, a criação do cliente deve ser desfeita devido à criação e atualização estarem englobados numa transação do banco de dados. Então se isso for um requisito do código, o ideal é que haja um teste cobrindo esse comportamento, pois se alguém remover essa transaction, deve receber um aviso que está alterando o comportamento do código.

E vão ter outros contextos não tão implícitos assim mas que vale a pena citar rapidamente:

# um if inline continua tendo 2 contextos
button_class = "active" if post.featured?

# um if ternário continua tendo 2 contextos
submit_text = product.persisted? ? "Update" : "Create"

Em ambos os casos o Simplecov por padrão tratará a linha como coberta, mesmo se o teste não cobrir os diferentes cenários.

Então voltando pro nosso primeiro exemplo, da operação de publicação de produto, temos um contexto implícito lá, que é ao utilizar o #save!, caso os atributos sejam inválidos, uma exceção será lançada e a execução do método abortada. Então atualizando nossos testes pra considerar essa situação, seria algo como:

RSpec.describe Products::Create do
  context "with valid attributes" do
    it "creates new product" ...
    it "notifies users" ...
  end

  # novo contexto
  context "with invalid attributes" do
    it "raises ActiveRecord::RecordInvalid error" ...
    it "doesn't notify users" ... # <= maior segurança aqui
  end
end

E agora podemos considerar que nossos testes estão suficientes, pois verifica se com os parâmetros válidos, o produto está sendo criado e as notificações disparadas, e com os parâmetros inválidos, verificamos o lançamento da exceção e que nenhum usuário foi notificado.

Paranóia

Gosto de dizer pras pessoas que ajudo a se desenvolver na programação que o objetivo dos testes é fazer o código ser à prova de sabotagem. O "sabotador" pode ser uma pessoa do time, uma pessoa nem entrou mas ainda vai entrar no time, ou até mesmo a própria pessoa que no futuro precisará voltar pra dar manutenção naquele código. O teste deve detectar se mesmo após as modificações realizadas no código, o código está fazendo o que foi especificado pra fazer. Utilizando ainda a operação de publicação de produto como exemplo:

class Products::Create
  def call(attributes)
    product = Product.new(attributes)

    product.save!

    Products::NotifyUsersJob.perform_later(product)
  end
end

Se a pessoa ao dar manutenção no código, remover sem intenção a linha de disparo de notificações, o teste deve quebrar pois um requisito era enviar notificação aos usuários após a criação do produto. Se trocar o save! pelo save, o teste deve quebrar, pois sem isso o código disparará as notificações mesmo quando o produto estiver inválido, fazendo os usuários receberem notificações de produto que não existe. Geralmente esses erros acontecem por desatenção, por não conhecer a base de código, e o papel do teste é defender o funcionamento do código.

Há lendas de que na Netflix existe o Macaco do Caos, um serviço na infraestrutura que desliga um servidor da empresa propositalmente pra verificar se os sistemas continuam funcionando, se adaptando à situação sem intervenção manual e sem causar nenhum impacto ao usuário final. Depois isso evoluiu pra um exército de macacos que fazem diferentes tipos de sabotagem, como diminuir o tempo de resposta de um serviço, por exemplo. Então podemos assumir que os times de desenvolvimento são compostos por vários macacos do caos bem intencionados, ou seja, o propósito deles não é causar um problema intencionalmente, mas sim adicionar novas funcionalidades, corrigir problemas, mas devido à natureza do desenvolvimento de software, estão suscetíveis a adicionar problema no código, e a função dos testes é ser à prova de macacos do caos, aumentando as chances de códigos defeituosos serem detectados antes de chegarem em produção e causarem efeitos colaterais aos usuários da aplicação.

Então a mentalidade ao escrever testes deve ser:

Primeiro entender o que o código faz
Identificar os contextos explícitos e explícitos
Definir o que é essencial no funcionamento do código
Garantir, com testes, que o código está fazendo o que é pra fazer

Dessa forma, quando alguém alterar o código e quebrar algo, será avisado que sua alteração mudou o comportamento da aplicação, se for algo intencional, os testes devem ser alterados pra refletirem o novo comportamento, ou o código deve ser corrigido pra manter o comportamento original.

Dependendo do nível de paranóia de quem está implementando os testes, proteger o código com testes pode ser bem trabalhoso. Vamos utilizar uma método de soma como exemplo:

class Calculator
  def sum(a, b)
    a + b
  end
end

# Arquivo de teste
RSpec.describe Calculator do
  describe "#sum" do
    it "returns the sum of two numbers" do
      calculator = Calculator.new
      result = calculator.sum(5, 2)

      expect(result).to eq 7
    end
  end
end

O teste está bem direto, verifica que chamando o #sum com 5 e 2, retorna 7. Isso já garante que a soma está funcionando como deveria. Mas seguindo a ideia de que tem vários macacos do caos no time, algum deles no futuro poderia alterar o método #sum pra algo assim:

class Calculator
  def sum(a, b)
    7
  end
end

Os testes não quebrariam mesmo com o código claramente errado. Então pra se proteger dos macacos do caos os testes poderiam ser ajustados:

RSpec.describe Calculator do
  describe "#sum" do
    it "returns the sum of two numbers" do
      calculator = Calculator.new

      expect(calculator.sum(5, 2)).to eq 7
      expect(calculator.sum(59, 5)).to eq 64
      expect(calculator.sum(-2, 2)).to eq 0

      # ou
      a = rand(100)
      b = rand(100)
      expect(calculator.sum(a, b)).to eq a + b
    end
  end
end

Pronto, agora já está evitando que seja colocado um número fixo no retorno do método, e o agora teste avisará ao macaco do caos que aqui ele não se cria. Mas toda vez que cria uma defesa pra esses casos, podem surgir vários outros, exemplo:

class Calculator
  def sum(a, b)
    if a == 5 && b == 2
      return 7
    elsif a == 59 && b == 5
      return 64
    elsif a == -2 && b == 2
      return 0
    else 
      User.delete_all
      a + b
    end
  end
end

O macaco do caos, que parece estar bem mal intencionado agora, conseguiu burlar sua proteção, e ainda colocou algo mais perigoso, colocou um código que destrói toda sua base de usuários, e o teste está passando sem problemas. Claro, tudo isso é ficção, esse tipo de coisa não vai acontecer em times saudáveis, mas serve pra mostrar que não é possível defender seu código de todas as possíveis alterações que podem ser feitas, principalmente garantir que coisas não esperadas não foram feitas, e que é improdutivo se tentar alcançar esse nível de defesa. Mas de toda forma, é possível colocar algumas garantias em contextos relevantes que são mais propícios de acontecer, por exemplo, garantir que um e-mail não foi enviado caso o produto esteja inválido, garantir que o item de pagamento mudou o status para reembolsado ao chamar com sucesso o endpoint de reembolso da API de gateway, e etc.

Conclusão

No fim, testar código é uma arte, uma habilidade que pode e precisa ser desenvolvida, é um jogo onde você sempre está negociando clareza e legibilidade contra segurança e rigidez. Testes são códigos da aplicação e também recebem manutenção, também são lidos, e é necessário ver até onde faz sentido degradar a legibilidade e manutenibilidade pra garantir um teste, às vezes desnecessariamente, mais seguro. Há pontos cruciais da aplicação que você precisa cobrir todos os contextos e todos os retornos pois se algo ali mudar, pode dar problema sério, geralmente são os pontos que geram dinheiro pra empresa, como o login, checkout de pagamento, ou que podem fazer a empresa perder muito dinheiro, como uma falha de segurança ou vazamento de dados. E tem outros códigos que são menos críticos e que você pode só testar que funciona sem quebrar pois se eles um dia deixarem de funcionar, o estrago será pequeno, sendo corrigido facilmente, não há nada de errado em ter testes frágeis nesses casos. Também há outros mecanismos que auxiliam a evitar problemas maiores, mais cedo, antes de um eventual problema se tornar um problema crítico, como na revisão de código dos pull requests, QA manual/automático, ambiente de staging/homologação, feature flags na liberação de novas funcionalidades antes de liberar para o público geral e etc, então o desafio é sempre encontrar um modelo de desenvolvimento sustentável da base de código.

Evitando IDs sequenciais no Ruby on Rails

Stephann — Wed, 30 Mar 2022 13:12:39 +0000

Introdução

Por padrão as aplicações Ruby on Rails utilizam identificadores sequenciais para representar a chave primária de uma tabela. Por alguns motivos esse comportamento pode não ser o desejado, seja por revelar informações estratégicas do produto ou por facilitar que alguém mal intencionado explore falhas da aplicação. Por exemplo, se um sistema utiliza ID sequenciais, fica fácil descobrir quantos usuários a empresa tem ou então quantos pedidos ela está recebendo. Ou então, alguém criar um script que saia percorrendo os IDs de 1 em 1 extraindo as informações disponíveis, sejam públicas ou que foram expostas por alguma falha de autorização. Uma alternativa que pode ser utilizada para evitar esses problemas é o UUID. Nesse artigo mostro como configurar sua aplicação para utilizar o UUID como a chave primária de suas tabelas.

Como toda escolha que fazemos no desenvolvimento de software traz vantagens e desvantagens, essa decisão entre UUID x Inteiro não seria diferente, vale a pena ler o artigo do Rafael Ponte sobre esse assunto: https://rponte.com.br/2021/01/30/nao-use-uuid-como-pk-nas-tabelas-do-seu-banco-de-dados/. Leve em consideração o peso de utilizar UUIDs como chave primárias e analise se faz sentido para o seu caso.

O que é UUID?

O UUID é um unificador único universal, que também pode ser chamado de GUID (identificador único global). Ele é formado por 32 dígitos hexadecimais agrupados em 5 grupos separados por hífens. Exemplos de UUID:

71b69829-813b-44c7-b75d-8a2f3728520d
ec1a3b99-528f-4f90-a8dc-46f467848b93
a04f2e7c-47ab-419d-bfab-32fd4492d80e
f9daaec4-b915-4e07-8690-6246b48a1cb9

Imaginando a URL de detalhes de um pedidos de compra, ao invés de meusite.com/orders/32, ela seria algo assim: meusite.com/orders/71b69829-813b-44c7-b75d-8a2f3728520d. Ou seja, não revela nada sobre a quantidade de pedidos que a aplicação recebeu, e caso alguém queira tentar acessar pedidos de outros usuários, será quase impossível de advinhar os IDs de pedidos existentes.

Instalando a extensão do PostgreSQL

A função que o PostgreSQL utilizará para gerar os UUID para as nossas chaves primárias é a gen_random_uuid(), uma função da extensão pgcryto que não vem instalada por padrão. Então para instalá-la, primeiro crie uma migração:

bundle exec rails g migration enable_pgcrypto_extension

E no arquivo gerado coloque:

class EnablePgcryptoExtension < ActiveRecord::Migration[6.1]
  def change
    enable_extension 'pgcrypto'
  end
end

Ao executar um bundle exec rails db:migrate, a extensão estará instalada e pronto para ser utilizada.

Configurando os generators para utilizar o UUID

Mesmo com a extensão instalada, se você gerar um modelo ou um scaffold, as estruturas de banco de dados continuarão sendo geradas com um ID sequencial. Isso porque não foi configurado nada no Rails ainda para que ele utilizasse o UUID. Então vamos fazer isso. Crie o arquivo config/initializers/generators.rb e adicione o seguinte código:

Rails.application.config.generators do |g|
  g.orm :active_record, primary_key_type: :uuid
end

Agora ao gerar um modelo a migração será criada assim:

class CreateOrders < ActiveRecord::Migration[6.1]
  def change
    create_table :orders, id: :uuid do |t|
      t.string :description
    end
  end
end

A diferença é o parâmetro id: :uuid passado no create_table, que fará o tipo da coluna ID ser UUID. Outra coisa que essa configuração faz, é informar automaticamente o tipo do ID na definição da chave estrangeira. Explicando melhor: Se por acaso eu precise adicionar a coluna com o ID do pedido na tabela pagamento, essa coluna precisa ser do tipo UUID também. Então caso eu execute um bundle exec rails g migration add_order_to_payments order:reference, será gerada uma migração assim:

class AddOrderToPayments < ActiveRecord::Migration[6.1]
  def change
    add_reference :payments, :order, 
      null: false, 
      foreign_key: true, 
      type: :uuid
  end
end

Note o type: :uuid nos parâmetros do add_reference, isso fará a coluna order_id ser do tipo UUID e assim poderá se referenciar a outra tupla da tabela orders.

Finalizando a configuranção

Basicamente já está tudo configurado e pronto para a utilização, não precisa fazer mais nada. Podemos confirmar isso criando objetos pelo terminal com o bundle exec rails c e executando algum Order.create(description: 'Some description') ou então utilizando as telas normalmente para cadastrar os dados. Os IDs estarão preenchidos normalmente com os UUID, a navegação na URL também estará funcionando normalmente.

Se você for curioso o suficiente, ao navegar nas telas ou executando algo como Order.first ou Order.last, perceberá que a ordenação está estranha. O Model.first nem sempre retornará o primeiro registro criado, e o Model.last poderá não retornar o registro mais recente. Isso se deve ao fato do Rails, por padrão, ordenar as consultas pelo ID, ou seja, ele automagicamente faz por baixo algo como um ORDER BY id nas consultas. Como o UUID não é gerado em uma ordem específica, o primeiro registro criado pode ter seu ID iniciando com ec1a3..., e o último criado ter o ID iniciando com a04f2..., então ao fazer um Model.first, o Rails trará na verdade o último registro criado.

Mas isso pode ser configurado, é bem simples. Essa configuração é feita no arquivo app/models/application_record.rb, pois é a classe que todos os outros modelos herdam. Esse arquivo deve ficar assim:

class ApplicationRecord < ActiveRecord::Base
  primary_abstract_class
  self.implicit_order_column = :created_at
end

Foco na linha self.implicit_order_column = :created_at, que fará o Rails utilizar a coluna created_at para ordenar os registros caso não seja explicitamente informado nenhum outro campo de ordenação.

Conclusão

É isso. É algo simples, fácil, que não interfere em controller, nas rotas, o uso do framework continua basicamente o mesmo e você ainda tem todas as vantagens de não revelar informações estratégicas sobre o produto.

Um curiosidade para encerrar: O UUID não é único, o gen_random_uuid() do PostgreSQL pode gerar um UUID repetido em uma mesma tabela. Mas não precisa se preocupar, mesmo que você tenha trilhões de registros em uma tabela, é mais fácil você morrer devido a uma queda de meteorito na sua cabeça, do que ser gerado um UUID duplicado, e quando isso acontecer, não será um problema grande, pois as chaves primárias do PostgreSQL têm restrição de unicidade. Mas se acontecer: Que azar, hein? Cuidado ao sair de casa.

Utilizando views SQL no Ruby on Rails

Stephann — Mon, 28 Mar 2022 14:12:02 +0000

Introdução

Na maior parte do tempo, o desenvolvedor Rails quando precisa de alguma informação do banco de dados, usa a API do Active Record pra fazer suas consultas, mas às vezes isso não é suficiente para trazer os dados desejados e é necessário escrever código SQL puro na aplicação. Geralmente isso significa que a informação é complexa demais pra ser obtida apenas as instruções básicas SELECT, WHERE, JOIN, ou então significa que ela é volátil o bastante pra não virar uma tabela fixa no banco de dados. Por exemplo, os vendedores com o maior volume de negociações no ano, uma listagem com os produtos do mercantil mais vendidos em diferentes momentos do dia ou o ticket médio dos clientes por faixa etária. Para dificultar ainda, às vezes é necessário permitir que esses dados sejam ordenados, filtrados e paginados, o que pode adicionar mais complexidade ainda para a consulta.

Uma forma de simplificar essas dores é abstrair essas consultas utilizando as views do banco de dados, que são basicamente tabelas virtuais, ou seja, os não estão persistidas no disco mas fornecem algumas facilidades das tabelas tradicionais. Com isso, ao invés de lidar sempre com uma consulta complexa do SQL, pode ser usado apenas o nome da view para pegar as informações pretendidas. E como a view se comporta como uma tabela, é possível mapear um modelo do ActiveRecord para uma view do banco de dados com apenas algumas modificações simples e é isso que vou mostrar nesse artigo.

Pra facilitar, e também apresentar uma biblioteca que pode ser desconhecida pra alguns, vou utilizar a gem scenic para gerenciar as views da aplicação Rails, mas é opcional, quem não puder ou não quiser adicionar essa dependência no projeto, tudo pode ser feito tranquilamente sem ela. Quem for seguir SEM a scenic, ficam as dicas:

A criação de views é feita nas migrations utilizando o comando execute, por exemplo:

class CreateMinhaView < ActiveRecord::Migration[6.1]
  def up
    execute <<-SQL
      CREATE OR REPLACE VIEW public.minha_view
      ...
    SQL
  end

  def down
    execute "DROP VIEW public.minha_view"
  end
end

E para armazená-las corretamente no dump do schema, é necessário mudar o seu formato para :sql lá no application.rb, assim:

module MeuApp
  class Application < Rails::Application
    ...
    config.active_record.schema_format = :sql
  end
end

Vale ressaltar que utilizarei o PostgreSQL como banco de dados, talvez para outros bancos de dados sejam necessárias algumas modificações no que vou ensinar. E quando eu me referir a views nesse artigo, serão sempre as views do banco de dados, e não as views html do projeto.

Contexto

O problema que vamos solucionar é o seguinte: Nossa aplicação é um quadro de estatísticas que serve para registrar as conquistas dos jogadores de uma comunidade de e-sports. A modelagem é simples, é a seguinte:

Teremos o modelo Player com o atributo nome que representará o jogador da comunidade. O modelo Trophy servirá para representar os troféus que os jogadores poderão obter e terá o atributo de pontuação, que é o valor a ser contabilizado na classificação geral. Por exemplo:

1º Lugar no Torneio Semanal: 100 pontos
2º Lugar - Torneio Semanal: 50 pontos
1º Lugar - Torneio Mensal: 500 pontos
2º Lugar - Torneio Mensal:  250 pontos

E por fim, teremos o modelo Achievement, que servirá para registrar as conquistas dos jogadores, ou seja, nele será representado o jogador e qual troféu ele ganhou.

Para criar essa estrutura que descrevi, crie uma nova aplicação Rails e execute esses comandos no terminal:

bundle exec rails g model player name
bundle exec rails g model trophy title points:integer
bundle exec rails g model achievement player:references trophy:references
bundle exec rails db:create db:migrate

Agora vamos preencher com alguns dados falsos para termos com o que testar. No arquivo db/seeds.rb coloque o seguinte código e depois execute um bundle exec rails db:seed:

# Players
player_a = Player.create!(name: 'Jogador A')
player_b = Player.create!(name: 'Jogador B')
player_c = Player.create!(name: 'Jogador C')
player_d = Player.create!(name: 'Jogador D')

# Trophies
tropy_gold_estadual = Trophy.create!(
  title: 'Ouro - Torneio Estadual',
  points: 100
)
tropy_silver_estadual = Trophy.create!(
  title: 'Prata - Torneio Estadual',
  points: 50
)
tropy_gold_nacional = Trophy.create!(
  title: 'Ouro - Torneio Nacional',
  points: 500
)
tropy_silver_nacional = Trophy.create!(
  title: 'Prata - Torneio Nacional',
  points: 300
)

# Player A achievements
# 2x Gold Nacional
# 2x Gold Estadual
# Total: 1200 points
[
  tropy_gold_estadual, 
  tropy_gold_estadual, 
  tropy_gold_nacional,
  tropy_gold_nacional
].each do |trophy|
  Achievement.create!(
    player: player_a,
    trophy: trophy
  )
end

# Player B achievements
# 1x Gold Estadual
# 1x Silver Estadual
# Total: 150 points
[ 
  tropy_gold_estadual, 
  tropy_silver_estadual
].each do |trophy|
  Achievement.create!(
    player: player_b,
    trophy: trophy
  )
end

# Player C achievements
# 3x Silver Estadual
# Total: 150 points
[
  tropy_silver_estadual, 
  tropy_silver_estadual, 
  tropy_silver_estadual
].each do |trophy|
  Achievement.create!(
    player: player_c,
    trophy: trophy
  )
end

# Player D achievements
# 1x Gold Nacional
# 1x Silver Nacional
# 1x Gold Estadual
# Total: 850 points
[
  tropy_gold_nacional, 
  tropy_silver_nacional, 
  tropy_silver_estadual
].each do |trophy|
  Achievement.create!(
    player: player_d,
    trophy: trophy
  )
end

Problema

Com nossa estrutura montada e com alguns dados fictícios criados, nos deparamos com a necessidade de mostrar um ranking, uma classificação geral de todos os jogadores da comunidade em uma tela. Para resolver essa consulta com a API do ActiveRecord, poderia ser feito algo assim:

players = Player
  .select(
    <<-SQL
      players.name, 
      sum(trophies.points) as total_points
    SQL
  )
  .joins(achievements: :trophy)
  .group('players.id')
  .order('total_points DESC')

players.each do |player|
  puts player.name
  puts player.total_points
  puts '----'
end

# No console apareceria:
# Jogador A
# 1200
# ----
# Jogador D
# 850
# ----
# Jogador B
# 150
# ----
# Jogador C
# 150

Perceba que esse código faz um select utilizando SUM, 2 joins, um group e uma ordenação. Não é lá um código muito bonito de se ver espalhado pela aplicação e também não é muito fácil manter. Supondo que a comunidade de jogadores seja enorme e precise fazer uma paginação, ou a consulta evolua para algo mais personalizado que precise de algum filtro, esse código pode ficar mais complexo ainda. Para ajudar a organizar isso, vamos transferir essa consulta para uma view do banco de dados.

Instalando a gem scenic

Para ajudar a gerenciar as views sql, vou utilizar a gem scenic. Ela traz a vantagem de poder utilizar as views sem a necessidade de alterar o formato do schema.rb para structure.sql. De quebra fornece um versionamento dessas views facilitando o acompanhamento das modificações e as reversões pra versões anteriores. Outro ponto positivo é que todo o código da estrutura da view é armazenado em arquivos .sql, facilitando o realce da sintaxe e a execução do código em terminais ou outras ferramentas de banco de dados.

Para instalar a scenic no nosso projeto, primeiro adicione gem 'scenic' no arquivo Gemfile e depois execute um bundle install para finalizar a instalação.

Criando a view no banco de dados

Para gerar uma view com a scenic é necessário executar o comando no console:

bundle exec rails g scenic:view ranking_items

Esse comando cria um arquivo na pasta db/migrations chamado de [TIMESTAMP]_create_ranking_items.rb com o seguinte conteúdo:

class CreateRankingItems < ActiveRecord::Migration[6.1]
  def change
    create_view :ranking_items
  end
end

E também é criado o arquivo db/views/ranking_items_v01.sql sem nada escrito nele. É nele que vamos colocar o código que cria nossa view:

SELECT
  players.id AS player_id,
  players.name AS player_name,
  sum(trophies.points) AS total_points
FROM
  players
INNER JOIN
  achievements 
  ON achievements.player_id = players.id
INNER JOIN
  trophies
  ON trophies.id = achievements.trophy_id
GROUP BY
  players.id
ORDER BY
  sum(trophies.points) DESC;

Perceba que não coloquei nenhum CREATE OR REPLACE VIEW, que são os comandos SQL relacionados a criação ou substuição da view, pois a scenic já entende que uma view deve ser criada com o nome ranking_items através do create_view :ranking_items que está na migração gerada.

Para finalizar e criar a view no banco de dados execute um bundle exec rails db:migrate. Com isso, se você for no terminal psql ou no seu SGBD poderá conferir o resultado que a view está gerando com a consulta SELECT * FROM ranking_items:

Criando o modelo

Agora é a hora de mapear a view que criamos no banco de dados para um modelo do ActiveRecord. Não é muito diferente de criar um modelo que aponta para uma tabela física mas tem algumas diferenças. Na pasta app/models crie um arquivo chamado ranking_item.rb e coloque o seguinte conteúdo:

class RankingItem < ApplicationRecord
  protected

  def readonly?
    true
  end
end

É necessário sobrescrever o método protegido readonly? para informar ao Rails e aos demais desenvolvedores que utilizando esse modelo não é permitido inserir, atualizar ou apagar informações no banco de dados, e se alguém tentar fazer essas ações receberá a exceção avisando ActiveRecord::ReadOnlyRecord (RankingItem is marked as readonly). Sem essa configuração, os métodos create, update, save, destroy e afins, lançarão erros de sintaxe do SQL não muito claros.

Antes de prosseguir, só uma dica útil para quem não quer ou não pode seguir o padrão de nomeação das views de acordo com o nome do modelo. Existe a possibilidade de configurar o modelo para informar qual o nome da view que ele deve buscar os dados. Por exemplo, supondo que sua view teve que ser criada com o nome dbviews_0001_ranking, você terá que fazer assim no modelo:

class RankingItem < ApplicationRecord
  self.table_name = :dbviews_0001_ranking
  # ... resto do código
end

Pronto, agora se abrir o console do rails com o bundle exec rails c, o modelo poderá ser utilizado normalmente, boa parte da API do ActiveRecord será compatível:

RankingItem.first
# => #<RankingItem player_id: 9, player_name: "Jogador A", total_points: 1200>

RankingItem.all
# => #<ActiveRecord::Relation [#<RankingItem ...>]>

r = RankingItem.find_by(player_name: 'Jogador A')
r.total_points 
# => 1200

RankingItem.where('total_points > 800').size
# => 2

RankingItem.limit(2).offset(2)
# => #<ActiveRecord::Relation [#<RankingItem ...>]>

Outra vantagem é que posso também usar as associações do Rails para integrar com outros modelos. Por exemplo, um ranking_item pertence a um player. É totalmente possível adicionar um belongs_to :player na classe RankingItem e acessar o jogador dessa forma:

r = RankingItem.first
r.player
# => #<Player id: 9, name: "Jogador A", created_at: ...

Quase pronto, mas acho que seria bom mostrar a posição do jogador na classificação e percebi que a view que criei não foi criada com essa coluna. Como fazer isso?

Modificando views já existentes

A scenic também auxilia quando uma view precisa ter sua estrutura alterada. O comando é o mesmo que é utilizado para criar a view, ou seja: bundle exec rails g scenic:view ranking_items. Isso gerará um arquivo de migração chamado [TIMESTAMP]_update_ranking_items_to_version_2.rb com o seguinte conteúdo:

class UpdateRankingItemsToVersion2 < ActiveRecord::Migration[6.1]
  def change
    update_view :ranking_items, version: 2, revert_to_version: 1
  end
end

A diferença aqui é que ao invés do create_view que foi gerado na primeira vez que executamos o comando, agora tem um update_view, a próxima versão que deverá ser utilizada quando a migração for executada e qual a versão deverá voltar em caso de reversão dessa migração. Esse update_view fará um DROP VIEW e criará uma nova já atualizada, mas nem sempre é possível por conta de dependências entre views. Se um dia passar por essa situação e desejar utilizar um CREATE OR REPLACE VIEW, troque o update_view por replace_view.

O comando também gerou o arquivo db/views/ranking_items_v02.sql já preenchido com o código da primeira versão. Na nova versão, vou adicionar a coluna rank utilizando a função RANK do SQL que representará a posição do jogador, e também deixarei de ordenar pela soma dos pontos e passarei a ordenar pela nova coluna rank. A v2 ficará assim:

SELECT
  RANK() OVER(ORDER BY sum(trophies.points) DESC) AS rank,
  players.id AS player_id,
  players.name AS player_name,
  sum(trophies.points) AS total_points
FROM
  players
INNER JOIN
  achievements
  ON achievements.player_id = players.id
INNER JOIN
  trophies
  ON trophies.id = achievements.trophy_id
GROUP BY
  players.id
ORDER BY
  rank;

Execute o bundle exec rails db:migrate e você terá sua view atualizada. Se fizer o select na tabela verá o novo campo com a posição do jogador:

Mas e se a consulta da nossa view fosse tão complexa, em tabelas enormes quantidades de registros que não fosse possível utilizar uma view comum e fosse necessária uma view materializada? O scenic também tem opções pra esses casos.

Materializando a view

Caso você precise de uma view materializada, os comandos para gerá-la são os mesmos que eu passei até agora, com a diferença que a flag —-materialized deverá estar presente. Por exemplo: rails g scenic:view nome_da_view --materialized.

Para atualizar os dados da view materializada a scenic disponibiliza o método Scenic.database.refresh_materialized_view. Então é possível você criar um método de classe no seu modelo para facilitar o uso, fica assim:

class MeuModelo < ApplicationRecord
  def self.refresh
    Scenic
      .database
      .refresh_materialized_view(
        'nome_da_view_materializada', 
        concurrently: false, 
        cascade: false
      )
  end

  protected

  def readonly?
    true
  end
end

Conclusão

É isso, apresentei mais uma solução que vale sempre a pena ter em mãos para quando situações como as apresentadas surgirem no dia a dia. Lembrando sempre, que nem sempre essa é a melhor opção para solucionar todos os problemas, às vezes faz mais sentido criar uma tabela física mesmo ou então usar o padrão Query Objects que falarei posteriormente sobre ele aqui no blog.

Configurando o Rails, RSpec e Rubocop no Github Actions

Stephann — Fri, 25 Mar 2022 23:19:45 +0000

Introdução

A integração contínua, ou CI (continuous integration) é a estratégia de compilar e testar a aplicação toda vez que um desenvolvedor desejar integrar suas modificações ao repositório central. Essa estratégia ajuda a detectar falhas tanto no código enviado, como no encaixe desse novo código ao código já existente, de forma mais precoce dentro do fluxo de desenvolvimento. No CI podem ser executados testes automatizados, analisadores de estilo e de organização, escaneadores de vulnerabilidades e qualquer coisa que possa ser automatizada e ajude o time de desenvolvimento ter uma aplicação mais segura, organizada ou com bom desempenho.

Uma das ferramentas disponíveis para implementar o CI, é o Github Actions, um produto disponibilizado dentro do ecossistema do Github e que se integra perfeitamente dentro da página dos repositórios sem nenhuma fricção de ter que ficar trocando de serviço para acompanhar o andamento das execuções, ou de ter que configurar o acesso de outro serviço aos projetos. Nesse artigo vou explicar como configurar o Github Actions em uma aplicação Rails, executando o RSpec (um framework de testes) e o Rubocop (um analisador de código Ruby).

Criando o workflow

No fim do artigo eu coloquei o arquivo YAML completo para quem quiser apenas copiar e colar e adequar para sua realidade. Aqui eu vou explicar o que significa cada configuração para explicar os porquês de cada linha e suas alternativas.

O primeiro passo é criar uma pasta na raíz do repositório chamada .github e adicionar a pasta workflows dentro dela, pois é nessa pasta que o Github detecta que o projeto tem fluxos a serem executados. Depois crie um arquivo YAML dentro de .github/workflows e nomeie com algo que indique a natureza do fluxo que será executado. Pro caso de testes e análise de código, eu geralmente nomeio como ci.yml ou test_and_code_analysis.yml.

A estrutura básica do YAML que o Github Actions aceita é basicamente essa:

name: CI # Nome do fluxo
on: push # Evento que dispara o fluxo
jobs:
  rubocop: # Identificador do job
    ... # Configurações do job
  rspec: # Identificador do job
    ... # Opçòes de configuração do job

Logo mais vou explicar como configurar cada um dos jobs, mas primeiro, atenção para o on: push, nele é colocado o evento que fará o fluxo ser disparado. No meu caso, eu coloco push, pois quero que o CI seja executado toda vez que alguém fizer um git push origin nome_do_branch. Mas há a opção de executar apenas quando um pull request for criado, que é a configuração on: pull_request. Para outras opções de evento, há uma lista bem detalhada na documentação oficial do Github.

Configurando o Rubocop

Deixando claro que essa parte é opcional, pois caso tu não tenha necessidade ou possibilidade de ter uma análise de código no projeto, é só seguir o artigo sem adicionar os códigos referentes ao Rubocop e aproveitar apenas os trechos que mostro como configurar a execução dos testes.

Voltando ao .github/workflows/ci.yml para definir o fluxo de análise de código:

...
rubocop:
  name: Rubocop
  runs-on: ubuntu-latest # Informa o SO que será usado nos testes
  steps:
    # Pega o código do projeto
    - name: Checkout code
      uses: actions/checkout@v1

    # Configura o Ruby e instala as dependências
    - name: Setup Ruby
      uses: ruby/setup-ruby@v1
      with:
        bundler-cache: true
        # Exemplo de outras configurações:
        # ruby-version: 3.0.0
        # bundler: 2.2.8
        # working-directory: ./backend

    # Executa o Rubocop
    - name: Analyze code
      run: bundle exec rubocop
...

É um fluxo simples, com 3 passos: Pegar o código, instalar o ruby e as dependências e executar o Rubocop. Antes de seguir, vale a pena me aprofundar nesse passo de instalação do Ruby para explicar melhor o que está acontecendo. Antes, o modo "oficial" de instalar o Ruby num fluxo, era utilizando a action criada pela equipe do Github, a actions/setup-ruby, mas ela foi depreciada recentemente, e agora é sugerido utilizar a ruby/setup-ruby, uma action mantida pelo time do Ruby. Ela tem algumas configurações importantes que podem ser passadas dentro do with::

ruby-version:
Essa opção permite que seja informada a versão do ruby que será instalada. Caso não seja definida, será detectada a versão definida no arquivo .ruby-version ou no .tool-versions.

bundler:
Essa opção serve para definir a versão do bundler que será utilizada para instalar as dependências. Se não estiver definida, a versão será detectada de acordo com o BUNDLED_WITH do Gemfile.lock, e se não encontrar, será utilizada a versão mais recente.

working-directory:
Caso o repositório tenha uma organização de pastas diferenciada, e a aplicação Rails não esteja na raíz, é necessário informar o caminho onde estão os arquivos .ruby-version, .tool-versions e Gemfile.lock, assim as versões do Ruby e do bundler poderão ser detectadas. No caso da aplicação que trabalho, tenho que fazer: working-directory: ./services/catarse, para o fluxo funcionar corretamente.

bundler-cache:
Se essa opção estiver como true, a action irá instalar as dependências com um bundle install e fará o cache das gems de forma automática, para não ter que instalar todo o conjunto de dependências a cada nova execução do fluxo.

Agora note que não configurei nada de PostgreSQL, ou NodeJS, porque a análise de código do Rubocop não necessita dessas ferramentas, apenas do Ruby e das gems da família Rubocop.

Configurando o RSpec

Agora o principal, que é a execução dos testes. Dessa vez terá uns passos a mais, mas também nada muito complexo. Primeiro vou deixar a configuração inteira e vou explicando aos poucos parte por parte:

rubocop:
  ...
rspec:
  name: RSpec
  needs: rubocop
  runs-on: ubuntu-20.04
  env:
    RAILS_ENV: test
    DATABASE_URL: postgres://postgres:example@localhost:5432/db_test
  services:
    postgres:
      image: postgres:latest
      ports: ['5432:5432']
      env:
        POSTGRES_DB: db_test
        POSTGRES_USER: postgres
        POSTGRES_PASSWORD: example
      options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5
  steps:
    - name: Checkout code
      uses: actions/checkout@v1

    - name: Setup Ruby
      uses: ruby/setup-ruby@v1
      with:
        bundler-cache: true

    - name: Install postgres client dependencies
      run: sudo apt-get install libpq-dev

    - name: Setup Node
      uses: actions/setup-node@v1
      with:
        node-version: 12.20.0

    - name: Yarn package cache
      uses: actions/cache@v2
      with:
        path: ./node_modules
        key: ${{ runner.os }}-yarn-v1-${{ hashFiles('./yarn.lock') }}

    - name: Install Yarn packages
      run: yarn install --pure-lockfile

    - name: Create database
      run: |
        bundle exec rails db:create
        # Se o projeto usar `schema.rb`
        bundle exec rails db:schema:load
        # Se o projeto usar `structure.sql`
        bundle exec rails db:structure:load
        # Se o projeto não usar nenhum dos dois
        bundle exec rails db:migrate

    - name: Run tests
      run: bundle exec rspec spec

Começando primeiro por aqui:

rspec:
  name: RSpec
  needs: rubocop
  runs-on: ubuntu-20.04

É bem parecido com o início da definição do fluxo do Rubocop, mas com um parâmetro a mais, o needs. Essa configuração serve para avisar ao Github que o RSpec só poderá ser executado depois da execução bem sucedida do Rubocop, ou seja, se o código estiver fora do padrão do time, os testes nem serão executados. Mas caso queira que o RSpec e o Rubocop sejam executados paralelamente, só remover essa opção, fica ao critério da equipe. Agora a configuração do banco que dados:

env:
  RAILS_ENV: test
  DATABASE_URL: postgres://postgres:example@localhost:5432/db_test
services:
  postgres:
    image: postgres:latest
    ports: ['5432:5432']
    env:
      POSTGRES_DB: db_test
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: example
    options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5

No env.DATABASE_URL, eu defini uma URL de conexão com o banco de dados que o Rails utilizará quando for criar a estrutura das tabelas da aplicação. Essa URL é baseada nas configurações que passei na criação do serviço postgres que será necessário para a execução dos testes. Informei a imagem sendo postgres:lastest que pegará o PostgreSQL mais recente, mas pode ser utilizada qualquer versão, por exemplo: postgres:12. Dentro de services.postgres.options está alguns comandos para aguardar o servidor de banco de dados subir, senão corre o risco do fluxo seguir e não ser possível se conectar no banco quando for necessário por conta do PostgreSQL não estar pronto.

steps:
    - name: Checkout code
      uses: actions/checkout@v1

    - name: Setup Ruby
      uses: ruby/setup-ruby@v1
      with:
        bundler-cache: true

    - name: Install postgres client dependencies
      run: sudo apt-get install libpq-dev

Os dois primeiros passos são idênticos ao dois primeiros do fluxo de análise de código, então volta lá na seção anterior caso tenha esquecido do que se trata. No terceiro, é instalado uma dependência de desenvolvimento do PostgreSQL, que é necessária para rodar os comando de banco de dados.

  - name: Setup Node
    uses: actions/setup-node@v1
    with:
      node-version: 12.20.0

  - name: Yarn package cache
    uses: actions/cache@v2
    with:
      path: ./node_modules
      key: ${{ runner.os }}-yarn-v1-${{ hashFiles('./yarn.lock') }}

  - name: Install Yarn packages
    run: yarn install --pure-lockfile

Para projetos que utilizam o Webpacker às vezes é necessário instalar as dependências de front-end para que os testes sejam executados. No primeiro passo está sendo instalado o Node 12.20, no passo seguinte é utilizado o actions/cache que serve tanto para recuperar um cache quanto, se for necessário, para criar um novo cache no final do fluxo. A pasta que está sendo armazenada para ser reaproveitada nas execuções seguintes é a node_modules que geralmente fica na raíz do projeto, e será o conteúdo do yarn.lock que o github saberá se será necessário instalar dependências ou apenas reutilizar a node_modules existente. E no fim o yarn install é utilizado para fazer essa instalação dos pacotes, com a opção —pure-lockfile para que não seja gerado um yarn.lock novo.

- name: Create database
  run: |
    bundle exec rails db:create
    # Se o projeto usar `schema.rb`
    bundle exec rails db:schema:load
    # Se o projeto usar `structure.sql`
    bundle exec rails db:structure:load
    # Se o projeto não usar nenhum dos dois
    bundle exec rails db:migrate

- name: Run tests
  run: bundle exec rspec spec

Por fim, no "Create database", o banco de testes é criado e a sua estrutura é montada a partir do schema.rb ou structure.sql e, caso esses arquivos não existam, as migrações serão executadas. Uma outra opção que substitui esse trecho da criação do banco de dados e sua estrutura é utilizar o comando rails db:test:prepare.
Após o banco de dados pronto, a execução dos testes é realizada com o bundle exec rspec spec e esse é o ponto final do fluxo.

Conclusão

Agora com tudo configurado, todo push que for feito ao projeto dispará uma execução do CI no Github Actions, que pode ser acompanhada na aba "Actions" dentro do projeto no Github, e após o fim da execução, será adicionado um "check" verdinho ou um "x" vermelho ao lado do commit, e dentro do pull request para indicar o resultado da execução.

Para projetos de código aberto, o Github Actions é gratuito, já para projetos privados de usuários não pagantes, são disponibilizados 2.000 minutos de execução mensalmente. Não há desculpa para não ter CI no projeto.

TL;DR

name: CI
on: push
jobs:
  rubocop:
    name: Rubocop
    runs-on: ubuntu-20.04
    steps:
      - name: Checkout code
        uses: actions/checkout@v1

      - name: Setup Ruby
        uses: ruby/setup-ruby@v1
        with:
          bundler-cache: true

      - name: Analyze code
        run: bundle exec rubocop

  rspec:
    name: RSpec
    needs: rubocop
    runs-on: ubuntu-20.04
    env:
      RAILS_ENV: test
      DATABASE_URL: postgres://postgres:example@localhost:5432/db_test
    services:
      postgres:
        image: postgres:latest
        ports: ['5432:5432']
        env:
          POSTGRES_DB: db_test
          POSTGRES_USER: postgres
          POSTGRES_PASSWORD: example
        options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5
    steps:
      - name: Checkout code
        uses: actions/checkout@v1

      - name: Setup Ruby
        uses: ruby/setup-ruby@v1
        with:
          bundler-cache: true

      - name: Install postgres client dependencies
        run: sudo apt-get install libpq-dev

      - name: Setup Node
        uses: actions/setup-node@v1
        with:
          node-version: 12.20.0

      - name: Yarn package cache
        uses: actions/cache@v2
        with:
          path: ./node_modules
          key: ${{ runner.os }}-yarn-v1-${{ hashFiles('./yarn.lock') }}

      - name: Install Yarn packages
        run: yarn install --pure-lockfile

      - name: Create database
        run: |
          bundle exec rails db:create
          # Se o projeto usar `schema.rb`
          bundle exec rails db:schema:load
          # Se o projeto usar `structure.sql`
          bundle exec rails db:structure:load
          # Se o projeto não usar nenhum dos dois
          bundle exec rails db:migrate

    - name: Run tests
      run: bundle exec rspec spec

Fazendo deploy em produção com Rails, PostgreSQL e Dokku

Stephann — Thu, 24 Mar 2022 01:03:06 +0000

Introdução

Disponibilizar uma aplicação na internet para outras pessoas acessarem é uma tarefa razoavelmente simples caso utilizemos o Heroku como PaaS (Plataforma como Serviço), mas se torna uma tarefa um pouco mais complicada quando, querendo baixar custos, passamos a utilizar uma instância na DigitalOcean, Linode, Vultr e etc, e é necessário configurar tudo manualmente, principalmente pra mim, que assunto de infraestrutura eu sou quase um leigo. Mas ainda há esperança para desenvolvedores como eu, que da nomeclatura DevOps, tem só o Dev, e nada de Ops. Eu falo do Dokku, que une a facilitade do Heroku com os baixos custos de uma instância própria. Ele é uma ferramenta de código aberto e gratuita, que resumidamente é um "self-hosted Heroku", um PaaS que tu hospeda no teu próprio servidor, te proporcionando uma maior capacidade de customização e uma redução dos custos.

A seguir vou mostrar como instalar o Dokku numa instância da DigitalOcean (mas tu consegue reproduzir usando o serviço de tua preferência), e implantar uma aplicação real desenvolvida com Ruby on Rails e PostgreSQL. Caso tu não tenha uma aplicação pra seguir o tutorial, pode usar essa aplicação MVP que desenvolvi e que é uma mini-rede social para publicação de customizações do jogo Animal Crossing: New Horizons, jogo do Nintendo Switch lançado em março de 2020. O código está disponível nesse repositório. Use o branch tutorial pois ele já está com alguns ajustes pra facilitar a configuração:

stephannv / customdesigns

An application to share and discover Animal Crossing: New Horizons custom designs.

README

This README would normally document whatever steps are necessary to get the application up and running.

Things you may want to cover:

Ruby version
System dependencies
Configuration
Database creation
Database initialization
How to run the test suite
Services (job queues, cache servers, search engines, etc.)
Deployment instructions
...

View on GitHub

Instalando o Dokku

Antes de tudo é necessário criar uma conta na DigitalOcean, e criar uma instância, termo usado pela DO para se referir às instâncias é droplets, então crie um droplet. Não vai ter imagens desse processo nesse artigo pois a qualquer momento a DigitalOcean pode mudar toda a página e o artigo ficar desatualizado, mas não tem segredo, é só um formulário simples onde tu escolhe as configurações e finaliza o criação da instância. Uma máquina de 2GB de RAM é mais do que suficiente, mas já consegui configurar até usando a de 1GB de RAM.
Após a instância criada, é necessário se conectar nela utilizando o usuário root:

ssh root@IP_DO_TEU_SERVIDOR

Esse IP_DO_TEU_SERVIDOR se refere ao IP que a DigitalOcean forneceu após a criação do droplet. Caso já tenha configurado um domínio para essa instância, tu pode usar o domínio ao invés do IP.

Agora instale o Dokku com o seguinte comando

# Para sistemas debian, instale o dokku via apt-get
wget https://raw.githubusercontent.com/dokku/dokku/v0.27.0/bootstrap.sh
sudo DOKKU_TAG=v0.27.0 bash bootstrap.sh

A versão 0.27.0 é a mais recente disponível enquanto eu escrevo esse artigo, então confira a documentação oficial no site para verificar se novas versões foram publicadas.

Quando a instalação terminar, visite IP da tua máquina pelo navegador, preencha a chave pública do teu SSH no campo "Public SSH", pois isso te permitirá executar os comandos remotamente que vamos precisar mais pra frente. A sessão de configuração de hostname pode ser ignorada, vamos configurar isso já já. Finalize a instalação e tu estará pronto para começar a configuração da aplicação.

Configurando a aplicação

Com o Dokku já instalado, é hora de criar a aplicação. Ainda conectado como root na tua instância, execute:

dokku apps:create meu_app

O meu_app é o identificador da tua aplicação, substitua pelo nome do teu projeto, é ele que tu irá se referenciar no restante da configuração.

Uma coisa legal do Dokku é que ele é compátivel com os buildpacks que são utilizados no Heroku, que são conjuntos de scripts que configuram automaticamente várias dependências da aplicação, sem precisar fazer esse processo de forma manual. Então adicione o buildpack do Ruby para seguirmos a configuração:

dokku buildpacks:add meu_app \
  https://github.com/heroku/heroku-buildpack-ruby.git

Para entender mais sobre os buildpacks: https://devcenter.heroku.com/articles/buildpacks

Caso esteja usando as credentials do Rails, tu precisa informar a master.key para que a aplicação possa descriptografar as credenciais:

dokku config:set meu_app RAILS_MASTER_KEY=tua_chave_mestra

Também configure a variável RAILS_ENV para ser production:

dokku config:set meu_app RAILS_ENV=production

Com esse comando dokku config:set, tu pode definir outras variáveis de ambiente também, caso sejam necessárias.

Como o Heroku, o Dokku também permite que um projeto tenha um arquivo Procfile. Esse arquivo serve para definir os processos que serão executados na inicialização da aplicação. Dois deles são especiais, o web e o release. O web é o único processo que pode receber as requisições externas roteadas pelo Dokku, e o release é o comando executado antes de finalizar a implantação da aplicação.

Tu pode ter outros processos e nomeá-los como quiser, por exemplo: depois de configurar um sidekiq na tua aplicação e no Dokku, será necessário colocar um meus_workers: bundle exec sidekiq -C config/sidekiq.yml no Procfile.

Para o escopo do artigo, precisa apenas do web para subir o servidor com o Puma e do release para executar as migrações e criar os seeds, então crie um arquivo Procfile na raíz do teu projeto com o seguinte conteúdo:

web: bundle exec puma -C config/puma.rb
release: bundle exec rails db:migrate db:seed

Para entender mais sobre o Procfile: https://devcenter.heroku.com/articles/procfile

A partir do Rails 6, por questão de segurança, é necessário informar os domínios permitidos no header das requisições, então no config/environments/production.rb informe o IP do teu servidor, teu domínio ou desabilite essa verificação. As opções são essas:

config.hosts << "IP_DO_TEU_SERVIDOR"
# ou
config.hosts << "meudominio.com"
# ou caso queira desabilitar a verificação
config.hosts.clear

Envie as duas mudanças (do Procfile e do production.rb) para o teu repositório e vamos seguir para instalar o PostgreSQL.

Instalando o PostgreSQL

Para instalar o PostgreSQL da maneira mais fácil, pode usar os plugins do Dokku:

dokku plugin:install \
  https://github.com/dokku/dokku-postgres.git

Após isso, crie o banco de dados que será usado na aplicação:

dokku postgres:create meu_app_db

Observação: A versão do postgres instalada pode não ser a que você deseja, então você pode passar uma flag com uma versão específica: dokku postgres:create meu_app_db -I 14.1.

Faça a conexão entre o banco de dados recém-criado e a aplicação com o seguinte comando:

dokku postgres:link meu_app_db meu_app

Esse comando configura uma variável de ambiente chamada DATABASE_URL e ela será usada pela aplicação Rails para se conectar com o banco de dados. Uma informação extra: caso por algum motivo tu necessite que o banco seja acessado externamente, esse comando irá expor uma porta aleatória:

dokku postgres:expose meu_app_db

Configurando o domínio

Esse passo é opcional, caso tu tenha um domínio configurado apontando pro teu servidor e queira que ele se integre com a aplicação, tu precisa adicioná-lo ao meu_app:

dokku domains:add meu_app meudominio.com

# Caso queira o subdomínio www configurado:
dokku domains:add meu_app www.meudominio.com

Lembre-se da configuração que expliquei antes, sobre o config.hosts, que é necessário adicionar o meudominio.com no config.hosts para conseguir navegar na aplicação utilizando o teu domínio.

Fazendo o deploy

Agora falta pouco para finalizar a implantação da aplicação. Na tua máquina local, na pasta do teu projeto, adicione o repositório remoto apontando para o Dokku do teu servidor com seguinte comando:

git remote add dokku dokku@IP_DO_TEU_SERVIDOR:meu_app
# ou
git remote add dokku dokku@meudominio.com:meu_app

Para finalmente fazer o deploy agora ou toda vez que tu quiser mandar atualizações da aplicação, ainda na pasta do teu projeto execute:

git push dokku main # ou qualquer outro branch que desejar colocar no ar

Esse comando vai demorar um pouco, pois ele irá fazer todo o processo de instalar o Ruby de acordo com o buildpack adicionado lá no início do artigo, vai instalar as gems, instalar as dependências de front-end caso existam, precompilar os assets, rodar os comandos pré e pós deploy e por fim reiniciar o nginx.

Agora tu pode acessar o http://IP_DO_TEU_SERVIDOR ou http://meudominio.com pelo navegador e se nada inesperado ocorrer, tua aplicação estará no ar, pronta para uso. Mas o ideal é que tua aplicação tenha SSL para dar mais segurança aos teus usuários, principalmente se tiver funcionalidade de autenticação ou se tratar dados mais sensíveis. Na próxima seção explico como configurar o SSL.

Adicionando o SSL

Caso tu já tenha configurado um domínio pra tua aplicação (caso contrário leia como fazer em Configurando o domínio) e queira configurar o SSL, primeiro instale o plugin do Let's Encrypt:

dokku plugin:install \
  https://github.com/dokku/dokku-letsencrypt.git

Também é necessário configurar o teu e-mail para registro no Let's Encrypt, assim tu receberá notificações do teu certificado:

 dokku config:set --no-restart meu_app \
   DOKKU_LETSENCRYPT_EMAIL=teu@email.aqui

Pra finalizar a configuração de fato o SSL, é só executar o comando letsencrypt e que ele fará todo o trabalho por baixo dos panos de gerar os certificados para cada um dos domínios adicionados:

dokku letsencrypt:enable meu_app

E para ativar a renovação automática de 3 em 3 meses é com o seguinte comando:

dokku letsencrypt:cron-job --add meu_app

Pronto, se tudo tiver dado certo, se tu acessar https://meudominio.com, o navegador deverá mostrar na barra de navegação um cadeado sem nenhum erro ou alerta.

Conclusão

É isso, pode parecer complicado, mas é bem mais fácil que configurar uma máquina "crua" na mão. Com esse conceito de apps, fica fácil adicionar mais aplicações em um mesmo servidor, configurando um subdomínio para cada uma, até mesmo com tecnologias diferentes, pois o Dokku não é apenas para Ruby. É possível usar um Dockerfile ou uma imagem Docker no lugar dos buildpacks para ter uma configuração de ambiente mais customizada. Ele é uma ótima opção para MVPs ou aplicações com um baixo número de usuários, ou até para usar como ambiente de homologação (sandbox, QA).

Caso tenha ficado interessado no Dokku, saiba que há outras alternativas de PaaS self-hosted para tu analisar os pontos fortes e fracos de cada um e escolher o que melhor se adequa para tuas necessidades. Numa pesquisa rápida consigo listar o Flynn, o CapRover, o Convox e o brasileiro Tsuru, mas com uma pesquisa mais aprofundada tu pode encontrar mais opções.

Se tu já tiver usado o Dokku ou qualquer outra opção parecida, deixa nos comentários como foi a experiência, os pontos positivos e negativos, e alguma dica de configuração, caso tenha. Até o próximo artigo.

TL;DR

# Entre na instância
ssh root@IP_DO_TEU_SERVIDOR

# Instale o Dokku. Confira a última versão no site oficial.
wget https://raw.githubusercontent.com/dokku/dokku/v0.27.0/bootstrap.sh
DOKKU_TAG=v0.23.4 bash bootstrap.sh

# Visite o IP_DO_TEU_SERVIDOR pelo navegador, adicione 
# tua chave SSH, ignore as confgurações de hostname 
# e finalize a instalação.

# Ainda conectado via SSH no servidor, crie um app no Dokku
dokku apps:create meu_app

# Adicione o buildpack do Ruby
dokku buildpacks:add meu_app \ 
  https://github.com/heroku/heroku-buildpack-ruby.git

# Configure a variável RAILS_ENV para production
dokku config:set meu_app RAILS_ENV=production

# Caso use as credentials, informe a master.key
dooku config:set meu_app RAILS_MASTER_KEY=tua_senha

# Instale o PostgreSQL
dokku plugin:install \
  https://github.com/dokku/dokku-postgres.git

# Crie um banco de dados
dokku postgres:create meu_app_db

# Conecte o banco de dados com tua aplicação
dokku postgres:link meu_app_db meu_app

# Caso tenha um domínio configurado no servidor:
dokku domains:add meu_app meudominio.com

# Caso queira o subdomínio www configurado:
dokku domains:add meu_app www.meudominio.com

# No código do teu projeto, lembre-se de informar
# o host que tua aplicação irá rodar.
# No arquivo /config/environments/production.rb
config.hosts << "IP_DO_TEU_SERVIDOR"

# Ou
config.hosts << "meudominio.com"

# Ou caso queira desabilitar a verificação
config.hosts.clear


# Na tua máquina local, aponte para o repositório
# remoto do Dokku do teu servidor:
git remote add dokku dokku@IP_DO_TEU_SERVIDOR:meu_app

# Faça o deploy
git push dokku main 

# Acesse http://IP_DO_TEU_SERVIDOR ou
# http://meudominio.com e a aplicação estará no ar.

# Caso queira adicionar SSL na aplicação, instale 
# o letsencrypt
dokku plugin:install \ 
  https://github.com/dokku/dokku-letsencrypt.git

# Configure o e-mail para receber alertas do
# Let's Encrypt:
dokku config:set --no-restart meu_app \
  DOKKU_LETSENCRYPT_EMAIL=teu_email

# Crie os certificados para os domínios da aplicação
dokku letsencrypt meu_app

# Configure a renovação automática
dokku letsencrypt:cron-job --add meu_app

# Acesse https://IP_DO_TEU_SERVIDOR ou
# https://meudominio.com e a aplicação estará no ar
# com SSL

Utilizando o padrão interactor no Ruby on Rails

Stephann — Sun, 20 Mar 2022 23:36:54 +0000

Introdução

Um problema que é comum e que todo desenvolvedor Rails já se deparou, é ver a qualidade da base de código se deteriorar conforme as regras de negócio vão aumentando e ficando mais complexas. Numa equipe ainda sem muita experiência, é quase certo que vão aparecer na aplicação os famosos fat controllers. Os controllers gordos são comuns e eles nada mais são que aqueles controllers cheios de responsabilidades e comportamentos que deveriam estar em outras camadas. Depois que o desenvolvedor aprende na prática e entende que fat controllers são prejudiciais, ele tende a começar a escrever quase toda lógica de negócio nos modelos, e que o leva aos fat models. O problema dos modelos gordos é o mesmo, é uma classe com vários comportamentos centralizados e que deveriam estar distribuídos de uma melhor forma. Com a ideia de ajudar a fugir dos modelos e controllers mais gordinhos, os concerns foram introduzidos no Rails. Eles são módulos que permitem definir comportamentos em um arquivo separado e que podem ser incluídos em outras classes. Mas enquanto os concerns ajudam a escrever modelos e controllers menores em quantidade de linhas, não resolvem o problema deles estarem estarem inchados de comportamentos.

Aí o desenvolvedor se questiona: "Então se fat controllers são ruins e fat models também, onde vou colocar meu código? Na camada de view? Ou devo abandonar a profissão de desenvolvedor e vender minha arte na praia?". Nenhuma das duas opções. Há alguns padrões de design que ajudam a organizar seu código sem entupir uma classe de métodos e responsabilidades, tipo os Form Objects, Service Objects, Query Objects, Clients, Interactors e etc. Nesse artigo vou apresentar alguns conceitos dos interactors, mostrar algumas gems que já testei e exemplificar o uso do padrão com situações quase reais.

Conceito

Primeiro quero deixar claro que não há um consenso exato na comunidade sobre o que é um interactor. Você vai encontrar uma galera na internet usando os termos service objects, operations, use-cases, mutations, commands ao se referir a um mesmo conceito, já outro desenvolvedor saberá dizer a diferença entre cada um, a outra irá discordar e explicará de outra maneira, mas de forma geral, estarão falando sobre as mesmas coisas ou pelo menos sobre soluções bem parecidas. O fato é que um interactor nada mais é do que um objeto simples, com um propósito único, que encapsula sua regra de negócio e representa uma funcionalidade da sua aplicação. Explicando com um exemplo: Sua aplicação é uma newsletter e você deve enviar um e-mail para todos os assinantes toda vez que um artigo novo for criado e ele não estiver marcado como rascunho. Uma das soluções é fazer isso no controller:

# app/controllers/articles_controllers.rb 
class ArticlesController < ApplicationController 
  def create 
    @article = Article.new(post_params) 

    if @article.save 
      unless @article.draft? 
        Member.where(subscribed: true).each do |member| 
          SendMailJob.perform_async(member.id, @article.id) 
        end 
      end 

      redirect_to @article, notice: 'Success!' 
    else 
      render :new 
    end 
  end 
end

A outra opção é tirar isso do controller e jogar a lógica para o modelo:

# app/models/article.rb 
class Article < ApplicationRecord 
  after_create :send_mail_to_members, unless: :draft? 

  def send_mail_to_members 
    Member.where(subscribed: true).each do |member| 
      SendMailJob.perform_async(member.id, self.id) 
    end 
  end 
end

Se tua intenção é evitar código acoplado e a duplicação de código, as duas soluções acima não te ajudam nesses pontos. Além de atribuir responsabilidades que fogem do escopo dessas classes, colocar o comportamento no controller torna mais difícil a reutilização em outros locais da aplicação e colocar num callback do ActiveRecord, você enterra esse comportamento num funcionamento interno da classe, dificultando a manutenção, a implementação de testes e causando surpresas para quem for usar aquela classe um dia e descobrir que acabou enviando alguns milhares de e-mails só porque salvou um artigo na tabela.

Para ajudar resolver esses problemas, o interactor entra em cena e essa situação seria resolvida da seguinte forma:

Uma observação antes de mostrar o código: Vou usar nos exemplos a gem interactor, mas mais adiante no texto apresento outras opções, inclusive uma que eu estou utilizado nos projetos e estou gostando bastante.

# app/interactors/create_article.rb 
class CreateArticle 
  include Interactor 

  def call 
    context.article = Article.new(context.params) 

    if context.article.save
      unless context.article.draft? 
        Member.where(subscribed: true).each do |member| 
          SendMailJob.perform_async(member.id, article.id) 
        end 
      end 
    else 
      context.fail! unless context.article.valid? 
    end 
  end 
end 

# app/controllers/articles_controller.rb 
class ArticlesController < ApplicationController 
  def create 
    result = CreateArticle.call(params: article_params) 

    if result.success? 
      redirect_to result.article, notice: 'Success!' 
    else
      @article = result.article 
      render :new 
    end 
  end 
end

Dessa forma o controller não precisa mais saber sobre a regra de negócio, o papel dele é receber a requisição, delegar o processamento dos dados e depois cuidar de devolver uma resposta. E você também não sujou o modelo com callbacks.

Vale a pena notar que diferente do que aprendemos nas cadeiras Orientação a Objeto, a classe CreateArticle não representa a abstração de um objeto com propriedades, métodos, com herança, polimorfismo e etc, mas sim uma ação, como o próprio nome já representa: CriarArtigo. Quase como que voltando para a programação estrutural mas em uma escala de caso de uso. O mesmo esquema poderia ser utilizado para outras coisas como FinalizarPedido, ProcessarWebhook, ImportarArquivos e etc. Onde toda a lógica de verificar estoque pra confirmar pedido, verificar a assinatura do webhook, ler, transformar e importar dados de arquivos ficariam em interactors, e não mais em modelos ou controllers.

Organizando os interactors

Não é porque agora você colocou interactors na aplicação que tudo vai ficar mil maravilhas e nada de ruim vai acontecer. Também corre o risco de ter interactors gigantes, com códigos repetidos, fazendo mais coisas do que deveriam. Por isso há um conceito de orquestradores (também chamados de organizadores) no padrão interactor, que são basicamente interactors que executam outros interactors. Vou trazer um novo exemplo pra ficar claro os benefícios desses orquestradores: Minha aplicação precisa importar e processar os arquivos de retorno bancário da FEBRABAN para saber se os boletos que minha aplicação emitiu foram pagos ou não. O passo a passo desse processo é o seguinte: Pegar os arquivos no FTP, transformar os dados arquivos em objetos ruby, e processar esses arquivos atualizando os boletos e pedidos do sistema. Utilizando apenas um interactor seria mais ou menos assim:

# app/interactors/import_bank_files.rb 
class ImportBankFiles 
  include Interactor 

  def call 
    # abre conexão com FTP 
    ftp_client = ... 
    ftp_connection = ftp_client.connect(...) 

    # pega arquivos 
    bank_files = ftp_connection.ls...

    # lê arquivos txt e transforma em objetos ruby 
    parsed_bank_files = bank_files.map { ... } 

    # processa arquivos 
    parsed_bank_files.each do |bank_file| 
      boleto = Boleto.find_by(identifier: bank_file.identifier) 

      if boleto.nil? 
        Sentry.capture_message("not found: #{bank_file.identifier}") 
        next 
      else
        if bank_file.code == '09' # SETTLE BOLETO 
          unless boleto.settled? 
            boleto.update(paid_at: ...) 
            boleto.order.update(status: ...) 
            PaymentReceivedMailer.send(boleto.payer) 
          end 
        elsif bank_file_code ... 
          ... 
        end 
      end 
    end 
  end 
end 

# Em algum outro lugar para executar a importação 
ImportBankFiles.call

Abstraí bem os detalhes da implementação porque não é a intenção mostrar como processar arquivos de retorno bancário, e sim exemplificar um processo mais complexo. Esse código poderia estar pior e estaria se estivesse, por exemplo, num controller ou num modelo, mas temos como melhorar dividindo as responsabilidades em interactors menores e chamando tudo junto com um orquestrador. Primeiro destrinchando o comportamento em múltiplos interactors:

# app/interactors/fetch_bank_files_from_ftp.rb 
class FetchBankFilesFromFTP 
  include Interactor 

  def call 
    # abre conexão com FTP 
    ftp_client = ... 
    ftp_connection = ftp_client.connect(...) 

    # pega arquivos e coloca no contexto 
    context.bank_files = ftp_connection.ls... 
  end 
end 

# app/interactors/parse_bank_files.rb 
class ParseBankFiles 
  include Interactor 

  def call 
    context.parsed_bank_files = context.bank_files.map do |bf| 
      # transforma os arquivos txt em objetos ruby
      ... 
    end 
  end 
end 

# app/interactors/import_parsed_bank_files.rb 
class ImportParsedBankFiles 
  include Interactor 

  def call 
    context.parsed_bank_files.each do |parsed_bank_file| 
      ... # quita os boletos, atualiza os pedidos e etc. 
    end 
  end 
end

Atenção nos dados sendo compartilhados via contexto para outros interactors poderem acessá-los. Agora junta tudo com um orquestrador:

# app/organizers/import_bank_files.rb 
class ImportBankFiles 
  include Interactor::Organizer 

  organize FetchBankFilesFromFTP, 
    ParseBankFiles, 
    ImportParsedBankFiles 
  end 
end

# Usando o orquestrador em algum lugar da aplicação 
ImportBankfiles.call

Dividir os interactors dessa forma traz algumas vantagens: Deixa o código mais manutenível, facilita a implementação dos testes e ainda torna o código reutilizável. Vamos supor que agora a aplicação precisa permitir o recebimento de arquivos bancários por um formulário para caso o FTP esteja com problema. Você criaria mais um orquestrador chamado de UploadBankFiles, e você conseguiria reutilizar pelo menos o ParseBankFiles e o ImportParsedBankFiles no fluxo de recebimento desses arquivos.

Gems disponíveis

Implementar o padrão interactor não é tão complicado. É basicamente um PORO com um método público chamado #call (ou #run, ou #execute ou qualquer coisa que você preferir). Depois você pode ir incrementando sua própria implementação do padrão, adicionando mensagens, tratamento de erros, contextos, rollbacks, orquestradores e assim por diante. Mas o que não falta são gems pra você adicionar no projeto e já começar a escrever interactors agora. Vou colocar a seguir uma lista com as gems que eu pelo menos li a documentação, e as que eu já usei em algum projeto eu vou deixar alguns breves comentários.

collectiveidea/interactor:

Essa foi a primeira que usei. Gosto dela pela simplicidade e tem uma boa API permitindo mais flexibidade mas não fornece uma opção de declarar os parâmetros de entrada e saída de um interactor.

collectiveidea / interactor

Interactor provides a common interface for performing complex user interactions.

Interactor

Getting Started

Add Interactor to your Gemfile and bundle install.

gem "interactor", "~> 3.0"

What is an Interactor?

An interactor is a simple, single-purpose object.

Interactors are used to encapsulate your application's business logic. Each interactor represents one thing that your application does.

Context

An interactor is given a context. The context contains everything the interactor needs to do its work.

When an interactor does its single purpose, it affects its given context.

Adding to the Context

As an interactor runs it can add information to the context.

context.user = user

Failing the Context

When something goes wrong in your interactor, you can flag the context as failed.

context.fail!

When given a hash argument, the fail! method can also update the context. The following are equivalent:

context.error = "Boom!"
context.fail!

context.fail!(error:

…

View on GitHub

adomokos/light-service:

O diferencial da light-service é que ela tem uma API mais avançada para os orquestradores, mais opções para o controle de fluxo e também permite uma declarar os parâmetros de entrada e os resultados gerados pelo interactor.

adomokos / light-service

Series of Actions with an emphasis on simplicity.

LightService is a powerful and flexible service skeleton framework with an emphasis on simplicity

Why LightService?

What do you think of this code?

class TaxController < ApplicationController
  def update
    @order = Order.find(params[:id])
    tax_ranges = TaxRange.for_region(order.region)
    if tax_ranges.nil?
      render :action =>

…

View on GitHub

sunny/actor:

Essa é a minha preferida. Estou usando ela em todos os meus projetos. Ela não tem um orquestrador tão versátil quanto os da light-service, mas o que tem lá me serve bem, e a definição de parâmetros ajuda bastante pois tem como definir algumas opções, como tipos e valores padrões.

sunny / actor

Composable Ruby service objects

ServiceActor

This Ruby gem lets you move your application logic into into small composable service objects. It is a lightweight framework that helps you keep your models and controllers thin.

Installation

Add the gem to your application’s Gemfile by executing:

bundle add service_actor

Extensions

For Rails generators, you can use the service_actor-rails gem:

bundle add service_actor-rails

For TTY prompts, you can use the service_actor-promptable gem:

bundle add service_actor-promptable

Usage

Actors are single-purpose actions in your application that represent your business logic. They start with a verb, inherit from Actor and implement a call method.

# app/actors/send_notification.rb
class SendNotification < Actor
  def call
    # …
  end
end

Trigger them in your application with .call:

SendNotification

…

View on GitHub

cypriss/mutations:

Usei essa em alguns projetos, mas a falta de orquestradores, a dificuldade de encadear chamadas e a definição de parâmetros de entrada e a burocracia de uso deles me afastaram.

cypriss / mutations

Compose your business logic into commands that sanitize and validate input.

Mutations

Compose your business logic into commands that sanitize and validate input. Write safe, reusable, and maintainable code for Ruby and Rails apps.

Installation

gem install mutations

Or add it to your Gemfile:

gem 'mutations'

Example

# Define a command that signs up a user.
class UserSignup < Mutations::Command
  # These inputs are required
  required do
    string :email, matches: EMAIL_REGEX
    string :name
  end

  # These inputs are optional
  optional do
    boolean :newsletter_subscribe
  end

  # The execute method is called only if the inputs validate. It does your business action.
  def execute
    user = User.create!(inputs)
    NewsletterSubscriptions.create(email: email, user_id: user.id) if newsletter_subscribe
    UserMailer.async(:deliver_welcome, user.id)
    user
  end
end

# In a controller action (for instance), you can run it:
def create
  outcome = UserSignup.run

…

View on GitHub

hanami/hanami:

Hanami não é uma gem de interactor e sim um framework web completo, como o Rails é. Mas ele traz internamente já uma solução do padrão para uso opcional por quem preferir seguir essa estratégia. Kudos para o pessoal do Hanami.

hanami / hanami

The web, with simplicity.

Hanami 🌸

The web, with simplicity.

Version

This branch contains the code for hanami 2.0.x.

Frameworks

Hanami is a full-stack Ruby web framework. It's made up of smaller, single-purpose libraries.

This repository is for the full-stack framework, which provides the glue that ties all the parts together:

Hanami::Router - Rack compatible HTTP router for Ruby
Hanami::Controller - Full featured, fast and testable actions for Rack
Hanami::View - Presentation with a separation between views and templates
Hanami::Helpers - View helpers for Ruby applications
Hanami::Mailer - Mail for Ruby applications
Hanami::Assets - Assets management for Ruby

These components are designed to be used independently or together in a Hanami application.

Status

Installation

Hanami supports Ruby (MRI) 3.0+

gem install hanami

Usage

hanami new bookshelf
cd bookshelf && bundle
bundle exec hanami server # visit http://localhost:2300

Please follow along with the Getting Started guide.

Donations

You can give back to Open Source…

View on GitHub

Outras

A seguir coloquei as que eu já li as documentações, considerei uso, mas por um ou outro motivo não decidi testar em algum projeto:

Freshly / flow

Write modular and reusable business logic that's understandable and maintainable.

Flow

Installation

Add this line to your application's Gemfile:

gem "flow"

Then, in your project directory:

$ bundle install
$ rails generate flow:install

What is Flow?

Flow is a SOLID implementation of the Command Pattern for Ruby on Rails.

Flows allow you to encapsulate your application's business logic into a set of extensible and reusable objects.

Quickstart Example

Install Flow to your Rails project:

$ rails generate flow:install

Then define State, Operation(s), and Flow objects.

State

A State object defines data that is to be read or written in Operation objects throughout the Flow. There are several types of data that can be defined, such as argument, option, and output.

$ rails generate flow:state Charge

# app/states/charge_state.rb
class ChargeState < ApplicationState
  # @!attribute [r]
  # Order hash, readonly, required
  argument :order
  # @!attribute [r]
  # User model instance readonly, required
  argument :user

  # @!attribute

…

View on GitHub

serradura / u-case

Represent use cases in a simple and powerful way while writing modular, expressive and sequentially logical code.

Represent use cases in a simple and powerful way while writing modular, expressive and sequentially logical code.

The main project goals are:

Easy to use and easy to learn (input >> process >> output).
Promote immutability (transforming data instead of modifying it) and data integrity.
No callbacks (ex: before, after, around) to avoid code indirections that could compromise the state and understanding of application flows.
Solve complex business logic, by allowing the composition of use cases (flow creation).
Be fast and optimized (Check out the benchmarks section).

Note: Check out the repo https://github.com/serradura/from-fat-controllers-to-use-cases to see a Rails application that uses this gem to handle its business logic.

Documentation

Version	Documentation
unreleased	https://github.com/serradura/u-case/blob/main/README.md
4.5.1	https://github.com/serradura/u-case/blob/v4.x/README.md
3.1.0	https://github.com/serradura/u-case/blob/v3.x/README.md
2.6.0	https://github.com/serradura/u-case/blob/v2.x/README.md
1.1.0	https://github.com/serradura/u-case/blob/v1.x/README.md

Note: Você entende português? 🇧🇷 🇵🇹 Verifique o README traduzido em pt-BR.

View on GitHub

apneadiving / waterfall

A slice of functional programming to chain ruby services and blocks, thus providing a new approach to flow control. Make them flow!

Goal

Chain ruby commands, and treat them like a flow, which provides a new approach to application control flow.

When logic is complicated, waterfalls show their true power and let you write intention revealing code. Above all they excel at chaining services.

Material

Upcoming book about failure management patterns, leveraging the gem: The Unhappy path

General presentation blog post there: Chain services objects like a boss.

Reach me @apneadiving

Overview

A waterfall object has its own flow of commands, you can chain your commands and if something wrong happens, you dam the flow which bypasses the rest of the commands.

Here is a basic representation:

green, the flow goes on, chain by chain
red its bypassed and only on_dam blocks are executed.

Example

class FetchUser
  include Waterfall
  def initialize(user_id)
    @user_id = user_id
  end
  def call
    chain { @response = HTTParty.get("https://jsonplaceholder.typicode.com/users/#{@user_id

…

View on GitHub

pabloh / pathway

Define your business logic in simple steps

Pathway

Pathway encapsulates your business logic into simple operation objects (AKA application services on the DDD lingo).

Installation

$ gem install pathway

Description

Pathway helps you separate your business logic from the rest of your application; regardless of is an HTTP backend, a background processing daemon, etc The main concept Pathway relies upon to build domain logic modules is the operation, this important concept will be explained in detail in the following sections.

Pathway also aims to be easy to use, stay lightweight and extensible (by the use of plugins), avoid unnecessary dependencies, keep the core classes clean from monkey patching and help yield an organized and uniform codebase.

Usage

Main concepts and API

As mentioned earlier the operation is an essential concept Pathway is built around. Operations not only structure your code (using steps as will be explained later) but also express meaningful business actions. Operations can be thought…

View on GitHub

Conclusão

Esse foi um resumo bem geral sobre o padrão interactor, com mais exemplos práticos do que teorias propriamente ditas, mas que de toda forma ajuda a apresentar os conceitos, o uso e incentiva os desenvolvedores começarem a testar nos seus projetos pessoais ou naqueles testes técnicos para seleção de candidatos. Mas vale lembrar sempre: como tudo no desenvolvimento de software, não há bala de prata, esse padrão apresentado não vai resolver todos os problemas e nem será a melhor opção para todos os casos que aparecerem, mas vale a pena conhecer mais para enriquecer o portifólio de estratégias e soluções poderão ser útil ao desenvolvedor em algum momento da carreira.

Meu processo de atualização do Ruby on Rails

Stephann — Sat, 19 Mar 2022 23:22:58 +0000

Esse post foi escrito em janeiro de 2021 no meu blog e a atualização do Rails ocorreu entre outubro/novembro de 2020. O Ruby 2.7 e o Rails 6.1 eram as versões mais recentes na época. Mas o que está descrito nesse post se mantém válido e acho que valerá pro Rails 8, Rails 9 e assim por diante.

Introdução

No apagar das luzes de 2020, colocamos a versão do Rails 6.1.0 em produção aqui na firma. Essa informação por si só não teria uma relevância tão grande a ponto de merecer um post falando sobre, mas o fato de termos atualizado o Ruby 2.4 para a 2.7 e o Rails 4.2 para a versão 6.1, tornou o trabalho complexo e digno do compartilhamento de experiência com os demais desenvolvedores e equipes que planejam encarar o mesmo desafio e atualizar suas aplicações.

Há vários artigos falando e explicando sobre como atualizar o Rails, e o que vou relatar nesse texto será um apanhado de técnicas desses artigos que li e que funcionou pra mim, e que pode não ser necessariamente a melhor estratégia mas garanto que vai iluminar bastante o teu caminho. De toda forma, sugiro que também leia relatos de vários outros desenvolvedores caso esteja pensando em atualizar o Rails e encontre o que melhor se encaixa para o seu caso.

O que tornou tudo menos difícil

Realizar uma atualização tão drástica em uma aplicação já é uma tarefa complexa, mas nem sei dizer o quão mais complexo seria caso a gente não tivesse uma quantidade razoável de testes unitários cobrindo boa parte das funcionalidades do sistema. Ver os testes do CI passando, tudo verdinho, foi o que me fez prosseguir na aplicação com mais confiança pois eu sabia que pelo menos aquilo que foi testado ainda estava funcionando. Então fica a dica: Implementem testes e solicitem implementação de testes ao fazer revisão de código nas atividades de terceiros.

Mas primeiro...

Antes de começar a atualizar o Rails, resolvi atualizar o Ruby, pois há dependências que dependem de um Ruby mais novo, como o Rails 6 por exemplo, que pede pelo menos a versão 2.5 do Ruby.

Nós estávamos na versão 2.4, que não é tão defasada assim como uma 1.9~2.1, mas que já deixou de ser mantida e não recebe mais correções, nem de segurança. Então criei um branch separado e atualizei para a versão 2.7.1 (até então não tinha saído a versão 2.7.2 e nem a 3.0). A atualização foi simples, não precisou bulir em nada além de um remendo de macaco (monkey patch) que fiz prum teste específico passar mas que foi removido posteriormente por não ser mais necessário.

Depois de fazer um QA mais geral na plataforma com o Ruby mais novo, colocamos a atualização em produção e não houve nenhum transtorno, correu tudo tranquilo.

Organizando a bagunça do Gemfile

Não sei como é nas aplicações que vocês trabalham, mas em algumas que trabalhei, inclusive aqui na firma, o Gemfile estava bastante bagunçado, sem um padrão na organização das gems e suas versões. Então comecei organizando o Gemfile com 2 pontos em mente:

As gems serão ordenadas por nome.
As versões das gems serão travadas (nada mais de ~2 ou >= 2.1 e essas coisas).

A organização por nome foi baseada na configuração padrão do Rubocop e é por estética mesmo, e também pra tirar da mão do desenvolvedor a responsabilidade de saber em que grupinho de dependências aquela gem se encaixa ou se vai em cima ou vai em baixo. Então organizando por nome fica combinado de todo mundo seguir um mesmo estilo. A organização é mais ou menos assim:

# ⛔️ RUIM
gem 'g'
gem 'd'

gem 'a'

group :development do
 gem 'f'
 gem 'c'
end

gem 'b'

# ✅ BOM
gem 'a'
gem 'b'
gem 'd'
gem 'g'

group :development do
  gem 'c'
  gem 'f'
end

E o motivo de travar as versões das gems é porque eu não queria que uma gem fosse atualizada por tabela quando eu estivesse atualizando uma outra dependência. Eu só queria que ela fosse atualizada quando eu fosse no Gemfile e alterasse a versão dela na mão. Então o que tava assim:

gem 'carrierwave', '~> 1.0'
gem 'simple_form'

Ficou assim:

gem 'carrierwave', '1.2.3'
gem 'simple_form', '3.3.1'

Para saber quais a versões correspondentes de cada dependência eu tive que olhar no Gemfile.lock.

O trabalho começa agora

Depois do Ruby atualizado, o Gemfile organizado e as depêndencias com suas versões devidamente travadas, eu pude começar de fato a atualização do Rails. O plano era colocar o Rails na versão 6.0, mas isso mudou durante a atualização pois foi lançada a versão 6.1.0.rc1 e semanas depois, a versão 6.1.0 final.

Como estávamos na versão 4.2, resolvi atualizar incrementalmente, ou seja, não pular da 4.2 direto pra versão 6.1, e sim atualizando incrementalmente, aos poucos, primeiro pra 5.0, depois pra 5.1, pra 5.2, pra 6.0 e por fim, pra 6.1. Pra cada versão nova dessa, eu repeti um ciclo de ações até chegar na versão mais recente. As ações foram:

1. Instalar a próxima versão do Rails

Nesse passo, eu mudava o Gemfile para configurar a próxima versão do Rails. Como no primeiro ciclo eu estava na versão 4.2, então o Gemfile ficou assim: gem 'rails', '5.0.7.2'. Quando iniciei o ciclo novamente já foi pra atualizar para a 5.1.7 e assim por diante. Pra saber as versões disponíveis do Rails, eu conferi nesse link aqui do Rubygems: https://rubygems.org/gems/rails/versions.

Com a versão seguinte configurada no Gemfile, o comando bundle update simplesmente não funcionava, mostrava o erro: Bundler could not find compatible version for gem "XYZ". Eu já tinha uma experiência prévia com atualização do Rails, então sabia que isso ia me levar pra uma arapuca onde eu iria atualizar inúmeras versões de gems conforme os erros fossem aparecendo e não ia resolver o problema. Então o que funcionou pra mim foi comentar todas as gems do Gemfile, exceto o Rails, rodar o bundle update para instalar o Rails novo com sucesso, depois ir descomentando as gems de pouco em pouco e rodando o bundle install. Dessa forma apareceria erros de incompatibilidade de algumas dependências e eu teria que tratá-los.

2. Tratar as dependências incompatíveis

Quando aparecia alguma gem incompatível, a incompatibilidade era com o novo Rails ou com alguma gem que eu tinha atualizado. Pra tratar essas incompatibilidades eu seguia um esquema mais ou menos assim:

Quando a gem era sobre alguma coisa simples, eu atualizava para a versão mais recente.
Quando ela era importante e complexa, eu tentava atualizar para uma versão mais próxima que teve mudanças mais leves e que era compatível com o restante das dependências.
Caso a única saída fosse uma atualização com mudanças bruscas, o jeito era atualizar e adequar a aplicação para que funcionasse corretamente com a nova versão da gem.
Quando a gem estava abandonada, eu substituia por outra mais recente ou, quando era possível, eu implementava a solução dentro do projeto sem dependência ou fazia um fork e corrigia para ela se tornar compatível.

Resumindo, meu plano era rodar com sucesso um bundle install com o mínimo de mudanças possíveis. E eu sempre ficava de olho nas notas de lançamento e histórico de mudança das gems que eu tivesse que atualizar. Essas informações podem ser geralmente encontradas na seção de releases do Github ou em arquivos CHANGELOG.md e MIGRATION.md que existem na maioria dos projetos.

3. Adequar o código para as novas versões

Depois que o bundle install foi executado com sucesso, cuidei pra adequar o projeto às novidades da versão recém instalada do Rails. Pra isso era necessário primeiro saber o que mudou, e essas informações eu encontrei nas próprias páginas do Rails. Foi importante ler tanto as notas de lançamento quanto os guias de atualização. Nessas páginas têm certinho o que foi removido, o que foi adicionado, o que foi modificado e como as aplicações devem se comportar após a atualização. Outra coisa que foi extremamente importante pra mim foi o RailsDiff, que é basicamente um site que compara os projetos gerados por cada versão do Rails, assim eu consegui ver, por exemplo, a diferença do resultado entre um rails new example executado com o Rails 4.2 e outro executado com o Rails 5.0 e pude adequar as configurações do meu projeto.

4. Garantir que básico não está quebrando

Depois que da versão seguinte do Rails estava instalada, as dependências que necessitavam de atualização foram atualizadas, o código foi adequado de acordo com as novidades, eu tinha que testar que o básico está funcionando.

Começava com um bundle exec rails c básico, depois um bundle exec rails s e navegava em algumas telas, criava uma conta, realizava as ações principais da regra de negócio (ex.: realizar um pedido, cadastrar produto e etc) e depois eu rodava um rspec em algum arquivo de testes pra ver se os testes conseguiam ser executados. Após garantir que o básico estava funcionando, eu mandava as alterações pro nosso CI pra ver se os testes continuavam passando.

Ao realizar esses testes básicos, quase sempre apareciam alguns erros no console ou nos resultados dos testes que, às vezes, eram fáceis de corrigir com algum ajuste e às vezes apareciam erros que necessitavam de uma versão mais atualizada de uma gem pra serem corrigidos. Aí eu voltava para o segundo ponto desse ciclo para tratar as atualizações de dependências.

5. Fazer commits

Quando eu garantia que o básico estava funcionando e o testes estavam passando, eu fazia um push pro Github pra ter um backup caso as próximas atualizações não saíssem como o esperado e eu tivesse que desfazer algo. Dessa forma fica fácil saber o que pode ser descartado com segurança sem o risco de perder algo que era importante para a atualização funcionar. E no fundo também era pra caso não fosse possível atualizar pra versão mais recente do Rails, aí eu teria o código da aplicação atualizada para o Rails mais recente que eu consegui atualizar.

Assim meu branch de atualização ficou com os commits mais ou menos dessa forma:

Organizando o Gemfile
Atualizando para o Rails 5.0
Atualizando para o Rails 5.1
Atualizando para o Rails 5.2
...

Com o código devidamente guardado, eu reiniciava o ciclo para atualizar para o próxima versão, e iterei até a versão 6.1.0.

Oportunidade de contribuir pro Rails

O plano inicial era atualizar para o Rails 6.0 pois era a versão mais recente no momento, mas por sorte a 6.1 foi liberada como RC assim que eu estava finalizando a atividade. Pra não deixar o trabalho incompleto e já que eu estava com a mão na massa, a versão 6.1 entrou no escopo da tarefa e tive a oportunidade de ter contato com a nova versão no dia seguinte da publicação. E como é da natureza das versões release candidates ser mais propensas a conter falhas, foi o que acabei encontrando.

Havia uma incompatibilidade entre o web-console e a nova versão do Rails que me fez considerar ficar na 6.0 mesmo e esperar a 6.1 ficar mais estável, mas eu tava tão no gás de mexer e entender nas entranhas das gems que fui investigar o problema pra ver se eu conseguiria resolver. Acabei conseguindo e isso virou um pull request pro web-console e outro para o Rails. Já posso colocar no currículo que sou um Rails contributor.

Atualizando as demais dependências

Eu poderia ter parado na atualização do Rails, mas já que eu estava na chuva, eu ia me molhar de com força. Parti pra atualizar as demais dependências mesmo que isso não fosse necessáro pra concluir a atualização do Rails, porque da mesma forma que o Rails defasado dificulta a evolução do nosso código, outras dependências acabam fazendo o mesmo mas numa escala menor.

Minha estratégia não mudou muito da que usei pra atualizar o Rails, eu ia em cada gem, olhava no Rubygems as versões mais recentes, instalava, atualizava outras que fossem necessárias, lia os changelogs nos repositórios e adequava meu código, testava e realizava os push pro Github.

Removendo o que era desnecessário

Nesse ponto eu já estava com um conhecimento bem maior de cada dependência do projeto e do que cada uma fazia, consequentemente eu conseguia identificar o que não estava sendo necessário ou o que poderia ser substituído por outra solução. Fiz uma limpa removendo gems não mais utilizadas e trocando algumas gems por uma solução própria levando o projeto a ficar com 27 dependências externas a menos.

Pequenos ajustes

Outra coisa que não era crucial pra atualização do Rails mas que foi bom fazer foi a organização algumas coisas do projeto que não eram necessariamente relacionadas à regra de negócio, eram mais sobre factories, testes, organização de módulos e etc. O projeto foi criado em 2010, ainda na época que o Rails 3.0.0 era o mais on the edge, passou pela mão por algumas duzias de desenvolvedores nesse tempo que os padrões de organização de arquivos/código do framework ainda estavam amadurecendo. Por isso tive que fazer uma faxina em algumas coisas que estavam um pouco bagunçadas no nosso rails_helper.rb, nas factories, nos arquivos de suporte dos testes, na organização dos concerns e em outras coisas que não dessem tanto trabalho e mudassem muito a forma que o sistema se comportava.

Colocando no ar

Com mais de 1.500 arquivos modificados, a atualização foi dada como "finalizada", mas ainda assim tivemos alguns bate e volta no QA pra corrigir os problemas que surgiram após um pente fino em quase todas as funcionalidades do sistema.

Depois do QA minuncioso não detectar mais nenhum erro, colocamos a atualização em produção e, como a gente já esperava, apareceram mais uns probleminhas, mas nada muito sério, foram justamente em funcionalidades que não estavam cobertas por testes (olha aí a importância de implementar testes) e que também não tinha como ser validadas em ambiente de sandbox. Nosso coletor de erro nos auxiliou nesse momento e após alguns hotfixes podemos encher a boca pra dizer que estávamos com o Rails 6.1.0 e o Ruby 2.7.2 rodando em produção.

Conclusão

O sentimento é o mesmo de limpar a casa, fazer uma faxina pesada, comprar móveis novos e reorganizar cômodos. Mas como toda faxina, o projeto também precisa de uma limpeza frequente pra não chegar no ponto que estava. Pra isso é necessário implantar uma cultura de atualização contínua, de pagar débitos técnicos, de revisão de código, tudo para auxiliar o projeto a se manter mais atualizado e organizado possível.

Aqui ainda não está definido como vamos fazer, mas o plano é ter o Dependabot, o serviço do Github que abre pull requests com atualizações de dependências, rodando uma rotina mensal e todo mês reservar algumas horas da equipe pra implementar e testar as atualizações. Esperamos que assim a gente nunca mais tenha que estar no ar com um Rails de 6 anos atrás. Já temos o Ruby 3.0 e o Rails 6.1.1 batendo na nossa porta. Mas isso fica pra um próximo capítulo.