Home | Escopo e Cronograma | Processo | Design/Mockups | Configuração | Arquitetura | Código | BD | Qualidade | Utilização |
---|
Processo de Desenvolvimento
Sumário
Git Workflow
Branches
Nomes
Como padrão para nomes de branches, foi decidido o seguinte:
<tipoDeItem>-<nomeDoItem>
Exemplo de Componentes:
component-navBar
component-slider
Exemplo de Páginas:
page-recipes
page-creations
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 push
para 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 'descrição da tarefa em português'
Não hesite em realizar vários commits, assim podemos ter docuemntado 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:
- Selecionar a branch de origem (sua branch de desenvolvimento);
- Selecionar a branch de destino (branch dev);
- Selecione
Compare branches and continue
- Em
Title
, escreva um título que descreva a funcionalidade adicionada ou bug corrigido; - Em
Description
, escreva uma descrição com uma breve justificativa nos arquivos que foram alterados; - Caso a tarefa seja visual (criação de componente/tela, correção de bug) adicione um gif exemplificando o uso (se considerar necessário);
- Na seção
Assignee
, selecioneAssign to me
para que fique registrado quem foi o responsável pelo desenvolvimento daquela tarefa (a pessoa selecionada será chamada caso o revisor tenha dúvidas sobre a tarefa); - Em
Milestone
selecione a Sprint em que a tarefa foi realizada; - Em
Labels
selecione qual é o tipo de tarefa que foi realizada; - Por último, revise se os arquivos que estão sendo enviados estão corretos e clique em
Submit Merge Request
.
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.
Na hora de revisar o Merge Request, entre na branch em sua máquina e teste a funcionalidade/bug/componente/tela de acordo com os critérios de aceitação apresentados no Airtable.
Caso haja pendências, relacionadas a documentação do código, padronização ou arquivos enviados, não exite 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 |
---|---|---|---|---|---|
1ª Reunião com o Cliente | Primeiro encontro entre o time e os stakeholders do projeto. Nesse encontro são apresentados os principais itens do projeto e a ideia geral. Também são realizados questionamentos sobre o que foi apresentado, com a finalidade de ajudar nas definições dos requisitos do projeto em conjunto com o cliente. | Cliente(s) | AGES I, II, III, IV e Cliente(s) | Uma vez (início do projeto) | 1 hora e 30 minutos |
Daily | Cada membro da equipe atualiza os outros sobre o que produziu desde o último encontro síncrono. o que visa fazer em seguida, e se tem alguma dificuldade, com o objetivo de que possam ser discutidos e resolvidos. | AGES IV | AGES I, II, III e IV | Duas vezes na semana | 15 minutos |
Review | Momento em que é apresentado o que foi desenvolvido e revisa-se o trabalho realizado. Onde podemos ver o que deu certo e o que precisamos melhorar em conjunto com o cliente. | AGES IV | AGES I, II, III, IV e Cliente(s) | Sempre no final das Sprints. | Aproximadamente 1 hora |
Planning | É realizado o planejamento do que irá ser feito durante a Sprint que se inicia. Realizada a priorização das User Stories que estão no Product Backlog para o Sprint Backlog atual do projeto. | AGES IV | AGES I, II, III e IV | No início das Sprints. | 30 minutos - 1 hora |
Retrospective | Momento em que os membros são incentivados para expor o que gostaram, o que não gostaram, com quem gostaram de trabalhar e qualquer comentário construtivo sobre a Sprint que se encerra. Como resultado levantamos ações para melhorar nossa experiência na AGES. | AGES IV | AGES I, II, III e IV | No final das Sprints. | 30 minutos - 1 hora |
Code Review | Processo assíncrono para revisão de código | AGES IV | AGES IV e III | Sempre que um merge request é aberto | 5 - 30 minutos |
Plano de Riscos
Risco | Prevenção | Contingência | Estratégia |
---|---|---|---|
Atingir limite de uso gratuito da AWS (Exemplo) | Utilizar servidores apenas para validação, desligando-os quando não utilizados (Exemplo) | Alterar ambiente para outra conta de usuário (Exemplo) | Transferir (Exemplo) |
TBD... | TBD... | TBD... | TBD... |