Configuração de Software e Políticas do Repositório - Desenho2018-1/pan-pan GitHub Wiki

Histórico de modificações

Data Autor
18/03 Pablo Diego
24/03 Pablo Diego
25/03 Pablo Diego
26/03 Álax Alves
27/03 Roger Lenke
31/03 Roger Lenke
01/04 Josué Nascimento
07/04 Fabíola Fleury

1. Introdução

Neste documento, será descrito o planejamento dos principais itens relevantes em relação a Gerência de Configuração do Projeto. Objetiva-se por meio deste, definir as Políticas de Configuração do projeto, que serão utilizadas ao longo do desenvolvimento e manutenção do mesmo.

2. Objetivo

O objetivo deste documento é orientar a equipe na contribuição com o repositório e o projeto, apresentando padrões, políticas, ferramentas, instruindo sobre o ambiente de desenvolvimento e qualquer atividade de configuração necessária.

3. Itens de configuração

Os itens de configuração para este projeto são o código disposto no repositório e a documentação apresentada na wiki. Sendo eles:

  • Documento: Arquivo de texto contendo os planejamentos, descrição do produto e projeto, relatos de reunião ou do fluxo de projeto.
  • Código: Artefato composto por um conjunto de arquivos de texto, contendo código de uma ou mais linguagens de programação ou marcação.

4. Ferramentas

Para o projeto são utilizadas algumas ferramentas. A tabela a seguir relaciona as ferramentas utilizadas e sua respectiva função.

Ferramenta Descrição de Uso
Git Ferramenta utilizada para controle de versões e gerenciamento do código produzido e da própria documentação inerente ao código
Github Responsável pela hospedagem do código fonte, documentações e outros itens do projeto
Docker Utilizado para automatizar a configuração do ambiente de desenvolvimento, garantir que os desenvolvedores trabalhem em ambientes padronizados e eliminar problemas de compatibilidade
Zenhub Utilizado para gerenciar as issues e milestones do projeto
Travis CI Utilizado para manter a integração contínua no repositório do GitHub, e será configurado em todas as branches

5. Repositório de código

5.1 Política de Commits

Adota-se para este projeto padrões para o comentário e execução dos commits. O idioma padrão para efetuar commits neste repositório é o inglês. As mensagens devem ser sucintas e expressarem de forma clara e objetiva a ação do commit.

Como exemplo, considere o trabalho da construção de uma tela inicial da aplicação. O commit deverá ser efetuado como segue:

git commit -m "Create new home Screen"

Atente ainda para os seguintes aspectos:

  • O commit deve iniciar com letras maiúsculas.
  • O commit deve iniciar com verbo no infinitivo.

Caso o trabalho tenha sido realizado por mais de um autor. O commit deverá possuir a assinatura das pessoas envolvidas. Nestes casos deve-se utilizar a flag --author ou a opção signed-off-by, de maneira que o trabalho de todos desenvolvedores possa ser refletido por sua contribuição. Como exemplo, veja as instruções:

git commit --author

git commit -s

5.2 Política de Branches

O repositório possui uma branch master, que possui objetivo de manter a versão estável do projeto. Possui também uma branch para desenvolvimento chamada devel, cujo objetivo é manter-se atualizada. Desta forma nenhum commit deve ser efetuado diretamente nestas branchs. As alterações devem ser criadas inicialmente em branchs de funcionalidades ou de configuração e correção, toda branch de funcionalidade deve ser criada a partir da branch devel.

A imagem a seguir, ilustra como deve ser a organização das branchs e os eventos de criação e merge de acordo com o Git Flow. https://leanpub.com/site_images/git-flow/git-workflow-release-cycle-2feature.png

Como pode ser visto, após a etapa de desenvolvimento em uma branch de funcionalidade ser concluída, deve ser submetido um pull request antes do merge da mesma. O pull request deve ser conferido por um membro da equipe e se estiver em conformidade, então o pull request é aceito.

5.3 Padrões para criação e uso das branches

Deve-se criar novas branches para trabalho em Histórias de usuário seguindo padrão GitFlow. Estas devem ser galhos da branch devel, e devem seguir a nomenclatura indicada abaixo, redigidas no idioma inglês.

5.4 Padrões para Histórias de Usuário

Branches de Histórias de Usuário devem seguir a convenção cammel case e usar o prefixo US. Exemplo: US_[NomeDaUSEmCamelCase].

5.5 Padrões para Correções e Configuração

Seguindo o padrão para as branchs de correção de algum defeito ou configuração de ferramentas novas, o padrão para nomenclatura será FIX_[NomeDaCorreçãoOuConfiguracao]

5.6 Padrões para tasks referentes a Histórias de Usuário

Branches de tasks devem seguir a convenção cammel case e usar o prefixo TK. Exemplo: TK_[NomeDaTKEmCamelCase].

5.7 Padrões para Historias Técnicas

Branches de Histórias Técnicas devem seguir a convenção cammel case e usar o prefixo TS. Exemplo: TS_[NomeDaTSEmCamelCase].

6. Repositório de documentação

O repositório de documentação é encontrado na wiki do projeto. Seu objetivo é armazenar a documentação proveniente do projeto, bem como, as práticas adotadas pela equipe de desenvolvimento. Este repositório segue especificações semelhantes ao repositório de código. Os commits devem seguir o mesmo padrão. Porém, os documentos devem ser mantidos na branch master e não há instruções a respeito da criações de novas branches.

7. Monitoramento e controle

O monitoramento e o controle de todas as atividades do projeto será feito somente pelo repositório do github. O processo abaixo exemplifica como é feito esse controle. Segue também uma descrição de suas atividades.

images/activity-control.png

7.1 Atividades do processo

7.1.1 Definir milestone

O planejamento do Projeto Pan Pan será realizado por milestones, que representarão releases num roadmap. Uma milestone é um marco no ciclo de vida de um projeto. Ela indica em qual ponto no projeto haverá uma mudança de fase, uma grande entrega, ou outro evento importante. A página de milestones do projeto representará, no Pan-Pan, um roadmap, que é o planejamento a longo prazo das entredas de um projeto. Mais informações sobre o artefato roadmap podem ser encontradas na página das metodologias utilizadas.

Neste projeto, as milestones são definidas de acordo com o Plano de Ensino da Disciplina de Arquitetura e Desenho de Softwaare. Novas milestones podem ser criadas de acordo com mudanças neste plano de ensino, ou de acordo com novas demandas da equipe.

7.1.2 Definir atividades da milestone

Esta atividade tem como objetivo escolher quais serão as atividades que vão ser realizadas no prazo de uma milestone. A escolha destas atividades se dará com a demanda de artefatos ou de acordo com as Features do Projeto..

A demanda de artefatos está ligada a fase de planejamento de um projeto. Ela descreve quais são os artefatos exigidos pelo Plano de Ensino, ou artefatos que a equipe de projeto acha necessário ter. Um artefato é um conjunto de informações auto-descritivas e concretas que auxiliam a um gerente de projeto a gerenciar esse mesmo projeto (Nigam & Caswell, 2003). Exemplos de artefatos são os planos de gerenciamento, o documento de requisitos, ou mesmo este cronograma.

Uma feature é uma funcionalidade que o usuário poderá realizar no sistema. As features do Pan-Pan serão concluídas por meio da realização de Histórias de Usuário, que serão implementadas pela equipe para entregar o valor da feature.

7.1.3 Priorizar atividades da milestone

As atividades da milestone devem ser priorizadas, de maneira que sempre sejam considerados dois aspectos no momento de decidir qual atividade será realizada primeiro:

  1. Essa atividade é importante para o cliente do projeto?
  2. Essa atividade é importante para a equipe do projeto?

As atividades que agregarem mais valor para o cliente do projeto serão alocadas prioritariamente em relação às atividades que são mais importantes para a equipe. É importante saber que está estrutura de priorização pode mudar de acordo com a dependência entre atividades, ou de acordo com novas entregas adicionadas ao Plano de Ensino.

Para a priorização das features, foi utilizado o método Moscow. Este método e sua aplicação podem ser encontrados no Documento de Engenharia de Requisitos e no Documento de Requisitos do Projeto.

A decisão da importância de uma atividade é papel do Product Owner.

7.1.4 Desenvolver Atividades da Milestone

A atividade de desenvolver atividades da milestone indica que os membros da equipe devem realizar as atividades da milestone em ordem de priorização, de maneira a sempre realizar o que é mais importante no momento. É importante perceber que as atividades podem ser feitas em paralelo, para que o conteúdo da milestone seja finalizado o mais rápido possível.

Outro fator importante a se perceber é a necessidade da atualização do kanban no desenvolvimento e finalização de uma atividade da milestone. Isto é importante porque é pelo kanban que será feito o controle das tarefas do projeto, assim como o controle do fluxo de atividades e a identificação de qual o estado de cada atividade causa maior gargalo.

Uma explicação de como funciona o kanban e seu contexto no projeto pode ser encontrada no Documento de Metodologias do Projeto.

8. Referências