DEV Community: Vitor Leal

Múltiplas versões do Elixir com ASDF

Vitor Leal — Thu, 10 Jun 2021 21:04:02 +0000

ASDF

O gerenciador de versões ASDF é uma linha de comando open-source disponível no GitHub que permite instalar múltiplas versões de diversas linguagens na mesma máquina, incluindo Elixir e Erlang.

Instalando manualment

Primeiro clone o projeto do GitHub com o seguinte comando:

git clone https://github.com/asdf-vm/asdf.git ~/.asdf

Se por algum acaso você quiser desinstalar o asdf da sua maquina basta deleter a pasta ~/.asdf.

Instalando via Homebrew (apenas no Mac)

Para instalar utilizando o Homebrew basta executar o comando:

brew install asdf

Configurando a Shell

Agora que você tem a linha de comando instalada na sua maquina você deve configurar a sua shell, no caso do zsh adicione esse linha no arquivo ~/.zshrc.

. $HOME/.asdf/asdf.sh

Se você utilizar Oh My ZSH, apenas adicione o plugin asdf nas configurações de plugin:

plugins=(asdf)

Se por acaso utilizar alguma outra shell pode olhar a documentação como realizar a configuração.

Instalando os plugins

Agora que temos o asdf instalado e configurado na nossa maquina podemos instalar os plugins das linguagens que a gente quer que ele gerencie as versões, no caso deste post o Elixir e o Erlang.

asdf plugin add erlang
asdf plugin add elixir

Instalando Erlang/OTP

Para saber as verões disponíveis para instalar execute o comando:

asdf list-all erlang

23.3.4.3
24.0-rc1
24.0-rc2
24.0-rc3
24.0
24.0.1
24.0.2
...

Quando listar todas as versões disponíveis escolha a que deseja instalar e execute o comando a seguir para instalar:

asdf install erlang 23.3.4.3

Perceba que diferente de outros gerenciadores de versão o asdf precisa que você seja específico na versão que deseja instalar, ex: 23.3.4.3

Para realizar a build do Erlang você vai precisar de algumas dependências instaladas. No Linux execute o comando:

apt-get -y install build-essential autoconf m4 libncurses5-dev libwxgtk-webview3.0-gtk3-dev libwxgtk3.0-gtk3-dev libgl1-mesa-dev libglu1-mesa-dev libpng-dev libssh-dev unixodbc-dev xsltproc fop libxml2-utils libncurses-dev openjdk-11-jdk

Instalando Elixir

Depois de instalar a versão do Erlang no passo anterior você pode listar as verões do Elixir disponíveis executando o comando:

asdf list-all elixir

1.12.1
1.12.1-otp-22
1.12.1-otp-23
1.12.1-otp-24
master
master-otp-21
master-otp-22
master-otp-23
master-otp-24
...

Como você pode perceber o Elixir tem múltiplas versões compiladas para cada major release do Erlang/OTP.

Agora você escolher a verão desejada compatível com a versão do Erlang instalada anteriormente e executar o comando para instalar:

asdf install elixir 1.12.1-otp-23

Selecionando uma verão para usar

Agora que a gente já sabe instalar as diversas verões disponíveis na mesma máquina vamos ver como selecionar a verão desejada. O asdf permite a gente fazer isso de duas formas.

Em uma pasta específica

Para definir uma versão para uma pasta específica a gente utiliza o comando local do asdf:

asdf local erlang 23.3.4.3
asdf local elixir 1.12.1-otp-23

Esse comando local vai criar na pasta que você executou o comando um arquivo .tool-versions que é utilizado pela linha de comando para definir a versão das linguagens que vai ser utilizado naquele projeto.

De forma global

Para definir uma versão para todos os projetos que não tenham uma versão definida ainda você pode utilizar o comando global do asdf.

asdf global erlang 23.3.4.3
asdf global elixir 1.12.1-otp-23

Este comando vai criar no seu diretório home o arquivo .tool-versions que vai definir as versões das linguagens que tem que ser utilizadas.

Espero que o conteúdo tenha sido útil para vocês.

GitHub Actions - Elixir

Vitor Leal — Tue, 07 Apr 2020 01:55:45 +0000

O Actions é uma ferramenta integrada aos seus repositórios do GitHub para automatizar os seus workflows de CI/CD (continuous delivery / continuous deploy). Você consegue rodar esses workflows baseado em diversos eventos do GitHub, como um novo push em uma branch a criação de uma nova issue ou uma nova release publicada.

Contexto

Desde que o GitHub lançou a versão beta do Actions, a Ingresse vem a testando. No final do ano passado o Actions saiu da versão beta e a gente decidiu finalmente migrar nossos workflows para lá.

Já que Elixir é a nossa linguagem principal na Ingresse, começamos a migrar primeiro os workflows dos serviços em Elixir para o Actions e aqui tem algumas dicas de como a gente faz.

Básico

Antes de tudo vou apresentar um pouco do básico do GitHub Actions, se você já tem familiaridade pode seguir passar direto essa seção.

O Actions vai ler os arquivos .yml ou .yaml dentro da pasta .github/workflows na raiz do seu projeto.

Primeiro vamos criar a pasta .github com a pasta workflows dentro:

mkdir -p .github/workflows

Agora vamos criar um arquivo que a gente pode chamar de ci.yml:

touch .github/workflows/ci.yml

Agora vamos adicionar o seguinte conteúdo nele:

name: Meu Workflow

on: push

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v1

Vamos aos detalhes do conteúdo desse arquivo.

`name`

O nome do seu workflow. É um campo opcional.

`on`

O nome do evento do GitHub que vai iniciar esse workflow.

Pode ser um evento apenas:

# Vai rodar sempre que alguém realizar um push no repositório
on: push

Pode ser uma lista de eventos:

# Vai rodar sempre que alguém realizar um push no repositório
# e quando for criado um novo pull request
on: [push, pull_request]

Pode ser customizado por evento:

on:
  # Vai rodar sempre que um pull request for criado
  pull_request:
    # Mas quando estiver apontando para a master
    branches:
      - master

  # Vai rodar sempre que uma release for criada
  release:
    # Mas se ela estiver com o status de publicada
    types: 
      - published

`jobs`

Um workflow pode ter um ou mais jobs. Por padrão, múltiplos jobs rodam em paralelo.

`jobs.<id-do-job>.run-on`

Em que tipo de máquina o job vai ser executado.

Pode ser em um tipo de máquina:

jobs:
  test:
    runs-on: ubuntu-latest

Podem ser em múltiplos tipos de máquinas, incluindo `ubuntu`, `macos` e `windows`:

jobs:
  test:
    strategy:
      matrix:
        platform: [ubuntu-latest, macos-latest, windows-latest]

    runs-on: ${{ matrix.platform }}

`jobs.<id-do-job>.steps`

Um job pode ter uma ou mais tarefas que vão ser executadas. Uma tarefa pode executar comandos, rodar setups ou rodar outras actions. O próprio GitHub tem uma série de actions publicadas que facilitam muitos trabalhos. Nesse exemplo estamos usando a action actions/checkout na versão v1 para clonar o repositório do projeto.

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      # Primeira tarefa a ser executada vai ser clonar o repositório
      - uses: actions/checkout@v1

Próximos passos

Bom agora que a gente já sabe um pouco mais sobe a estrutura básica de um workflow do GitHub Actions vamos começar a moldar ele para executar por exemplo uma tarefa de mix format e uma tarefa de mix test em um projeto Elixir.

Para evitar ter que instalar o Elixir no processo de build, vamos utilizar o atributo container para baixar uma imagem Docker já existente.

name: Meu Workflow

on: push

jobs:
  test:
    runs-on: ubuntu-latest

    container:
      image: elixir:1.10

    steps:
      - uses: actions/checkout@v1

`jobs.<id-do-job>.container`

Em qual imagem Docker vai rodar as tarefas desse job.

jobs:
  test:
    container:
      image: elixir:1.10

Agora que nosso ambiente já tem Elixir, podemos criar as tarefas para executar o mix format e mix test.

name: Meu Workflow

on: push

jobs:
  test:
    runs-on: ubuntu-latest

    container:
      image: elixir:1.10

    steps:
      - uses: actions/checkout@v1

      - name: Formatar
        run: mix format --check-formatted

      - name: Instalar as dependências
        run: mix deps.get

      - name: Testar
        run: mix test

Pronto já temos um workflow que clona nosso repositório, verifica se nosso código está formatado de acordo com as configurações do projeto, instala as dependências e roda nossos testes.

Utilizando serviços

O cenário anterior funciona perfeitamente para quando a gente tem um lib escrita em Elixir, mas para casos que a gente esteja trabalhando em um projeto com Phoenix por exemplo, a gente vai precisar provavelmente conectar em um banco de dados para poder executar alguns testes.

Nesse momento a gente consegue utilizar os services para criar containers de um banco de dados Postgres, por exemplo, para que os nossos jobs possam ter onde se conectar.

`jobs.<id-do-job>.services`

services:
  postgres:
    image: postgres

    # Mapeia a porta 5432 no container Docker para a porta 5432 no container do Postgres
    ports:
      - 5432:5432

    # Configura os dados de acesso ao banco de teste
    env:
      POSTGRES_USER: usuario
      POSTGRES_PASSWORD: senha
      POSTGRES_DB: banco

Agora que o nosso workflow vai criar o banco de dados pra gente poder conectar, tem um detalhe que temos que alterar nas nossas tarefas que vão rodar para conectar nesse banco. No caso, a nossa tarefa mix test tem que receber uma variável de ambiente para poder conectar corretamente no banco criado pelo Actions.

- name: Testar
  run: mix test
   env:
     POSTGRES_HOST: postgres
     POSTGRES_PORT: $❴❴ job.services.postgres.ports[5672] ❵❵

O exemplo completo fica assim:

name: Meu Workflow

on: push

jobs:
  test:
    runs-on: ubuntu-latest

    container:
      image: elixir:1.10

    services:
      postgres:
        image: postgres

        ports:
          - 5432:5432

        env:
          POSTGRES_USER: usuario
          POSTGRES_PASSWORD: senha
          POSTGRES_DB: banco

    steps:
      - uses: actions/checkout@v1

      - name: Formatar
        run: mix format --check-formatted

      - name: Instalar as dependências
        run: mix deps.get

      - name: Testar
        run: mix test
        env:
          POSTGRES_HOST: postgres
          POSTGRES_PORT: $❴❴ job.services.postgres.ports[5432] ❵❵

Agora basta alterar as configurações da nosso ambiente de teste para receber utilizar as variáveis de ambiente:

import Config

config :meu_app, Meu.Repo,
  adapter: Ecto.Adapters.Postgres,
  username: "usuario",
  password: "senha",
  database: "banco",
  port: String.to_integer(System.get_env("POSTGRES_PORT", "5432"))
  hostname: System.get_env("POSTGRES_HOST"),
  pool: Ecto.Adapters.SQL.Sandbox

Docker Compose

Se você já utiliza Docker Compose nos seus projetos você não precisa criar os services no arquivo do Actions e pode criar esses serviços direto no seu arquivo do Docker Compose de teste.

Exemplo do arquivo docker-compose-test.yml:

version: "3.3"
services:
  meu_servico:
    build: .
    depends_on:
      - meu_postgres
    ports:
      - "4000:4000"
    environment:
      - MIX_ENV=test
    command: mix phx.server

  postgres:
    image: postgres
    container_name: meu_postgres
    environment:
      - POSTGRES_DB=banco
      - POSTGRES_USER=usuario
      - POSTGRES_PASSWORD=senha
    ports:
      - "5433:5432"

Para rodar os testes com o Docker Compose, o ideal é mudar a imagem que roda no Actions para uma imagem que tenha já tenha o compose instalado.

jobs:
    container:
      image: docker/compose

O exemplo completo fica assim:

name: Meu Workflow

on: push

jobs:
  test:
    runs-on: ubuntu-latest

    container:
      image: docker/compose

    steps:
      - uses: actions/checkout@v1

      - name: Formatar
        run: docker-compose -f docker-compose-test.yml run meu_servico mix format --check-formatted

      - name: Testar
        run: docker-compose -f docker-compose-test.yml run meu_servico mix test

Espero que tenha ajudado vocês a entender um pouco melhor como rodar projetos Elixir no GitHub Actions.

Até a próxima!

Adotando o Elixir na Ingresse

Vitor Leal — Fri, 06 Mar 2020 20:26:57 +0000

Com o crescimento acelerado da Ingresse nos últimos anos, tivemos que reformular nossa arquitetura e infraestrutura inicial para poder escalar com essa demanda.

A Ingresse nasceu com uma base em PHP, um Monolito que atendeu bem o MVP e os primeiros anos do produto, mas com o passar do tempo acabou dificultando a evolução dele.

No processo de reformulação da arquitetura em 2016 nasceram os primeiros serviços em Python que resolveram bem os problemas para qual a linguagem foi escolhida. No início de 2017 quando estávamos com uma stack com um misto de PHP e Python começamos a olhar para outras linguagens que nos ajudasse a escalar e aproveitar melhor todos os recursos disponíveis da nossa infra. Mas para essa linguagem a gente tinha um foco muito importante, ela tinha que ser developer friendly, estávamos buscando uma linguagem que nos ajudasse na escalabilidade e performance mas principalmente na produtividade do nosso time.

Prova de conceito

Para começar fizemos uma prova de conceito de um microserviço novo implementando poucas features, mas desenvolvendo as mesmas features utilizando duas das linguagens que estávamos analisando. A idéia não era comparar só a performance do serviço entre essas duas linguagens, mas também, como é o dia a dia desenvolvendo com essas linguagens.

Escolhendo o Elixir

Uma das linguagens escolhidas para o teste foi o Elixir. Uma linguagem open source criada pelo José Valim na Plataformatec, empresa recentemente adquirida pelo Nubank.

O Elixir é uma linguagem moderna que executa na Máquina Virtual Erlang (BEAM), conhecida por executar sistemas de baixa latência, distribuídos e tolerantes a falhas.

Além disso tem uma comunidade muito ativa e frameworks para desenvolvimento web como o Phoenix que tem foco em criar uma estrutura produtiva que não compromete a velocidade de desenvolvimento nem a manutenção.

Alguns pontos altos do Elixir:

Instalação simples

A instalação do Elixir é muito simples, tem instalador para Linux, Mac, Windows e para quem prefere container como eu, imagens Docker para não sujar seu ambiente.

Documentação e conteúdo

A documentação é bem completa e fácil de navegar. O site da linguagem aponta diversos materiais de leitura, cursos e screencasts para quem quer começar. Tem muito material gerado pela comunidade, tanto aqui no Dev.to quanto no Medium.

Um ótimo lugar para iniciar com conteúdo em português é o ElixirSchool.

Gerenciador de pacotes

Uma coisa que a gente espera em todas as linguagens modernas é um gerenciador de pacotes decente. E esse é o caso do Hex, um gerenciador de pacotes para as linguagens que compilam para rodar na Maquina Virtual do Erlang (BEAM).

Ferramenta de build

O Mix é uma ferramenta de build que fornece tasks para criar, compilar e testar projetos Elixir, gerenciar suas dependências e muito mais. É uma ferramenta que facilita o dia a dia no desenvolvimento e nos processos de automatização.

Testes

O ExUnit é um framework completo para testes no Elixir. Totalmente integrado para ser executado com um simples mix test e com capacidade de rodar os testes de forma assíncrona.

Produtividade

A velocidade de desenvolvimento no Elixir é muito boa. Tem um syntax que é fácil escrever um código limpo e compreensível sem sacrificar a produtividade de um desenvolvedor.

Processo de mudança

Hoje ainda temos microserviços em outras linguagens rodando em produção, simplesmente porque estão dando conta do recado. Já até pensamos em migrar alguns mas se ainda estão funcionando bem não tem porque mexer.

Com o tempo o nosso time foi pegando pequenas tarefas para executar em Elixir até sentirem que tinham o domínio na linguagem para poder dar manutenção e criar novos microserviços do zero. A troca de conhecimento entre as equipes é essencial para que esse tipo de mudança tenha sucesso.

Com certeza não é um processo rápido adotar uma nova linguagem em produção, quando se tem uma quantidade enorme de acessos, mas acredito que os benefícios de ter uma linguagem moderna com um grande foco no desenvolvedor e na sua produtividade é um grande diferencial para a equipe e para o futuro da empresa.

Um dos nossos desenvolvedores Backend escreveu um post sobre Elixir, com uma visão de quem veio do PHP. Muito útil pra quem está tendo seu primeiro contato com a linguagem e com o paradigma funcional.

Conclusão

Essa prova de conceito hoje se tornou um dos nossos principais serviços e está em produção desde o final de 2017.

Ele é responsável por transacionar centenas de milhões de Reais em ingressos todo ano, não só na Ingresse mas em outras "tiqueteiras" do mercado que utilizam nossas API's. É um Gateway de pagamentos, com múltiplos adquirentes e plataformas de pagamento integradas como Cielo, Stone, Getnet, PicPay, StarkBank, Iugu e PayPal.

Hoje todos os nossos serviços novos são desenvolvidos em Elixir. Até agora temos 5 deles em produção e no momento mais 3 sendo desenvolvidos em 2020.

Se já trabalha com Elixir ou estiver querendo aprender estamos sempre com vagas abertas.