Skip to content

Software para Controle de Processos - Defensoria Pública do Paraná

License

Notifications You must be signed in to change notification settings

FabSoftUnicentro/e-DefPR

Repository files navigation

e-DefPR

Software para Controle de Processos - Defensoria Pública do Paraná

Sumário

  1. Guia Geral
  2. Workflow
  3. Instalação da Aplicação
  4. Execução e Gerenciamento de Tarefas
  5. Estrutura
  6. Sobre

Guia Geral

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.

Workflow

  • 2.1 Ferramentas:

  • 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.
      Execução de tarefas em fluxo normal:
      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:

Instalação da Aplicação

  • 3.1 Git e Github:

    • 3.1.1. Instalando o Git
    $ sudo apt install git
    
    • 3.1.2. Configurando informações do Git
    $ git config --global user.email "[email protected]"
    $ git config --global user.name "Full Name"
    
    • 3.1.3. Criando chave para acesso SSH
    $ ssh-keygen -t rsa -b 4096 -C "[email protected]"
    $ cat ~/.ssh/id_rsa.pub
    
    • 3.1.4. Inserindo chave SSH no Github

      Tutorial Github

    • 3.1.5. Clonando o repositório do Github
    $ git clone [email protected]:C3DSU/e-DefPR.git
    

  • 3.2 Bash Profile:

    • 3.2.1. Abra o Arquivo .profile com seu editor (Vim, Nano ou outro)
    $ sudo vim ~/.profile
    
    • 3.2.2. Adicione ao final do arquivo as linhas
    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.

    • 3.2.3. Carregue as alterações do arquivo bash
    $ source ~/.profile
    
    • 3.2.4. Na variável PATH agora devem aparecer alguns caminhos relacionados a pasta do projeto
    $ echo $PATH | grep edef
    

    Nota: caso o comando acima não possua retorno revise os passos de instalação e reinicie o sistema operacional.

Execução e Gerenciamento de Tarefas

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.

Inicialização

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

Estrutura

  • 6.1 Ambientes:

    • local: servidor local de desenvolvimento, configurado na máquina de cada desenvolvedor
    • production: 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 controllers
    • frontend: pasta frontend do projeto, contendo arquivos de views
    • devops: pasta de uso geral de devops, como operações de ecossistema, processos, etc
    • docs: além do README.md, utilizamos essa pasta para documentações de arquivos e UML

Sobre

  • 7.1 A equipe:

    • Gianluca Bine

    Backend developer
    Slack: @gianlucabine
    Github: @Pr3d4dor
    E-mail: [email protected]
    
    • Jean Pierri

    Backend developer
    Slack: @envikeyy
    Github: @EnViKeyy
    E-mail: [email protected]
    
    • Higor Gardin

    Frontend developer
    Slack: @HGardin
    Github: @HigorG
    E-mail: [email protected]
    
    • Prof. Mauro Miazaki

    Professor
    Slack: @mmiazaki
    Github: @hmmiazaki
    E-mail: [email protected]
    
    • Prof. Marcos Antônio Quináia

    Professor
    Slack: @marcosquinaia
    E-mail: [email protected]
    
    • Davi Bastos

    Backend developer
    Slack: @Davi Bastos
    Github: @dav3sk
    E-mail: [email protected]
    
    • Enrique Augusto da Roza

    Backend developer
    Slack: @Enrique Augusto da Roza
    Github: @hdoidao
    E-mail: [email protected]
    
    • Luiz Eduardo Chicouski da Cruz

    Slack: @Luiz Eduardo Chicouski da Cruz
    Github: @SUdoWinchester
    E-mail: [email protected]
    
    • Paulo Henrique Pieczarka da Silva

    Fullstack developer
    Slack: @paulopieczarka
    Github: @paulopieczarka
    E-mail: [email protected]
    
    • Alexandre Gueths

    Frontend developer
    Slack: @agueths
    Github: @agueths
    E-mail: [email protected]
    
    • Gabriel Pimenta

    Backend developer
    Slack: @Pimenta
    Github: @Pimenta1
    E-mail: [email protected]
    

About

Software para Controle de Processos - Defensoria Pública do Paraná

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published