Gerenciamento de projetos
As seguintes ferramentas serão utilizadas para composição do processo de desenvolvimento:
Essas duas ferramentas vão compor o gerenciamento de versões. Teremos cinco tipos de ramificações no repo:
- master - Contém o código do app que está em produção
- develop - Ramificação intermediária que absorverá várias mudanças de novas implementações de features (equivale a uma milestone)
- feature/desc-issue-#nº - Desenvolvimento de funcionalidade acontece sempre em um branch com essa denominação (equivale a uma issue sem marcação de bugfix)
- hotfix/desc-issue-#nº - Correção de bug que deve ir logo para produção! (equivale a uma issue de bugfix)
- release/vX.X.X - Preparativos para lançar uma nova versão em produção para verificação de bugs e pequenas melhorias
Recomendo muito a leitura do artigo publicado pela equipe do Zenhub para compor o gerenciamento de projeto. Muita coisa aqui é fundamentada nesse artigo: https://www.zenhub.com/guides/project-management-with-zenhub.
Vamos entender melhor o fluxo de execução com a explicação dos boards que compões o board de tarefas:
Todas as tarefas criadas inicialmente são colocadas aqui para serem classificadas posteriormente
Estão agrupadas aqui todas as tarefas de baixa prioridade ou/e alta complexidade que podem ser desenvolvidas em um futuro relativamente distante. É como um repositório de boas ideias de implementação.
São todas as Issues que não couberam no intervalo do Sprint atual, mas ela possuem uma prioridade maior de desenvolvimento
Daqui pra frente estarão todas as Issues que devem ser terminadas até o final do Sprint. Além de agrupadas nessa pipeline essas Issues devem estar agrupadas em uma milestone.
Antes de partir para o desenvolvinto, caso possua desenvolvimento de alguma lógica, deve ser desenvolvido o teste de unidade para tal.
Aqui finalmente consiste no desenvolvimento da aplicação. Ao término será criado uma pull request para essa feature.
Por fim, alguém irá avaliar o código desenvolvido a fim de evitar bugs. Caso a pull request for reprovada a Issue será recolocada no Sprint Backlog. Importante ser cuidadoso pois além de rever o código alguém no futuro terá que avaliar novamente.
Aqui fica o histórico do nosso trabalho. 👌
Uma definição detalhada e clara do que fazer primeiro vai ajudar a todos a manter uma boa produtividade!
Todos os commits devem conter ao final o número da issue!
'commit inicial #1'
Todos os commits!
Documetação - JSDoc
Muito importante comentar todo o código!
Sempre será necessário adicionar a pasta com a documentação criada no arquivo jsdoc.json. Para gerar a documentação veja a opção jsdoc disponível via package.json
Você pode ser a pedra no sapato de alguém 👞
Por isso fique atento se existe alguma tarefa designada para você com a marcação especial block💛 de amarelo. Se houver algum card assim para você, discuta com quem criou essa marcação para você qual o tamanho da necessidade de execução para saber se a prioridade é maior do que o que você está fazendo atualmente.
Certifique se o card já não possui um branch para o desenvolvimento daquela tarefa. Se o card estiver marcado com a tag pull request deny💜 com certeza já existe um branch para tal tarefa, logo use-o: git flow feature pull desc-issue#nº.
Caso não exista um branch para tarefa ela estará marcada como bugfix💔 ou feature💙, logo deve criar uma feature para isso. Todas essas tarefas vão requerir um novo branch feature para resolução, mesmo que seja um bugfix git flow feature start desc-issue-#nº. Fique atento ao número da issue, ela sempre deve ser colocada ao final do nome do branch. Por exemplo o card é a issue 1, logo o nome da feature será primeira-issue-#1.
Sempre que houver uma tag SUPER BUG🍊 para você significa que é uma correção urgente que deve inclusive ser publicada no branch master para ir o mais rápido possível! Para isso crie uma hotfix via git flow: git flow hotfix start vX.X.X+1, se a versão atual é v0.0.1, no hotfix será v0.0.2.
Por fim crie um pull request para o branch em que você produziu seu trabalho e atribua a alguém que não seja você para rever seu código.
Todas as pull requests devem ter o mesmo nome do branch
Para ter certeza que terminou seu trabalho se faça as seguintes perguntas:
- Quais são os requisitos do meu card que eu deveria ter desenvolvido?
- O trabalho que realizei entrega todos eles?
- Rodei todos os testes do projeto e passou em todos?
- Meu código está claro? Qualquer pessoa que ler conseguirá entender facilmente?
- Fiz as documentações corretamente?
- Selecionei corretamente os arquivos para commit?
- Coloquei o código do card na mensagem do commit?
- Escrevi corretamente e de forma clara a mensagem do commit?
- Outra pessoa lendo a mensagem entenderia bem o que foi realizado?
- Eu realizei o commmit?
Sempre ao avaliar o trabalho de alguém além de ser um tanto criterioso, fique atento a descrição da tarefa que irá possuir uma definição de pronto, esse é o objetivo a ser atingido.