Resumo

Agora que temos o boilerplate feito, precisamos configurar o CI corretamente.

Jobs do CI

• testes
• lintagem
• análise de segurança do código
• CodeCov com restrição

CONTEXTO/PROPÓSITO

Na página principal (homepage) o usuário (entregador/advogado) indica o seu perfil e resolve um captcha.
O propósito aqui é armazenar o e-mail informado pelo usuário

CRITÉRIOS DE ACEITE

1. O formato do e-mail deve ser validado
2. O perfil (entregador/advogado) e o e-mail informado devem ser armazenados

Problema

Precisamos criar a estrutura de código do projeto para iniciarmos o desenvolvimento. Com isso é necessário montar um boilerplate, organizando as ferramentas e elementos que o projeto de backend irá utilizar.

Estratégia

Sugestão de tópicos que podemos pensar:

• Javascript ou Typescript ? Decidido por Javascript. Mais informações no chat do Discord
• Qual framework http ? Ex: express, fastify, hapi.js, etc
• Qual padrão de código iremos utilizar ? Ex: MVC, MVVM, etc
• Iremos utilizar algum framework alto nível ? Ex: NestJS, AdonisJS, etc
• Qual estilo de código ? Ex: AirBnB Style Guide, Google Style Guide, JS Standard Style Guide, etc
• Quais bibliotecas de testes ? Ex: Jest, Mocha, etc
• Quais linters e formatters ? Ex: ESlint, prettier, etc

Algumas dessas decisões já estão sendo discutidas nas issues #2 e #4 e no chat do Discord.

São muitas dúvidas e certamente ainda falta coisa. Acredito que podemos olhar para algo já pronto e extrair o melhor dele, ou criar algo do zero, agregando as boas práticas que o time decidir adotar.

Sugestões são bem vindas 🎉

Resumo

Após termos o #1 concluídos, precisamos decidir e documentar quais os requisitos que utilizaremos para julgar o que é um PR válido.

Já temos alguns pontos. Mas precisamos expandir.

Explicar nossos 'padrões' de projeto e qualidade de código para ser um PR aceitável (isso pode ser adicionado posteriormente pois ainda será descutido com os tech leads).

Explicar também o que deve acontecer se for um PR inválido.

Exemplos

Por exemplo:

• explicar que para ter um PR é nesserário tem uma Issue aberta
• explicar que teremos testes de CI (obrigatórios) que se não passarem seu PR não será revisado (explicar quais testes)
• explicar os padrões adotados
  • linting
  • linguagem
  • docstring
  • documentação
• adição de testes se for uma feature ou mudança de comportamento

Esse issue existe em outros repos

Temos esse issue com a mesma discussão no idvogados.github.io e frontend. Utilizar esse issue para discutir.

idvogados/idvogados.github.io#2
idvogadosorg/idvogados-web#2

Resumo

Relacionado as issues #14 e #15

Criterios de aceitação

• Apenas texto com características de email podem ser aceitos (Regex)
• Verificar se o email não existe no banco de dados

Informações adicionais

• Esse validador deve ser usado para advogados, usuários e qualquer outro email necessário
• O tipo da entidade deve ser fornecida por parâmetro
• Deve ser um helper

Spec

src/helpers/validate-email.js

module.exports = async (email, model) => {
    const reg = new RegExp(/** definir regra de regex a ser utilizada */)
    if (!reg.test(email)) return false
    const alreadyExists = await model.exists({ where: { email } })
    if (alreadyExists) return false
    return true
}

Problema

A implementação do boilerplate contém um wrapper da lib PinoJS criado em
src/client/logger-client.js, que já possúi toda configuração básica para se utilizar os métodos padrões de um logger (info, warn, error, etc).

Dessa forma, precisamos definir um padrão dos logs gerados pela API, descrever como será o JSON enviado ao terminal e quais campos devem estar presentes, para que seja possível indexar em um agregador e gerar estatísticas dessas informações.

Além disso, precisamos debater se iremos utilizar alguma plataforma (kibana, serviço em cloud, etc) para armazenar os logs, mantendo seu histórico ou apenas joga-los no terminal. Acredito que o @deniojunior poderá nos ajudar.

Sugestão

Acredito que possamos utilizar a seguinte chamada no código:

logger.method({
    action: 'service.method', // indica onde o log foi chamado no código
    message: 'foo bla',       // mensagem descritiva da operação
    meta: {                   // metadados da operação (opcional)      
       color: 'red',
       user: 'john'
   }
})

Resumo

Teremos algumas automações para os issues/pr's com relação ao nosso workflow (mantido no Project).

Possibilidades

• Automação baseado apenas em label
• Automação baseado em assignee
• Automação baseado em label junto com assignee

Referência

• https://github.com/marketplace/actions/github-project-automation
• https://github.com/marketplace/actions/assign-to-one-project
• https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idif
• https://github.com/imobanco/zoop-wrapper/blob/master/.github/workflows/project-automation.yml
• https://developer.github.com/v3/activity/events/types/#projectcardevent

Detalhamento técnico

Issues

Como PM, eu gostaria das seguintes automações:

• Todo ticket de bug fosse movido para a coluna de triagem (dentro do projeto Quadro de preparo
• Quando o label Em progresso for atribuído a uma issue, ela deve ser movida para o quadro In Progress no projeto Sprint
• Quando um ticket for movido para In Progress no projeto Sprint, o label Em progresso deve ser atribuído à issue.
• Quando uma issue receber o label Bloqueado ela deve ser movida para a coluna Blocked do projeto Sprint
• Quando um ticket for movido para Blocked, a label Bloqueado deve ser atribuída à issue

PR

Como PM gostaria das seguintes automações:

• Quando um novo PR for criado, mover a issue para Code Review, no projeto Sprint
• Quando um novo PR for criado, assinar todos os tech-leads e marcá-los para revisar o código
• Quando um novo PR for criado, Adicionar a label Precisa ser revisado (tanto no PR quanto na issue)
• Se um PR ficar mais de 30 dias sem nenhuma atividade, ele deve ser fechado e a issue associada voltar para a coluna de To Do e remover os labels
• Quando um for feito o merge do PR com a branch dev, a issue deve ser movida para a coluna Done do projeto Sprint

Observação

Precisamos documentar essas automações em algum 'manual', seja ele no CONTRIBUTING.md ou outro (tech leads ou um próprio para isso)

Resumo

Relacionado ao épico #9 .

O usuário (entregador) deve conseguir cadastrar seu e-mail de contato na plataforma.

Critério de aceitação

• Apenas texto com características de email podem ser aceitos (Regex)
• Se o e-mail não for válido, uma mensagem de erro deve ser retornada para o front-end
• Se o e-mail for válido, ele deve ser salvo em nossa base de dados e uma mensagem de sucesso deve ser enviada para o front-end

Comportamento

• Se o e-mail não for válido, uma mensagem de erro deve ser retornada para o front-end
• Se o e-mail for válido, uma mensagem de sucesso deve ser enviada para o front-end

Tarefa

Mudar template do PR para fechar a(s) issue(s) associadas.

Resumo

Precisamos de um CONTRIBUTING.md

Requisitos

• o arquivo precisa ser em português
• linkar nosso código de conduta
• explicar fluxo de como dar fork (ou linkar para uma documentação que explique)
• explicar fluxo de como fazer um PR (ou linkar para uma documentação que explique)

Além disso, adicionar o seguinte heading no README.md:

# Como contribuir
Leia nosso guia de contribuição nesse arquivo (link para o contributing)

Referências

• https://github.com/xamarin/Xamarin.Forms/blob/master/.github/CONTRIBUTING.md
• https://github.com/dotnet/runtime/blob/master/CONTRIBUTING.md

Precisamos ter o seguinte heading no arquivo CONTRIBUTIND.md:

# Configurando o ambiente de desenvolvimento
bla bla bla

Aguardando decições dos tech leads e criação do boilerplate do projeto

O link para os termos de uso deverá ficar no README.md ou no CONTRUBUTING.md?

Após a discussão tida nesse issue, foi decidido que ficará no README.md .

Resumo

Criar um client na API para comunicar com o sendgrid.

Critério de aceitação

• Ser possível enviar um e-mail para uma conta catalogada;
• Ser possível enviar um e-mail para várias contas catalogadas, de uma vez;
• Ser possível criar e-mail personalizado (alterando nome em cada envio, por exemplo);
• Ser o mais customizada possível, para que seja possível utilizar em diferentes contextos;
• Deve ser implementado dentro da pasta src/clients;
• Instanciar o sendgrid com as variáveis de ambientes

Comportamento

• Ao fazer a chamada desta API um ou vários e-mails devem ser enviados para o(s) destinatário(s);

Depende de

• PR #17

Bloqueia

Por enquanto não bloqueia nenhuma issue.

CONTEXTO/PROPÓSITO

Na página principal (homepage) o advogado indica o seu perfil e resolve um captcha.
O propósito aqui é armazenar o e-mail que o advogado informou no form que é exibido após a resolução do captcha.

CRITÉRIOS DE ACEITE

1. O formato do e-mail deve ser validado
2. O perfil (advogado) e o e-mail informado por ele devem ser armazenados

Tarefa

Arquivos locais de configuracao de IDEs, como JetBrains e VS Code, podem ser salvos no repo.

Novas regras deveriam ser adicionadas ao arquivo .gitignore para que isto nao ocorra.

Resumo

Os tech leads ou responsáveis pelo projeto ou as pessoas que forem fazer code review devem ter um arquivo de instruções. Por exemplo:

• boas práticas
• padrões adotados
• o que é um PR válido (#2)
• dentro outros tópicos

Sugestão

Ter um arquivo público em cada respositório com essas instruções.

Motivação

Traria mais transparência do processo de gerência para quem esta contribuindo (ter uma gerência mística nem sempre é bom).

O que acham?

Originally posted by @rodrigondec in idvogadosorg/idvogados-web#10

Decidimos utilizar o Jest. É mais completo e autocontido. Porém o Jest aparentemente (pode ter problema) com debugging.

Tem também o mocha (que depende de outras libs).

tarefa

discutir e decidir qual a lib a ser utilizada.

• escrever código com a lib
• como configurar a lib
• como rodar os testes
• como debugar nas IDE's

CONTEXTO/PROPÓSITO

Na página principal (homepage) o usuário (entregador/advogado) indica o seu perfil e resolve um captcha.
O propósito aqui é armazenar o e-mail informado pelo usuário

CRITÉRIOS DE ACEITE

1. O formato do e-mail deve ser validado
2. O perfil (entregador/advogado) e o e-mail informado devem ser armazenados

Resumo

Relacionado ao épico #8.

O advogado deve conseguir cadastrar seu e-mail de contato na plataforma.

Critério de aceitação

• Apenas texto com características de email podem ser aceitos (Regex)
• Se o e-mail não for válido, uma mensagem de erro deve ser retornada para o front-end
• Se o e-mail for válido, ele deve ser salvo em nossa base de dados e uma mensagem de sucesso deve ser enviada para o front-end

Comportamento

• Se o e-mail não for válido, uma mensagem de erro deve ser retornada para o front-end
• Se o e-mail for válido, uma mensagem de sucesso deve ser enviada para o front-end