Planejamento

O GitLab da plataforma Embrapa I/O está adisponível para acesso em:

Ele possui uma ferramenta de gestão de projetos integrada, baseada na metodologia de desenvolvimento ágil Kanban. Assim, é possível planejar as versões do ciclo de vida das aplicações por meio do registro de milestones. As tarefas a serem executadas em cada milestone são registradas e atribuídas por meio de issues.

Atenção! Todo o controle de milestones e issues deverá ser feito pela board do grupo de repositórios (ou seja, o projeto como um todo), e não pela board de um repositório específico. Infelizmente não é possível, na versão atual do GitLab, desativar a gestão do Kanban nos repositórios, o que pode ocasionar alguma confusão.

Para iniciar o planejamento do desenvolvimento, é recomendado estabelecer a versão almejada no ciclo atual de desenvolvimento e registrá-la como um milestone. O nome da versão e, portanto, o nome do milestone, deverá respeitar as regras de nome de versão da plataforma explicitadas na introdução. Por exemplo, se este é o 3º macro-ciclo de desenvolvimento do projeto e se o cronograma deste ciclo de desenvolvimento finaliza em outubro de 2022, poderia ser proposto um milestone denominado “3.22.10”.

As issues que serão registradas para este milestone são organizadas por meio de rótulos (labels). Quando um novo projeto é criado na plataforma, é atribuído um conjunto inicial de labels. Dentre elas, algumas labels irão formar a board do projeto, que possibilitará acompanhar a evolução das issues de seu registro no backlog até a conclusão.

Na board do projeto, mostrada na figura acima, existem 6 (seis) colunas. São elas:

1. Open: Esta é a coluna de backlog do projeto e nela são registradas todas as demandas do projeto (que podem ou não ser atendidas). Existem dois labels disponíveis para qualificar estas demandas: Bug e Request.
2. To Do: Quando a issue sai da coluna de backlog para esta coluna significa que ela será executada. É necessário, portanto, atribuir esta issue a um milestone aberto, atribuir um responsável da equipe pela execução e determinar o prazo limite.
3. Doing: Quando o desenvolvedor responsável pela issue começa a executá-la, ele deve mudá-la para esta coluna.
4. Alpha: Quando a codificação da issue está finalizada ela deve ser disponibilizada para os testes internos mudando para esta coluna.
5. Beta: Após passar pelos testes internos, a issue deve mudar para esta coluna de forma a ser disponibilizada para testes externos.
6. Closed: Quando a issue passa pelos testes externos ela pode ser encerrada. Neste momento é possível atribuir três qualificadores a ela:
   • Release: Ou seja, a implementação está apta a entrar em produção;
   • On Hold: Caso esta issue esteja suspensa; e
   • Invalid: Caso a execução da issue tenha sido cancelada por qualquer motivo.

Como uma issue inicial a ser registrada e atribuída, sugerimos a configuração do error tracking em cada aplicação do projeto. Uma vez configurado, os erros começarão a ser registrados mesmo em ambiente de desenvolvimento.