Plano de Gerenciamento e Configuração de Software
| Data | Versão | Descrição | Autor |
|---|---|---|---|
| 25/08 | 0.1 | Política de commits | Ronyell |
| 25/08 | 0.2 | Política de Aprovação do código | João Paulo |
| 27/08 | 0.3 | Política de Branches | João Paulo |
| 27/08 | 0.4 | Introdução | Thiago Nogueira |
| 27/08 | 0.4 | Uso de Issues | Ronyell |
| 27/08 | 0.4 | Ferramentas | João Paulo |
| 27/08 | 1.0 | Versão 1 do Documento | João Paulo |
| 11/09 | 1.0 | Adicionando imagem da política de branchs | Thiago Nogueira |
O presente documento tem como objetivos definir as ferramentas que serão utilizadas durante o desenvolvimento do software servindo de suporte para o mesmo. Aqui será abordado também como será os procedimentos de gerência e configuração de software que será seguida no projeto.
| Ferramenta | Versão | Descrição |
|---|---|---|
| Atom | 1.19.6 | Editor de Texto |
| Coverage | 4.4.1 | Ferramenta para execução da switch de teste |
| Coveralls | 1.2.0 | Ferramenta para gerar relatórios de tese |
| CodeClimate | - | Ferramenta para análise estática do código |
| Django | 1.11.4 | Framework para desenvolvimento web |
| Docker | 17.06.2-ce | Ferramenta de isolamento de ambiente |
| Docker-Compose | 1.16.0 | Ferramenta de gerenciamento de containers Docker |
| Flake8 | 3.4.1 | Ferramenta de análise estática do código |
| Git | 2.4.7 | Ferramenta para versionamento |
| GitHub | - | Local de hospedagem do repositório do projeto |
| Heroku | - | Ferramenta para deploy contínuo |
| PostgreSQL | X | Ferramenta gerenciadora de banco de dados |
| Sonar | 4.5.7 | Ferramenta de análise estática de código |
| SourceMeter | 8.2.0 | Plugin de análise estática |
| Travis | - | Ferramenta para integração contínua |
Editor de texto adotado como padrão pela equipe. É utilizado este editor de texto devido aos seus plugins que auxiliam de maneira eficiente no gerenciamento da equipe. É utilizado o plugin do Flake8 que é faz a análise estática do código em tempo real, o que torna o código mais padronizado.
Ferramenta de execução de switch de teste que foi definida como padrão para o projeto. É uma ferramenta que a própria comunidade de Python Django recomenda para realização de testes unitários.
Ferramenta para geração de relatórios de testes que será utilizada para facilitar a visualização dos dados obtidos através dos testes. É uma ferramenta que se tem uma grande adesão por parte da comunidade de desenvolvedores. Esta ferramenta possui uma simplicidade no seu manuseio, mas entrega de uma forma muito clara e simples um relatório sobre os testes.
Ferramenta utilizada para análise estática de código adotada pela equipe. A escolha dessa ferramenta se deu a sua simplicidade de utilização e um diferencial crucial na escolha é por esta ferramenta possuir uma integração com o Github.
Framework voltado para desenvolvimento web, utiliza-se da tecnologia de Python. A escolha desta framework se deu por ela atender todas as necessidades da equipe e satisfazer as necessidades do cliente. Um outro ponto que ajudou na escolha desta ferramenta se deu ao fato da equipe de GPP já possuir algumas experiências com a mesma.
O Docker é um plataforma que permite que a criação, execute e faça deploy de containers. De maneira simples, um container é o empacotamento da sua aplicação mais as dependências dela. A plataforma será utilizada para executar a aplicação sem precisar instalar as dependências de forma direta em uma máquina, assim facilitando o desenvolvimento quando o deploy para o ambiente de produção.
Ferramenta utilizada para a criação de ambientes isolados, que execute e faça deploy de containers. De maneira simples, um container é o empacotamento da sua aplicação mais as dependências dela. A plataforma será utilizada para executar a aplicação sem precisar instalar as dependências de forma direta em uma máquina, assim facilitando o desenvolvimento quando o deploy para o ambiente de produção.
Ferramenta utilizada para análise estática de código adotada pela equipe. A escolha dessa ferramenta se deu por ela possuir a integração com plugins do Átom o que possibilita uma análise em tempo real de como está sendo realizado o código. Está ferramenta também possibilita verificar se a folha de estilo está sendo seguida pelos membros.
Ferramenta utilizada para o versionamento do código será utilizado o Git, consiste em uma ferramenta de controle de versão descentralizada, possibilitando o trabalho cooperativo entre várias pessoas no mesmo código. O método de utilização consiste em realizar as alterações locais versionando o código e quando conveniente é submetido ao repositório remoto.
Ferramenta utilizada para a hospedagem do repositório, controle de versão, revisão de código, marcação de atividades para os membros de time e documentação do projeto.
Ferramenta que será utilizada para realizar o deploy contínuo. É através dessa ferramenta que será possível disponibilizar o projeto em sua versão mais recente na web.
Ferramenta utilizada para análise estática de código adotada pela equipe. A escolha dessa ferramenta se deu por entregar a equipe de GPP algumas métricas que tinham sido estabelecidas no plano de qualidade.
Plugin utilizado na ferramenta Sonar. A utilização deste plugin ocorreu pois, com a utilização do mesmo é possível customizar mais a análise do código fazendo com que o que será analisado será mais preciso e poderá ser utilizado de uma maneira melhor.
Ferramenta utilizada para realizar a integração contínua, é através desta ferramenta que os testes serão executados a cada envio de atualização das branchs(push). O Travis CI também será de extrema importância na checagem de Pull Request e deploy contínuo através do Heroku.
Os commits devem ser feitos de forma sucinta descrevendo o que foi feito, portanto o commit deve ser atômico descrevendo a funcionalidade que foi implementada. Cada commit deve ser ligado a alguma issue aberta no repositório do projeto, logo é necessário iniciar o commit com uma hash indicando qual a issue que o commit está relacionada. As issues representarão casos de uso durante a primeira release e história de usuário na segunda release. A mensagem deve seguir o seguinte padrão:
<#(Número da Issue) - Mensagem com a primeira letra da frase maiúscula, verbo no gerúndio, terminando com ponto final.>.
Exemplo: “#1 - Creating user structure.”
O repositório do projeto contará com duas branches principais para o desenvolvimento, sendo elas: master e devel, e as branches auxiliares contendo as funcionalidades desenvolvidas.
A branch master conterá a versão estável do produto, tendo seu conteúdo proveniente da branch de desenvolvimento (devel) após a aprovação do pull request.Por decisões de projeto, nenhum commit poderá ser feito pelos membros diretamente na branch master.
A branch devel será utilizada para o desenvolvimento do produto, onde a integração das funcionalidades desenvolvidas pela equipe nas branches auxiliares ocorrerá.
As branches auxiliares serão utilizadas para o desenvolvimento das funcionalidades.Essas branches serão nomeadas de acordo com a rastreabilidade e na língua inglesa, tendo o seu padrão de acordo com a metodologia adotada no momento.
Na metodologia tradicional, o nome das branches auxiliares seguirão o padrão de casos de uso.O formato será: UC< número do caso de uso conforme foram priorizados >-< Descrição breve composta pelo nome do caso de uso sempre iniciado com letra maiúscula e em inglês >.
- Exemplo : "UC01-UseCase".
Na metodologia ágil, o nome das branches auxiliares seguirão o padrão de histórias de usuário.O formato será: US< número da história>-< Nome definido para a história pela equipe >.
- Exemplo : "US01-UserStories".
Após o término da funcionalidade, seja ela um caso de uso ou uma história de usuário, o membro responsável por tal funcionalidade deve integrar a branch da funcionalidade a branch devel e requerer um pull request da devel para a branch principal (master), onde o nome do pull request deverá ser igual ao nome da funcionalidade desenvolvida.
Durante a Release 1 o código do pull request deverá ser analisado por algum dos membros da equipe de gerência e caso cumpra as especificações do caso de uso o código será integrado a branch principal.
Durante a Release 2 o código do pull request deverá ser analisado pelo PO e caso cumpra os critérios de aceitação e tasks exigidas pela história de usuário o código será integrado a branch principal. O código só será integrado caso sejam feitos testes do código desenvolvido.
As issues do github serão usadas para se ter um maior controle sobre o que se é desenvolvido, portanto na metodologia tradicional as issues representarão os casos de uso e na metodologia ágil as issues representarão as histórias de usuário.
Na metodologia tradicional as issues serão cadastradas usando o seguinte padrão: UC< número do caso de uso conforme foram priorizados >-< Descrição breve composta pelo nome do caso de uso sempre iniciado com letra maiúscula e em inglês >.
- Exemplo : "UC01-UseCase".
Na metodologia ágil também serão cadastradas as tasks e os critérios de aceitação de cada história de usuário, além dessa ser especificada em voz de usuário. A especificação da história de usuário seguirá o seguinte padrão: Eu, como desejo , para .
- Exemplo: “Eu, como gerente, desejo cadastrar novos produtos, para manter meu estoque sempre atualizado.”
O nome das issues seguirão o padrão de histórias de usuário.O formato será: US< número da história>-< Nome definido para a história pela equipe >.
- Exemplo : "US01-UserStories".
