Plano de Gestão e Configuração de Software
1. Introdução
O presente documento tem como finalidade abordar os procedimentos de gerência e configuração de software a serem seguidos no projeto.
2. Políticas
Política de Commits
Os commits devem ser atômicos e seu comentário deve descrevê-lo de forma sucinta. O texto deve descrever o que foi produzido, de forma resumida e em português, sem acentuação, com o tempo verbal no particípio. Além disso, deve conter o número de sua issue correspondente, no seguinte formato:
Repositorio de Documentação
[#<id da issue>] <Texto começando com letra maiúscula, verbo no particípio, e com final>.
Exemplo:
[#1] Criado Documento de Arquitetura.
Outos Repositorios
[<Tag da issue>] <Texto começando com letra maiúscula, verbo no particípio, e com final>.
Exemplo:
[US00] Criada estrutura de usuário.
Política de Branches
O repositório do projeto terá uma branch principal, sendo ela a branch estável, a master. Haverá também uma branch denominada devel destinada a ser branch de desenvolvimento.
A master será a branch estável do projeto, sendo ela proveniente da devel por meio de aprovação de pull request ao fim de cada release. Nenhum membro será autorizado a fazer commits diretamente na master ou na devel.
As branches auxiliares são destinadas a implementação de funcionalidades, realização de histórias técnicas e conserto de bugs. Cada uma dessas atividades terá sua própria branch, criada a partir da devel, as Hotfix são as branches criadas a partir da master e servem para resolver de forma rápida, os bugs em produção. Terão como padrão de nomenclatura:
<Identificador da atividade>-<Nome issue associada a atividade>
Exemplos:
TS03-Configurar-Ambientes
BUG-Duplicação-no-Banco
US01-Implementar-Login
Após o fim do desenvolvimento nas branches auxiliares elas devem ser incorporadas a devel por meio de pull request.
Política de Aprovação do Código
Para a aprovação do código, o pull request deve ser revisado por ao menos 1 membro da equipe de EPS, a nomenclatura da branch e dos commits deve estar de acordo com as definições deste documento, o código deve estar escrito seguindo a folha de estilo, a build não pode apresentar erros, a saúde do código deve atingir o nível mínimo, a cobertura de testes deve atingir o nível mínimo e o pull request deve seguir o template do community .
3. Uso de Issues
As issues serão criadas com o objetivo de mapear e descrever todo o trabalho a ser desenvolvido durante o projeto, possibilitando controle e transparência do que está sendo feito. Com isso, conseguiremos manter o rastro de tudo que foi planejado e efetuado.
As issues vão conter identificadores e labels, para que se possa indicar sua natureza. Os identificadores definidos para o projeto serão:
- [EPIC] - Utilizado para as issues que representam épicos.
- [US] - Utilizado para as issues que representam histórias de usuário.
- [TS] - Utilizado para as issues que representam histórias técnicas.
- [FT] - Utilizado para as issues que representam features.
O formato padrão de nomenclatura para essas issues é:
[<Identificador><Número da issue>] <Nome definido pela equipe para issue>
Exemplo:
[US01] Prototipação
- [REFACTOR] - Utilizado para issues que representam refatoração.
- [BUG] - Utilizado para issues que representam correção de bugs.
- [DOC] - Utilizado para as issues que representam tarefas de documentação.
- [TRAINNING] - Utilizado para issues que representam atividades de estudo e treinamento.
- [QUESTION] - Utilizado para issues que representam perguntas que a comunidade deseja fazer aos mantenedores.
- [SUGGESTION] - Utilizado para issues que representam sugestões que a comunidade deseja fazer aos mantenedores.
O formato padrão de nomenclatura para essas issues é:
[<Identificador>] <Nome definido para a issue pela equipe>
Exemplo:
[BUG] Duplicação no Banco
4. Ferramentas
| Ferramenta | Descrição |
|---|---|
| Git | Ferramenta de versionamento |
| GitHub | Ferramenta de hospedagem de repositórios |
| ZenHub | Ferramenta de gerenciamento de equipe |
| ReactJS | Ferramenta de criação de interface de usuário |
| Django Rest | Ferramenta para criação de API's |
| Docker | Ferramenta de virtualização e configuração de ambiente por meio de containers |
| Docker Compose | Ferramenta de gerenciamento de containers Docker |
| Code Climate | Ferramenta de análise estática de código |
| Travis CI | Ferramenta de integração contínua |
| DigitalOcean | Ferramenta de deploy em produção |
| CodeCov | Ferramenta de análise de cobertura de testes |
| VS Code | Ferramenta de edição de código fonte |
| Slack | Ferramenta de comunicação do grupo |
| FireBase | Ferramenta utilizada para abstrair a complexidade da autenticação |
| Rancher | Ferramenta utilizada para orquestrar os conteiners |
Integração das Ferramentas
O GitHub e o Docker tem um papel central na integração das ferramentas, considerando o seguinte pipeline, o desenvolvedor sobe seu ambiente isolado de desenvolvimento criado com containers Docker facilmente através do gerenciamento e orquestração dos containers proporcionado pelo Docker Compose, gera código fonte em python e javascript através do editor de texto VS Code, controla o versionamento utilizando Git e sempre que possível sincronizar o trabalho realizado localmente com o repositório remoto hospedado no GitHub. A partir deste ponto entram em cena Travis e Code Climate, pois após cada alteração no repositório remoto o Travis gera uma nova build do projeto e o Code Climate realiza uma análise estática do código fonte. Além de realizar a build, o Travis também possui outras funções que em alguns casos fazem parte da build e em outros casos são eventos pós build ou pré build, como executar todos os testes automatizados e enviar as informações sobre os testes para o CodeCov verificar a cobertura de testes, e comunicar qualquer problema que ocorra no processo de build impedindo que código quebrado se junte as versões estáveis do projeto. O Travis irá executar um script que automatizará o deploy na Digital Ocean onde a orquestração de containers será feita pelo Rancher. Por fim, e novamente através do GitHub, o Slack e o ZenHub disparam notificações ou realizam ações com base em atualizações no repositório remoto, logicamente além das funções descritas acima Slack e ZenHub também ajudam na comunicação e gerência da equipe através de algumas ações manuais feitas pelos membros, no entanto no caso do Slack ainda existem alguns bots que são usados para automatizar certas atividades.
5. Referências
PMI. Um guia do conhecimento em gerenciamento de projetos. Guia PMBOK® 5a. ed. - EUA: Project Management Institute, 2013
Semantic Versioning 2.0.0 . Semantic Versioning Specification (SemVer). Disponível em <http://semver.org/>
PlataformaJogosUnB. Plano de Gerenciamento de Configuração de Software. Disponível em <https://github.com/fga-gpp-mds/2017.1-PlataformaJogosUnB/wiki/Plano-de-Gerenciamento-de-Configura%C3%A7%C3%A3o-de-Software>
Histórico de Revisão
| Data | Versão | Descrição | Autor(es) |
|---|---|---|---|
| 26/03/2019 | 0.1 | Criação do Documento e adição dos tópicos Introdução, Políticas e Uso de Issues | Lucas Macêdo |
| 26/03/2019 | 0.2 | Adição do tópico Ferramentas | Lucas Macêdo e Matheus Rodrigues |
| 27/03/2019 | 0.3 | Adição do sub-tópico Integração das Ferramentas | Lucas Macêdo |
| 21/04/2019 | 0.4 | Ajuste tópico de branches | Matheus Rodrigues |
| 22/06/2019 | 0.5 | Ajustes finais | Matheus Rodrigues |