Software para Controle de Processos - Defensoria Pública do Paraná
Esclarecimentos gerais relacionados a documentação:
-
1.1 Nomenclaturas:
- Issues: tarefas
-
1.2 Siglas:
- PR: Pull Request
-
1.3 Notas Gerais:
- Em comandos, os colchetes
[]
delimitam que alguns conteúdos devem ser preenchidos em seu lugar; - A distro Ubuntu 16.04 foi utilizada como base de referência para a elaboração desta documentação, em outras distribuições podem ocorrer pequenas variações.
- Em comandos, os colchetes
-
2.2 Levantamento e distribuição de tarefas:
-
2.2.1. Draft (Github):
Consiste no levantamento de demanda semanal em reunião de equipe técnica com equipe de produto, onde são debatidas e anotadas todas as solicitações para serem convertidas em tasks posteriormente.
-
2.2.2. Tasks (Waffle):
São as menores fragmentações do processo, são as tarefas técnicas executadas para que uma determinada funcionalidade seja implementada, sendo que essas nem sempre são independentes, e são necessárias diversas tarefas técnicas para completar um item de checklist do roadmap.
-
-
2.3 Ciclo de vida de Tarefas:
-
Para cada tarefa há um prazo máximo de execução de 5 dias;
-
Caso a execução de uma tarefa ultrapasse 5 dias a mesma deve ser reavaliada;
-
Tarefas devem ser quebradas em caso de:
- Tarefas muito grandes;
- Tarefas que modifiquem diversas áreas distintas do projeto;
- Tarefas em que a execução ultrapasse os 5 dias.
1. Iniciada em colunas To do: (Random, Backend, Frontend) 2. Executada pelo Desenvolvedor (in progress) 3. Enviada para Revisão de código pela equipe (review) 4. Marcada como concluída (done)
-
-
2.4 Revisão de Pull Request:
- As revisões de Pull Request devem ser feitas exclusivamente através do Github;
- Comentários devem ser feitos na Pull Request e avisados via Slack;
- É proibido realizar merge de Pull Request sem responder aos comentários;
-
2.5 Solicitações no Slack: utilizamos por padrão flags de classificações no início de cada solicitação.
- REVIEW: a notificação de REVIEW, é direcionada para o channel correto, de acordo com a categoria.
Ex.: @here: gianlucabine needs a *REVIEW*: https://github.com/sices/C3DSU/e-DefPR/pull/1/files
Para responder uma solicitação utilizamos por padrão o nome de usuário junto a resposta.
Ex.: @gianlucabine [MESSAGE]
Nota: Para respostas curtas de confirmação pode ser utilizado apenas
:+1:
-
3.1 Git e Github:
$ sudo apt install git
$ git config --global user.email "[email protected]" $ git config --global user.name "Full Name"
$ ssh-keygen -t rsa -b 4096 -C "[email protected]" $ cat ~/.ssh/id_rsa.pub
$ git clone [email protected]:C3DSU/e-DefPR.git
-
3.2 Bash Profile:
$ sudo vim ~/.profile
export EDEF_PATH=[PROJECT_PATH] source $EDEF_PATH/devops/config/variables export PATH=$PATH:$EDEF_PATH/devops
Nota: lembre-se de substitir
[PROJECT_PATH]
pelo caminho do projeto.$ source ~/.profile
$ echo $PATH | grep edef
Nota: caso o comando acima não possua retorno revise os passos de instalação e reinicie o sistema operacional.
Processo automatizado:
1. Executar: edef-issue-start xxx, onde xxx se refere ao número da tarefa no Waffle.
2. Efetuar as modificações no código-fonte.
3. Executar: git add [ARQUIVO INDIVIDUAL ou LISTA DE ARQUIVOS].
- IMPORTANTE: Não recomendo o uso de: 'git add .'
4. Executar: git commit -m "MENSAGEM EXPLICATIVA" após cada 'git add [ARQUIVO INDIVIDUAL ou LISTA DE ARQUIVOS]' do passo 6.
- IMPORTANTE: Na "MENSAGEM EXPLICATIVA" explicar de forma resumida o que foi modificado nos arquivos que que foram adicionados no 'git add'.
5. Executar: git push origin issue#xxx, onde xxx se refere ao número da tarefa no Waffle.
6. Executar: edef-issue-request-review auto ou edef-issue-request-review manual (auto cria a PR automaticamente e o manual redirecionada para a página do GitHub)
7. Comunicar no channel o link da PR pedindo review de código.
8. Esperar pelo menos 1 ou 2 Approves e após isso realizar o merge no site do GitHub.
- IMPORTANTE: Caso as modificações foram complexas e/ou muito imporantes requisitar mais Approves do que somente 2.
9. Ir na página da Pull Request no GitHub e realizar o merge.
Processo manual:
1. Comunicar no channel apropriado (backend, frontend, random) o início da tarefa
2. Executar: git pull origin master
3. Executar: git checkout -b issue#xxx, onde XXX é o numero da issue no Waffle.
4. Executar: git push --set-upstream origin issue#xxx, onde XXX é o numero da issue no Waffle.
5. Mover a tarefa para a coluna In-progress no Waffle caso não for movida automaticamente.
6. Efetuar as modificações do código fonte.
7. Executar: git add [ARQUIVO INDIVIDUAL ou LISTA DE ARQUIVOS].
- IMPORTANTE: Não recomendo o uso de: 'git add .'
8. Executar: git commit -m "MENSAGEM EXPLICATIVA" após cada 'git add [ARQUIVO INDIVIDUAL ou LISTA DE ARQUIVOS]' do passo 6.
- IMPORTANTE: Na "MENSAGEM EXPLICATIVA" explicar de forma resumida o que foi modificado nos arquivos que que foram adicionados no 'git add'.
9. Executar: git push origin issue#xxx, onde xxx se refere ao número da tarefa no Waffle..
10. Ir na página do repositório no GitHub na parte de branches e criar a PR (Pull Request).
- IMPORTANTE: Na descrição da PR colocar: fixed #XXX, onde XXX é o numero da issue no Waffle.
12. Comunicar no channel o link da PR pedindo review de código.
13. Esperar pelo menos 1 ou 2 Approves e após isso realizar o merge no site do GitHub.
- IMPORTANTE: Caso as modificações foram complexas e/ou muito imporantes requisitar mais Approves do que somente 2.
14. Ir na página da Pull Request no GitHub e realizar o merge.
15. Executar: git checkout master
16. Executar: git pull origin master
17. Executar: git branch -d issue#xxx.
Frontend:
Dentro da pasta Frontend
1. yarn install
2. yarn start
Backend:
Dentro da pasta Backend
1. composer install
2. php artisan migrate:refresh
3. php artisan migrate
4. php artisan passport:install
5. php artisan db:seed
6. php artisan serve
-
6.1 Ambientes:
local
: servidor local de desenvolvimento, configurado na máquina de cada desenvolvedorproduction
: servidor remoto de produção, base final de uso de deploy manual
-
6.2 Pastas raiz:
backend
: pasta backend do projeto, contendo arquivos de models e controllersfrontend
: pasta frontend do projeto, contendo arquivos de viewsdevops
: pasta de uso geral de devops, como operações de ecossistema, processos, etcdocs
: além doREADME.md
, utilizamos essa pasta para documentações de arquivos e UML
-
7.1 A equipe:
Backend developer Slack: @gianlucabine Github: @Pr3d4dor E-mail: [email protected]
Backend developer Slack: @envikeyy Github: @EnViKeyy E-mail: [email protected]
Frontend developer Slack: @HGardin Github: @HigorG E-mail: [email protected]
Professor Slack: @mmiazaki Github: @hmmiazaki E-mail: [email protected]
Professor Slack: @marcosquinaia E-mail: [email protected]
Backend developer Slack: @Davi Bastos Github: @dav3sk E-mail: [email protected]
Backend developer Slack: @Enrique Augusto da Roza Github: @hdoidao E-mail: [email protected]
Slack: @Luiz Eduardo Chicouski da Cruz Github: @SUdoWinchester E-mail: [email protected]
Fullstack developer Slack: @paulopieczarka Github: @paulopieczarka E-mail: [email protected]
Frontend developer Slack: @agueths Github: @agueths E-mail: [email protected]
Backend developer Slack: @Pimenta Github: @Pimenta1 E-mail: [email protected]