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 |
| Docker | 17.06.2-ce | Ferramenta de isolamento de ambiente |
| Docker-Compose | 1.16.0 | Ferramenta de gerenciamento de containers Docker |
| Git | 2.4.7 | Ferramenta para versionamento |
| GitHub | - | Local de hospedagem do repositório do projeto |
| Heroku | - | Ferramenta para deploy contínuo |
| Travis | - | Ferramenta para integração contínua |
2.1 Atom Editor de texto adotado como padrão pela equipe. É utilizado este editor de texto devido aos seus plugins que auxiliam de maneira impar 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.
2.2 Docker
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.
2.2 Docker-Compose
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.
2.3 Git
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.
2.4 GitHub
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.
2.6 Heroku 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.
2.7 Travis CI
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".
