2021.1-Cartografia-social-api-gatway

Repositório do gateway do projeto da Cartografia social

Sumário

• Dependências
• Execução
• Guia de Contribuição
  • Issues
  • Branches
  • Commits
  • Pull Requests
• Licença
• Código de Conduta

Dependências

Para a execução local da aplicação será necessário ter instaladas as seguintes ferramentas:

• Npm
• Docker Compose

Execução

Instalação

Faça um clone do repositório

$ git clone https://github.com/fga-eps-mds/2021.1-Cartografia-social-api-gateway

Instalando as dependências e Configurando variáveis de ambiente

$ cd 2021.1-Cartografia-social-api-gateway
$ npm install
#caso dê erro de permissão, tente executar com o comando sudo npm install

Crie um projeto no firebase e crie um arquivo '.firebase.env.' no diretório raiz. Se baseie no arquivo '.firebase.env.example' para o preenchimento das configurações.

Executando a aplicação

Para buildar a aplicação os seguintes comandos podem ser usados:

# local
$ make debug-build

ou

# local
$ docker-compose up --build gateway-debug rabbitmq mongo

Caso a execução falhe por causa que o serviço do rabbitmq ja esteja em execução, pode ser usado o seguinte comando para parar o processo e depois executar o comando anterior novamente:

$ sudo -u rabbitmq rabbitmqctl stop

Escolha um dos ambientes para a execução

# development ambient
$ docker-compose up gateway-dev mongo

# debug ambient
$ docker-compose up gateway-debug mongo

# production mode
$ docker-compose up gateway-prod mongo

Testes

# unit tests
$ npm run test

# e2e tests
$ npm run test:e2e

# test coverage
$ npm run test:cov

Guia de Contribuição

Para a contribuição e evolução das informações presentes nesse repositório, o seguinte guia de contribuição foi criado, especificando instruções de uso e dos padrões utilizados.

Issues

As issues devem ser criadas conforme template predefinido, contendo:

• Descrição - Descrição simples e direta do problema que a issue busca resolver ou da adição da issue;

• Tarefas - Checklist trazendo o passo a passo granularizado de como a issue deve ser executada, permitindo que cada tarefa seja marcada quando concluída;

• Critérios de Aceitação - Checklist do funcionamento ou resultado esperado após a conclusão da issue de forma satisfatória, permitindo que cada critério seja marcado quando concluído;

• Issue Vinculada - Referência a outra issue que esteja vinculada à issue presente, com link para a issue referenciada. Caso não haja issue, deve ser preenchido como 'Não se aplica.' somente;

• Assignees - As issues criadas devem ser atribuídas a um membro para execução, se houver alguém responsável por realizá-la;

• Labels - As issues criadas devem conter labels que categorizem aquela issue, para informar aos demais contribuidores sobre a natureza de seu conteúdo;

• Sprint - As issues devem possuir a sprint a qual se referem no campo destinado;

• Estimate - As issues devem ser pontuadas conforme seu grau de dificuldade;

Nomenclatura

A Nomenclatura das issues deve seguir o padrão:

[PREFIXO] Breve descrição da issue em português

De forma que o elemento PREFIXO siga o seguinte padrão

Prefixo	Tema	Exemplo
DOCS	Documentação	[DOCS] Melhorar README
DEVOPS	Integração, DevOps	[DEVOPS] Implementar CI/CD
USXX	História de Usuário, em que XX se refera ao número da história de usuário	[US12] Questionário para criação de uma nova comunidade
IMPROVE	Melhoria ou adição de funcionalidades não correlacionadas a uma História de Usuário	[IMPROVE] Adiciona regras de navegação ao frontend

Branches

Para a padronização das branches foi tomada uma adaptação do modelo padrão do gitflow conforme representado pelo diagrama abaixo:

Esse modelo segue a seguinte categorização para as respectivas branches:

• Main - A Branch Main contém o histórico oficial do código ou projeto em questão, sendo assim a versão do código que estará em produção no ciclo de vida do projeto.

• Hotfix - As Branches Hotfix servem para manutenção ou correção de forma rápida dos lançamentos em produção, feitas a partir da Main para uma integração mais rápida.

• Develop - A Branch Develop serve como uma ramificação para integração de recursos, sendo a versão do projeto disponível no ambiente de Homologação.

• Feature - As Branches de Feature servem para a realização de novas adições e funcionalidades para o projeto, sendo criadas a partir da branch develop para serem integradas a essa branch à medida que a feature (ou funcionalidade) em questão é concluída. Essas funcionalidades representam novas adições ao projeto em si, através da inserção de códigos.

• Support - As Branches Support servem para armazenar modificações que integram o projeto mas não representam funcionalidades (ou features), como documentação, Integração Contínua, Deploy Contínuo e demais configurações focadas na estrutura do projeto.

Nomenclatura

A Nomenclatura das branches deve seguir o seguinte padrão

Branch	Nomenclatura
Main	main
Develop	develop
Feature	feature/[NUMERO-USER-STORY]-[BREVE-DESCRIÇÃO-EM-INGLES] Ex.: feature/01-mark-point-on-map
Support	support/[BREVE-DESCRIÇÃO-EM-INGLES] Ex.: support/document-contribution-guide
Hotfix	hotfix/[BREVE-DESCRIÇÃO-EM-INGLES] Ex.: hotfix/remove-second-callback

Commits

Os commits devem seguir padrões paa identificação de alterações feitas e implementadas, tanto para futuras modificações quanto para gerar rastro de informação.

Nomenclatura

A Padronização de commits foi baseada na proposta de ConventionalCommits com adaptações, de forma que a mensagem final de commits assume a seguinte forma:

• [#NUMERO_ISSUE] tipo - breve descrição em inglês, com verbo no imperativo

Sendo o Número da Issue o Id atribuído a ela no momento de sua criação, o Tipo conforme descrito na próxima sessão e a Breve Descrição estando na língua inglesa, contendo o verbo principal no imperativo, conforme o seguinte exemplo:

• [#15] feat - Add user validation to point info

Lista de Tipos

Os tipos de commits a serem implementados são:

• test

Indica qualquer tipo de criação ou alteração de códigos de teste. Exemplo: Criação de testes unitários.

[#1] test - add unit test of main module

• feat

Indica o desenvolvimento de uma nova feature ao projeto. Exemplo: Acréscimo de um serviço, funcionalidade, endpoint, etc.

[#2] feat - create get location function 

• refactor

Usado quando houver uma refatoração de código que não tenha qualquer tipo de impacto na lógica/regras de negócio do sistema. Exemplo: Mudanças de código após um code review

[#3] refactor - reorder validation flow

• style

Empregado quando há mudanças de formatação e estilo do código que não alteram o sistema de nenhuma forma. Exemplo: Mudar o style-guide, mudar de convenção lint, arrumar indentações, remover espaços em brancos, remover comentários, etc..

[#4] style - change primary color

• fix

Utilizado quando há correção de erros que estão gerando bugs no sistema. Exemplo: Aplicar tratativa para uma função que não está tendo o comportamento esperado e retornando erro.

[#5] fix - remove second callback

• chore

Indica mudanças no projeto que não afetem o sistema ou arquivos de testes. São mudanças de desenvolvimento. Exemplo: Mudar regras do eslint, adicionar prettier, adicionar mais extensões de arquivos ao .gitignore

[#6] chore - add map library

• docs

Usado quando há mudanças na documentação do projeto. Exemplo: adicionar informações na documentação da API, mudar o README, etc.

[#7] docs - add architecture document

• build

Utilizada para indicar mudanças que afetam o processo de build do projeto ou dependências externas. Exemplo: Gulp, adicionar/remover dependências do npm, etc.

[#8] build - remove unused dependencies

• perf

Indica uma alteração que melhorou a performance do sistema. Exemplo: alterar ForEach por while, melhorar a query ao banco, etc.

[#9] perf - optmize validation flow

• ci

Utilizada para mudanças nos arquivos de configuração de CI. Exemplo: Circle, Travis, BrowserStack, etc.

[#10] ci - implement ci/cd

• revert

Indica a reverão de um commit anterior.

[#11] revert - revert previous commit

Pull Requests

Deve seguir o mesmo padrão de nomenclatura da issue, e os usuŕios devem se atentar a linkar a respectiva issue a ser fechada pelo pull request.

Nomenclatura

A Nomenclatura de Pull Requests deve seguir o padrão:

[PREFIXO] Breve descrição do Pull Request em português

De forma que o elemento PREFIXO siga o seguinte padrão

Prefixo	Tema	Exemplo
DOCS	Documentação	[DOCS] Melhorar README
DEVOPS	Integração, DevOps	[DEVOPS] Implementar CI/CD
USXX	História de Usuário, em que XX se refera ao número da história de usuário	[US12] Questionário para criação de uma nova comunidade
IMPROVE	Melhoria ou adição de funcionalidades não correlacionadas a uma História de Usuário	[IMPROVE] Adiciona regras de navegação ao frontend

Licença

A Licença do repositório presente é a Licença MIT, de seguinte texto:

Copyright 2021,

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Código de Conduta

O Código de Conduta do repositório leva em conta comportamentos que favoreçam o crescimento da comunidade e respeite a individualidade de cada membro, detalhado no documento completo.