Plano de Gerenciamento de Configuração de Software

Histórico de modificações

Data	Versão	Descrição	Autor
25/09/2017	0.1	Adicionando Introdução, Item de configuração, Ferramentas, Gerenciamento de repositórios de código e documentação,Monitoramento e Controle e Referências	Álax Alves
26/09/2017	1.0	Revisão do Documento	Matheus Richard

Sumário

1. Introdução
2. Item de configuração
3. Ferramentas
   1. Docker
   2. Travis CI
   3. Git / GitHub
4. Gerenciamento de repositórios de código
   1. Política de Commits
   2. Política de Branches
   3. Utilização das Branches
   4. Política de Aprovação
   5. Uso das Issues
5. Gerenciamento repositórios de documentação
   1. Política de Commits
   2. Política de Branches
   3. Versionamento do Documento
6. Monitoramento e Controle
7. Referências

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 - Item de configuração

       Um item de configuração é um artefato produzido no projeto que necessite de gerenciamento (itSMF, 2002). Portanto, para determinar quais ferramentas serão utilizadas e métodos de versionamento, determina-se quais serão os artefatos que se tornarão itens de configuração. Para o contexto deste projeto, serão considerados dois principais itens de configuração a serem mantidos:

• Documentos: Arquivos em texto contendo planejamentos, relatórios de reunião, descrição do produto e projeto e outros semelhantes.
• Código: É um dos artefatos resultantes da execução deste projeto, sendo composto por conjunto de arquivos texto, que conterão código de uma ou mais linguagens de programação, HTML ou CSS.

3 - Ferramentas

3.1 - Docker

       Utilizado para automatizar a configuração do ambiente de desenvolvimento, garantir que os desenvolvedores trabalhem em ambientes padronizados e eliminar problemas de compatibilidade

       O Docker possibilita o empacotamento de uma aplicação ou ambiente inteiro dentro de um container, e a partir desse momento o ambiente inteiro torna-se portável para qualquer outro Host que contenha o Docker instalado. Isso reduz drasticamente o tempo de deploy de alguma infraestrutura ou até mesmo aplicação, pois não há necessidade de ajustes de ambiente para o correto funcionamento do serviço, o ambiente é sempre o mesmo, configure-o uma vez e replique-o quantas vezes quiser.

3.2 - Travis CI

       A ferramenta web Travis CI será utilizada no projeto para integração contínua nos repositórios do GitHub, e será configurada em todas as branches de ambos os repositórios de desenvolvimento.

3.3 - Git / GitHub

       O Git será a ferramenta utilizada para controle de versões e gerenciamento do código produzido e da própria documentação inerente ao código, a qual será armazenada na estrutura de uma Wiki. Para hospedagem do código fonte, documentações e outros itens do projeto será utilizado um repositório no Github.

4 - Gerenciamento de repositórios de código

       Serão mantidos dois repositórios principais no Github:

• O BackEnd mantido junto a organização da Faculdade Gama no Github para projetos desenvolvidos pelas disciplinas de Gestão de Portfólio e Projetos de Software e Métodos de Desenvolvimento de Software, onde está disponível o código fonte da API do sistema. Serão mantidos, também, arquivos de configuração de ambientes de desenvolvimento e integração, arquivos de prototipagem e a documentação em geral.
• O FrontEnd também mantido junto a organização da Faculdade Gama no Github para projetos desenvolvidos pelas disciplinas de Gestão de Portfólio e Projetos de Software e Métodos de Desenvolvimento de Software. Esse repositório contém o aplicação em Vue.js que consome a API.

4.1 - Política de Commits

       Os commits realizados no repositório do projeto deverão seguir o padrão definido abaixo:

• Mensagem do commit em inglês, com verbo no gerúndio indicando o propósito do commit, iniciado por letra maiúscula e sem ponto final.
• Ao commitar utilizar-se da linha de comando $ git commit -s

Exemplo de mensagem de commit: Updating readme.md

4.2 - Política de Branches

       A branch master será sempre atualizada a partir da branch devel deste repositório. As branchs de desenvolvimento das funcionalidades deverão ser criadas sempre a partir da branch devel. Uma vez que as funcionalidades estejam concluídas deve ser aberto o Pull Request para a branch devel.

       A integração contínua será configurada nas em todas as branches, e os Pull Requests só serão integrados à devel e master uma vez que as builds estejam passando.

       Nos pontos de entrega, será aberto um "Pull Request" da branch devel para a branch master do repositório oficial. Desta forma visa-se garantir a estabilidade da branch master do repositório oficial, que será utilizada para deploy automatizado da aplicação.

4.3 - Utilização das Branches

       Sempre que uma equipe de desenvolvimento for começar a trabalhar em algum Caso de Uso ou História de Usuário, deve-se criar a branch a partir da master, com o padrão definido abaixo:

Padrão para Casos de Uso:

• Nome da branch iniciada com UCX, onde X é o número de identificação do Caso de Uso. Em seguida o nome do Caso de Uso, com palavras em minúsculo e separadas por underline.
• Ex: UC01_manter_usuario

Padrão para Histórias de Usuário:

• Nome da branch iniciada com USX, onde X é o número de identificação da História de Usuário. Em seguida o nome da História de Usuário, com palavras em minúsculo e separadas por underline. Para Histórias Técnicas deve-se aplicar o mesmo padrão, porém substituindo USX por TSX, sendo X o número de identificação da História Técnica.

• Ex: US10_avaliar_jogo

• Ex: TS3_refatorar_classe_jogo

4.4 - Política de aprovação

       Para que o "Pull Request" das funcionalidades seja devidamente aceito, esta deve estar devidamente testada e conforme os padrões de commit e estilo de código. Além disso, a build da Integração Contínua deve estar "passando" para tal funcionalidade.

4.5 - Uso das Issues

       Durante a segunda release, deverão ser utilizadas issues para mapear as demandas das Histórias de Usuário, de modo que cada issue deve ser identificada com labels que facilitem o seu mapeamento com as Histórias. Haverão labels para cada história desenvolvida, e além destas haverão as seguintes label padrão:

• Bug;
• Documentation;
• Software Configuration Management;
• Extras;

       Desta forma, por exemplo, caso uma issue esteja mapeando um bug relacionado à História Manter Usuário, deve adicionar à ela as tags Bug e Manter Usuário.

5 - Gerenciamento repositórios de documentação

       A documentação do projeto ficará armazenada no repositório do projeto, chamado de Falko-2017.2-BackEnd/wiki.

5.1 - Política de Commits

       Os commits realizados no repositório do projeto deverão seguir o padrão definido abaixo:

• Mensagem do commit em inglês, com verbo no gerúndio indicando o propósito do commit, iniciado por letra maiúscula e sem ponto final.
• Ao commitar utilizar-se da linha de comando $ git commit -m

5.2 - Política de Branches

       A branch master será sempre utilizada para manter os documentos. Não há restrições quanto a criação novas branches para propósitos de edição, adição ou exclusão de artefatos. Deve-se saber que contribuidores externos sem permissão de escrita no repositório, devem submeter um merge request a partir de um repositório fork.

5.3 - Versionamento do documento

       Deve-se manter uma tabela de histórico no topo de cada documento elaborado, esta tabela possibilitará descobrir quais alterações foram feitas no documento e quem foi o autor destas. A tabela de histórico deve ser no seguinte padrão baseado nos templates de RSC (2001):

Data	Versão	Descrição	Autor
DIA/MÊS/ANO que foi realizada a alteração	Versionamento do documento, seguindo o padrão 0.X,1.X, 2.X, ..., N.X no qual muda-se de versão quando há alterações substanciais no artefato desde sua versão N.0	Descreve qual seção foi modificada ou qual alteração foi feita no artefato	Nome do autor/responsável pela alteração

6 - Monitoramento e controle

       A equipe de gerenciamento do projeto deverá manter sobre revisão constante todos os artefatos produzidos para verificar se estão de acordo com o que foi estabelecido neste planejamento. Caso alguma política tenha sido violada, ou o não seguimento dos padrões aqui estabelecidos, o responsável será notificado e deverá corrigir imediatamente para manter a padronização nos itens de configuração.

7 - Referências

itSMF. International: IT Service Management, an introduction. London: Van Haren Publishing, 2002. RSC. Rational Software Corporation. Templates em HTML. 2001. Acessado em: 24 de Março de 2017. Disponível em: http://www.funpar.ufpr.br:8080/rup/webtmpl/index.htm.