Procedimentos de Trabalho

Descrição

Esta seção é dedicada a apresentar convenções e processos de desenvolvimento do time, junto dela serão apresentados documentos referentes a maneira que o time se organizou e trabalha.

Sumário

• Git Workflow
• Convenções de Código
• Matriz de Responsabilidade
• Plano de Comunicação
• Plano de Riscos

Git Workflow

Branches

Nomes

Como padrão para nomes de branches, foi decidido:

<tipoDeTask>/<userStoryDaTask>
Ex: feature/US01

Exemplo de Componentes:

component-navBar
component-slider

Exemplo de Páginas:

page-recipes
page-creations

Criação

Para garantir que o processo de desenvolvimento esteja sempre atualizado com a branch develop, lembre-se de executar o seguinte comando na sua branch antes de subir o código para o repositório:

git pull origin develop

Depois da execução desse comando é necessário criar uma branch, para isso, execute o seguinte comando:

git checkout -b <nomeDaBranch>

Assim que criar a branch, é necessário fazer um git push para garantir que a mesma estará criada remotamente:

git push --set-upstream origin <nomeDaBranch>

Pronto! Agora você já pode começar a programar na sua Branch.

Commits

Para que o código desenvolvido seja salvo em sua branch de maneira remota, é necessário realizar os comandos de commit, seguido do comando push.

Salvando Localmente

Antes de chamar o commit, lembre-se de adicionar os códigos a serem "commitados", desta forma, chame o comando add para adicionar os arquivos essenciais para a tarefa:

git add <nomeDoArquivo>

Depois de adicionar todos os arquivos que deseja salvar, execute o commando de commit com uma mensagem curta que represente o que foi trabalhado nesses arquivos adicionados:

git commit -m 'descrição da tarefa em português'

Não hesite em realizar vários commits, assim podemos ter documentado e salvo vários estados do desenvolvimento.

Salvando Remotamente

Depois de finalizar o desenvolvimento, envie todos os commits da sua máquina para o servidor remoto. Para isso depois de realizar as etapas de salvamento local, salve remotamente com o comando push:

git push

!!! Atenção: Antes de dar push, sempre de o comando:

git pull origin develop

Esse comando irá garantir que sua branch esteja sincronizada com a branch develop, evitando conflitos na hora de subir o código para o repositório.

Merge Requests

Depois de uma task ter sido desenvolvida e estiver pronta de acordo com os critérios de aceitação, é necessário que a mesma seja enviada para a branch de desenvolvimento. Para isso é necessário abrir um Merge Request pela platafora GitLab:

Criando o Merge Request

A criação pode ser realizada na seção Merge Requests do repositório em que a branch foi criada. Clicando no botão New Merge Request siga os seguintes passos:

1. Selecionar a branch de origem (sua branch de desenvolvimento);
2. Selecionar a branch de destino (branch dev);
3. Selecione Compare branches and continue
4. Em Title, escreva um título que descreva a funcionalidade adicionada ou bug corrigido;
5. Em Description, escreva uma descrição com uma breve justificativa nos arquivos que foram alterados;
6. Caso a tarefa seja visual (criação de componente/tela, correção de bug) adicione um gif exemplificando o uso (se considerar necessário);
7. Na seção Assignee, selecione Assign to me para que fique registrado quem foi o responsável pelo desenvolvimento daquela tarefa (a pessoa selecionada será chamada caso o revisor tenha dúvidas sobre a tarefa);
8. Em Milestone selecione a Sprint em que a tarefa foi realizada;
9. Em Labelsselecione qual é o tipo de tarefa que foi realizada;
10. Por último, revise se os arquivos que estão sendo enviados estão corretos e clique em Submit Merge Request.

Revisando o Merge Request

A revisão de merge request pode ser realizada por qualquer desenvolvedor, mas é preciso da aprovação de pelo menos um AGES III ou AGES IV para que a mesma seja incorporada na dev.

Na hora de revisar o Merge Request, entre na branch em sua máquina e teste a funcionalidade/bug/componente/tela de acordo com os critérios de aceitação apresentados no Airtable.

Caso haja pendências, relacionadas a documentação do código, padronização ou arquivos enviados, não exite em realizar um novo commit na branch com as mudanças necessárias antes de realizar a integração.

Convenções de Código

Nos projetos de frontend e backend, foram definidos padrões de código a serem seguidos.

Para auxiliar o programador a manter o código bem organizado, utilizamos as seguintes extensões de IDE:

• Prettier
• Conventional Commits

Prettier

O Prettier é uma ferramenta de formatação de código que permite definir convenções textuais como identação, espaçamento, etc. As configurações do Prettier foram préviamente definidas no projeto, basta adicionar o Prettier em sua IDE de prefêrencia.

Caso esteja utilizando o VS Code (Visual Studio Code), basta abrir o painel de Extenções com Ctrl + Shift + x , pesquisar por "Prettier" e instalar a extensão.

As configurações do Prettier no VS Code também estão em ambos os repositórios com o nome de settings.json. Toda vez que salvar o projeto, com o comando Ctrl + s, o editor será salvo e realizará as formatações definidas.

Os códigos que não estiverem respeitando os padrões de formatação, além de possivelmente não compilarem, não devem subir ao repositório.

Configurações definidas:

"semi": true         --> Adiciona ponto e vírgula no final
"singleQuote": true  --> Garante o uso de aspas simples
"tabWidth": 2        --> Tabulações definidas com 2 espaços
"printWidth": 100    --> Define o número máximo de caracteres de uma linha do código

Conventional Commits

O Conventional Commits é um padrão de commit popularmente utilizado na indústria, inicialmente concebido em projetos da Google, veja mais sobre aqui!

Nesse projeto, existem ferramentas para facilitar os commits de acordo com as regras estipuladas, basta escrever:

yarn commit

e um menu irá guiar o usuário para realizar o commit da maneira mais adequada.

O processo de commit tradicional, feito pelo comando git commit também é permitido neste projeto, desde que respeite as regras acima citadas.

Todos os commits que não respeitarem os padrões de commits previamente definidos, serão rejeitados automaticamente.

Nomenclatura de Arquivos

A nomenclatura dos arquivos de ambos os projetos, deve respeitar os padrões estipulados pelas arquiteturas dos projetos, ou seja, seguir os padrões e exemplos já estipulados no projeto. Em caso de dúvida, consultar a sessão de Arquitetura para maiores informações.

Documentação das Rotas

Para auxiliar o desenvolvimento e documentação do projeto de backend, fizemos o uso da ferramenta Swagger.

Swagger

O Swagger é definido como uma aplicação open source que auxilia desenvolvedores nos processos de definir, criar, documentar e consumir APIs REST. Em suma, o Swagger visa padronizar este tipo de integração, descrevendo os recursos que uma API deve possuir, como as rotas dos endpoints, o formato de dados recebidos, dados retornados, códigos HTTP e métodos de autenticação, dentre outros. Para mais informações, acesse este link: Swagger.

Matriz de Responsabilidade

Essa matriz foi desenvolvida para ajudar os membros do time a saberem seus papéis na dentro do processo de desenvolvimento.

I: Deve ser informado; C: Deve ser consultado; R: Responsável; A: Aprova

Plano de Comunicação

Plano de Riscos