1. Instalações
1.1 Linux
Pega o repositorio do github: git clone https://github.com/VictorArnaud/PGTBL.git
Instalar dependencias para rodar o python3 e pip3
sudo apt-get update
sudo apt-get install -y python3-dev sqlite python3-pip libpq-dev
sudo apt-get install -y gettext
Criar o ambiente virtual de desenvolvimento (virtualenvwrapper)
sudo pip3 install --upgrade pip
sudo pip3 install virtualenvwrapper
No arquivo .bashrc do link insira:
WORKON_HOME=~/.virtualenvs
VIRTUALENVWRAPPER_PYTHON=/usr/bin/python3
source /usr/local/bin/virtualenvwrapper.sh
-
Para criar um ambiente virtual:
mkvirtualenv <venv_name> -
Para entrar no ambiente virtual:
workon <venv_name> -
Para sair do ambiente virtual:
deactivate
Instalar dependencias do projeto dentro do ambiente virtual
pip install -r pgtbl/requeriments.txt
Rodar comandos para popular o banco de dados
make migrations
make migrate
make superuser
Rode o servidor
make run
1.2 Docker
Instale o docker: https://docs.docker.com/install/linux/docker-ce/ubuntu/
Execute o comando no diretorio do projeto:
docker-compose up -d
Se tudo der certo o projeto estará rodando na porta 8000
Obs: Se der erro tente com o sudo na frente do comando.
2. Contribuindo com o PGTBL
Caso queira contribuir com o projeto, talvez seja uma boa ideia começar pelo README para conhecer melhor sobre nós.
Outro documento importante e que deve ser lido é o Código de Conduta.
Obrigado por contribuir! Sua ajuda será recebida com muita gratidão!
2.1 Como eu posso contribuir?
2.1.1 Reportando um Bug
Esse projeto segue um padrão de Issues. Logo, caso encontre um bug, verifique se ele não se encontra em uma das nossas Issues. Os bugs devem ser marcados com tag (label) bug.
Se o bug encontrado não consta nas Isses, basta abrir uma Nova Issue.
2.1.2 Adicionando e/ou modificando alguma funcionalidade
Primeiro verifique que não existe nenhuma Issue a respeito dessa modificação e/ou adição.
Caso não exista, crie uma Nova Issue. Dê um título significativo a ela, coloque uma descrição e pelo menos uma label.
As mudanças devem ser submetidas através de Pull Requests.
2.2 Padrão de Commit
2.2.1 Por questões de padronização recomendamos que sigam nosso estilo de commit:
Os commits devem ser todos em inglês;
Ele deve conter um título curto e objetivo do que foi feito naquele commit;
Se for preciso, após esse título, deve-se descrever, com um pouco mais de detalhes, todas as atividades executadas.
Caso esteja trabalhando em com algum associado assine nos seus commits os seus parceiros
Exemplo:
Creating project community files (Título curto e objetivo)
Issue #01
Adds project license (Descrição de uma das atividades)
Adds project code of conduct file
Adds project contributing file
Adds project issue template file
Adds projects pull request file
Signed-off-by: Victor Arnaud <victorhad@gmail.com> (Assinatura de parceria)
2.3 Política de Branchs
A política de branches que será utilizada no decorrer do projeto seguirá o modelo descrito na imagem acima: para cada funcionalidade a ser implementada será criada uma branch a partir da branch devel, que estará em constante atualização com a branch master e vice versa.
Assim que cada funcionalidade for completada, será aberto um pull request (feito pela equipe de desenvolvimento) da branch correspondente à funcionalidade para a branch devel, para que esta seja aprovada.
O servidor de integração contínua estará funcionando em cima da branch master e devel. Ao fim de cada sprint, será realizado um rebase da branch devel para a branch master e então será realizado o processo de integração contínua do projeto. Tanto a branch master como a devel estarão em constante atualização, para que as próximas funcionalidades a serem implementadas tenham sempre o projeto mais atualizado possível.
Essa Política de Branches deverá guiar os desenvolvedores na forma de organização de suas contribuições ao repositório.
master - Branch principal do repositório onde será permitida somente a integração de software consolidado e testado. Essa branch será exclusiva para a entrega de Realeases, ou seja, um conjunto maior de funcionalidades que integram o software, aqui estará a versão stable do software.
dev - Branch para integração de novas funcionalidades, onde será permitido a entrega das features desenvolvidas e que estão em um estágio avançado de completude. Será o branch base para o início do desenvolvimento das features e da correção de bugs. Aqui também serão mergeadas as releases.
nome-da-feature - Branch utilizada para o desenvolvimento de novas features do backlog. Caso a feature tenha sida proposta por uma issue do repositório e aceita no backlog o nome deverá conter o número da issue.
Ex: US01_
2.4 Política de Pull Request
Para que o "Pull Request" das funcionalidades seja devidamente aceito, esta deve estar devidamente testada e conforme os padrões de commit e estilo de código. Além disso, a build da Integração Contínua deve estar "passando" para tal funcionalidade e o pull request deve ser aberto seguindo o padrão estipulado no template.
2.5 Política de Versionamento
Todos os artefatos de gerenciamento devem informar sua versão atual no seguinte formato: X.Y.Z, descrito abaixo:
X: Apenas incrementa quando há mudanças que quebram a estrutura do projeto ou que disponibiliza uma versão estável para uso do projeto.
-
X < 1: A versão do projeto não é estável.
-
X >= 1: A versão do projeto é estável.
Y: Apenas incrementa quando é realizada a alteração ou adição de alguma nova funcionalidade.
Z: Apenas incrementa quando são realizadas correções ou alterações no código.