Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • W Wiki
  • Project information
    • Project information
    • Activity
    • Labels
    • Planning hierarchy
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 0
    • Issues 0
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Agendamento de Visitas de Escola ao Museu
  • Wiki
  • Wiki
  • Processos

Last edited by Matheu Palheta de Araújo Góes Jun 23, 2023
Page history

Processos

Home Sprints UserStories/Requisitos Processos Arquitetura Configuração Mockups Banco de Dados Horários Disponiveis

Processo de Desenvolvimento

Sumário

  • Git Workflow
  • Matriz de Responsabilidade
  • Plano de Comunicação
  • Plano de Riscos

Git Workflow

Branches

Nomes

Como padrão para nomes de branches, foi decidido o seguinte:

Exemplo de Componentes:

Exemplo de Páginas:

Criação

Para garantir que o processo de desenvolvimento esteja sempre atualizado, lembre-se de executar o seguinte comando na branch dev antes de criar uma branch nova:

git pull origin dev

Depois da execução desse comando é necessário oficialmente criar a Branch, para isso, execute o seguinte comando:

git checkout -b <nomeDaBranch>

Assim que criar a branch, é necessário fazer um pushpara garantir que a mesma estará remota:

git push --set-upstream origin <nomeDaBranch>

Pronto! Agora você já pode começar a programar na sua Branch.

Commits

Para que o código desenvolvido seja salvo em sua branch de maneira remota, é necessário realizar os comandos de commit e push

Salvando Localmente

Para garantir que apenas o código necessário para funcionamento da tarefa lembre-se de realizar o comando add apenas nos arquivos essenciais para a tarefa:

git add <nomeDoArquivo>

Depois de adicionar todos os arquivos que deseja salvar, execute o commando de commit com uma mensagem curta que represente o que foi trabalhado nesses arquivos adicionados:

git commit -m ''

Não hesite em realizar vários commits, assim podemos ter documentado e salvo vários estados do desenvolvimento

Salvando Remotamente

Depois de finalizar o desenvolvimento, envie todos os commits da sua máquina para o servidor remoto. Para isso depois de realizar as etapas de salvamento local, salve remotamente com o comando push:

git push

Merge Requests

Depois de uma task ter sido desenvolvida e estiver pronta de acordo com os critérios de aceitação, é necessário que a mesma seja enviada para a branch de desenvolvimento. Para isso é necessário abrir um Merge Request pela platafora GitLab:

Criando o Merge Request

A criação pode ser realizada na seção Merge Requests do repositório em que a branch foi criada. Clicando no botão New Merge Request siga os seguintes passos:

Revisando o Merge Request

A revisão de merge request pode ser realizada por qualquer desenvolvedor, mas é preciso da aprovação de pelo menos um AGES III ou AGES IV para que a mesma seja incorporada na dev.

Caso haja pendências, relacionadas a documentação do código, padronização ou arquivos enviados, não hesite em realizar um novo commit na branch com as mudanças necessárias antes de realizar a integração.

Matriz de Responsabilidade

Essa matriz foi desenvolvida para ajudar os membros do time a saberem seus papéis na dentro do processo de desenvolvimento.

Atividades AGES I AGES II AGES III AGES IV
Alimentar a wiki R R R R
Definir squads C C C R
Definir marcos da sprint C C C R/A
Quebra de tasks C C C C
Desenvolvimento R R C/R/A C/R/A
Code review C C C/R/A C/R/A
Executar testes funcionais R R A A
Deploy da aplicação I I R R/A
Apresentação da review C C C R
  • I: Deve ser informado
  • C: Deve ser consultado
  • R: Responsável
  • A: Aprova

Plano de Comunicação

Evento Descrição Responsável Envolvidos Frequência Duração

Plano de Riscos

Risco Plano Estrategia
Falha na comunicação ou com cliente Definir passos junto ao time Mitigar
Falta de motivação ou empenho para fazer as atividades Conversar abertamente com os colegas e definir um plano de ação apartir da conversa Mitigar
Falta de conhecimento nas tecnologias Administrar estudos dirigidos e dojos e ajustar times de acordo com o conhecimento dos membros Estudo/Organização
Conflito na execução de atividades relacionadas Estabelecer um canal de comunicação claro e transparente entre as equipes envolvidas. Chamar membros das equipes envolvidas para ajudar no merge. Comunicação/Organização
Alunos não indo nas aulas Entrar em contato com amigos ou com a coordenação da ages para falar com o aluno e entender sua situação. Comunicação
Atraso nas entregas Analizar o motivo do atraso e mitigar na proxima sprint. Deixar claro ao cliente o atraso nas atividades. Mitigar

EAP

EAP_1_

Clone repository
  • Processos
  • arquitetura
  • banco_dados
  • configuracao
  • Home
  • horarios
  • mockups
  • requisitos
  • sprints