2018.2-NaturalSearch

Para propósitos de arquitetura microserviços utilizaremos um segundo repositório aqui: https://github.com/NaturalSearch/NaturalSearch_visualization

View project on GitHub

Contribuindo com o NaturalSearch

Antes de decidir se deseja de fato contribuir conosco leia o README do projeto e conheça melhor como funciona o nosso projeto, bem como o código de conduta da equipe.

Como contribuir?

Reportar Bugs

Caso deseje reportar um bug no projeto, então:

  • Crie uma issue e marque-a com a label bug para que possamos ver e resolver o problema o mais rápido possível.

  • Caso exista uma issue para o problema, então, é possível adicionar um comentário sobre o problema se achar necessário.

Adicionar/Modificar funcionalidades

Se o objetivo é adicionar e/ou modificar uma funcionalidade já existente, então:

  • Verifique se existe uma issue com a mesma modificação ou adição que você pretende realizar.

  • Se não existir, crie uma nova issue com um título significativo, adicione uma descrição e, no mínimo, uma label.

  • Submeta as mudanças através de um pull request e aguarde pela aprovação da equipe.

Política de commits

É recomendado que todo contribuinte do projeto siga as orientações a seguir para realizar commits de forma padronizada:

  • Commits exclusivamente em inglês.

  • Mensagens curtas e significativas sobre o conteúdo do commit.

  • Apenas commits que adicionem incrementos significativos, ou seja, nada de commits apenas mudando nomes de variáveis, por exemplo.

  • Se estiver trabalhando em conjunto especifique os participantes no commit.

Exemplo:

Adds project license (Descrição de uma atividade)

Adds project code of conduct file

Co-authored-by: FilipeKN4 <filipekn4@gmail.com> (Assinatura do(s)participante(s))

Política de branches

Visando padronizar a criação de branchs e facilitar a identificação do objetivo de criação de cada uma delas a equipe adota uma política de branches que deve ser seguida completamente para qualquer um que visa contribuir com este projeto. A política segue o fluxo de trabalho da ferramenta git flow, sendo assim, recomenda-se fortemente a instalação e utilização dela. Os tipos de branch são utilizados são:

  • master - é a branch principal do repositório e realiza o papel de ambiente de produção. Nela só é aceito código devidamente testado e validado, de modo que todas as inserções nela feitas serão as releases do projeto.

  • development - é a branch que concentrará todas as novas funcionalidades do projeto, onde realizará o papel de concentrar o trabalho do ambiente de desenvolvimento, correção de bugs e finalização de testes.

  • feature/ - tipo de branch utlizada para o desenvolvimento de uma nova feature do projeto, de modo que o nome do deve ser “US - “ e o número da história de usuário que essa feature representa. Ex: “feature/ US - 01”

  • bugfix/ - branch utilizada para corrigir bugs de baixa ou média urgências e não estão presentes na master. O nome deve ser a descrição do bug. Ex: “bugfix/ descricao”

  • hotfix/ - branch utilizada para corrigir bugs de alta urgências que foram passados para a master. O nome deve ser a descrição do bug. Ex: “hotfix/ descricao”

  • release/ - branch utilizada para a homologação do sistema e correções finais, caso sejam necessárias. O nome deve ser o número da versão da nova release. Ex: “release/ v1.0”

Usando o git flow

Para seguir o fluxo do git flow no projeto da melhor forma abra o terminal do Linux e configure-o da seguinte forma.

1 - Clone o repositório para sua máquina com o comando:

git clone https://github.com/fga-eps-mds/2018.2-NaturalSearch.git

2 - Vá até a pasta do projeto e utilize:

git flow init

Responda as perguntas exatamente da seguinte forma:

Which branch should be used for bringing forth production releases?
    - development
    - gh-pages
    - master
Branch name for production releases: [master]         

Which branch should be used for integration of the "next release"?
    - development
    - gh-pages
Branch name for "next release" development: [] development         

How to name your supporting branch prefixes?
Feature branches? [feature/] 
Bugfix branches? [bugfix/] 
Release branches? [release/] 
Hotfix branches? [hotfix/] 
Support branches? [support/] 
Version tag prefix? [] v

Para a pergunta “Hooks and filters directory?” apenas pressine ENTER.

Agora que o git flow foi configurado na sua máquina basta utilizá-lo.

Política de Issues

Para facilitar a comunicação e padronização de atividades da equipe por meio de issues a equipe do Natural Search optou pela criação de uma política de issues que deve ser seguida sem excessões por todos os membros e possíveis contribuintes com o produto. A seguir os padrões de issues utilizados:

  • Iniciadas sempre com verbo no infinitivo. Exemplo:

    • “Elaborar Documento de Visão.”

  • Breve descrição que explica sobre o que se trata a issue adicionada. Exemplo:

    • “Esta issue refere-se a criação do Documento de Visão do Natural Search por parte dos membros da disciplina MDS.”

Para issues referentes a histórias de usuário e histórias técnicas devem ser considerados, também, os padrões a seguir:

User Story: tipo de issue utilizada para a marcação de histórias de usuário. O padrão deve ser:

  • US01 - “descrição da issue”

Tecnical Story: tipo de issue utilizada para marcação de histórias técnicas. O padrão deve ser:

  • TS23 - “descrição da issue”