\ GamesBI - Documentação

Viabilidade



Pipeline DevOps



Sumário

1. Introdução

Este documento visa apresentar todas as políticas adotadas pela equipe para atingir a integração contínua e o deploy contínuo da aplicação. Tendo isso em vista, este documento irá ser dividido em duas partes, visando a melhor apresentação das informações. A primeira parte do documento irá ser apresentado como foi realizado a integração contínua, e na segunda parte, o deploy contínuo.

2. Integração contínua

A integração contínua visa promover um desenvolvimento fluído, no qual cada desenvolvedor consiga integrar o código desenvolvido na mesma frequência com que as funcionalidades são desenvolvidas. Para isso, utilizamos várias ferramentas e políticas que irão ser explicadas mais detalhadamente adiante.

2.1 Políticas de commit

A estrutura do commit é dado pelas seguintes regras:

[<1>] #<2> <3>
  • Onde <1> é a operação feita:
    • [ADD] - Quando novo código/feature é adicionada ao repositório
    • [DEL] - Quando código/feature é deletada
    • [UPDATE] - Quando código/feature existente é atualizada ou refatorada
    • [DOC] - Quando for relacionado à documentação do projeto
    • [FIX] - Correção de bugs, código quebrado, etc
    • [HOTFIX] - Correção de bugs críticos, que já se encontram no ambiente de homologação ou produçãoc
  • <2> o número da issue relacionada e caso esteja em um repositório diferente do repositório onde se encontram as issues, adicionar fga-eps-mds/2018.2-GamesBI
  • <3> Texto explicativo sobre o que foi realizado:
    • Todos os textos em INGLÊS

2.2 Políticas de branches

Para a política de branches, utilizamos seguir o padrão utilizado pelo gitflow, que utiliza as seguintes branches:

  • master, é utlizada para guardar a história oficial de releases do software, no qual está contido a versão mais recente e estável da aplicação. Essa é a branch utilizada como ambiente de produção.
  • develop, é utilizada para a integração de todas as features desenvolvidas neste novo insumo de código. Essa é a branch utilizada como ambiente de homologação.
  • feature, é utilizada para a codificação da feature em questão.
    • A nomeação dessa feature é dada da seguinte forma: feature_#0, no qual #0 é o número da issue(ex: feature_#23, caso a issue em questão seja a issue de número 23).
    • Essa branch deve ter como base a develop.
    • Assim que a feature for completa, ela é integrada devolta à branch develop.
  • release, é utilizada após o insumo de código estiver apropriado para ser lançado como uma novo release. É possível realizar ajustes rápidos para poder ser lançado como uma nova release. Assim que estiver pronta, esta branch è integrada à master e à develop.
  • hotfix, caso haja algum problema urgente, é criado essa branch para realizar ajustes e logo após integrar à master.

2.3 Folha de estilo e Testes

Uma folha de estilo é necessária para garantir a qualidade do código desenvolvido. Visto que todas as API’s que iremos desenvolver irão ser feitas em python, a folha de estilo que decidimos utilizar é o PEP8, que é considerada padrão para projetos em python. Utilizando a ferramenta Code Climate, é possível verificar, a cada insumo de código, se o mesmo segue o padrão definido pelo PEP8.

Em relação aos testes, possuímos uma métrica bastante importante, que é a cobertura de teste. Essa métrica é capaz de garantir a por centagem de código testado na aplicação. Para gerarmos e controlarmos essa métrica, utilizamos o Coveralls, bastante parecido com o Code Climate, no sentido de que a cada insumo de código, também é gerado um relatório identificando o aumento ou a diminuição da cobertura de testes.

2.4 Pull requests

Após a codificação de uma história de usuário, o desenvolvedor deverá abrir um pull request a partir de sua branch em relação à branch master do repositório oficial. Todos os pull requests deverão seguir um template já definido dentro do repositório, descrevendo as alterações que foram realizadas assim como as issues relacionadas à esse pull request.

Depois da criação do pull request, todos os CI’s que estamos utilizando deverão dar um visto, afirmando que essas alterações seguem a folha de estilo definida, não houve uma diminuição da cobertura de teste e se a build está sendo criada corretamente. Em seguida, ao passar em todos os vistos, o pull request necessitará de um reviewer para aprovar as alterações feitas. Com isso feito, o pull request estará pronto a ser aceito na master.

2.5 Builds

Como dito anteriormente, as builds são geradas ao final de cada pull request, à fim de testar a criação desses insumos de código. Caso esse passo ou qualquer um dos outros CI’s dê algum tipo de problema, essas ferramentas irão informar aos mantenedores do repositório via email e pelo próprio pull request também.

2.6 Ferramentas utilizadas

  • Travis CI: Ferramenta de build para a integração contínua
  • Coveralls: Ferramenta de análise de cobertura de código
  • Codeclimate: Ferramenta de análise de qualidade de código
  • Docker e docker-compose: Ferramenta de conteinerização utilizada para construir os ambientes necessários (desenvolvimento, testes, homologação e produção).

2.7 Ambientes

Existirá, ao todo, 4 ambientes. São eles:

  • Desenvolvimento
  • Testes
  • Homologação
  • Produção

Os ambientes de homologação e de produção irão ser atualizados sempre ao fim da sprint, ou seja, uma vez por semana, com exceção dos casos que se faça necessário utilizar hotfixes para atualização de um bug urgente dentro de um desses ambientes.

O ambiente de desenvolvimento é exclusivo para cada desenvolvedor, cabe a ele utilizar do docker e docker-compose disponível no repositório para subir o seu próprio ambiente de desenvolvimento.

2.8 Serviços

A aplicação desenvolvida irá consistir de apenas 3 serviços. Os serviços implementados são: uma API escrita em django, que se comunica diretamente com o front-end, um front-end escrito em React.js e por fim um worker escrito em python que utiliza o celery para realizar a importação de dados diariamente

3. Deploy Contínuo

Como dito anteriormente, existem 2 ambientes de deploy, homologação e produção. Ambos os ambientes se encotram no heroku.

Após o desenvolvedor escolher uma história e codifica-la e abrir um PR com sua modificação para a develop, os CI's irão executar suas análises e comentar suas respectivas análises no PR aberto.

Um mantenedor deverá revisar o insumo de código e caso haja necessidade de modificações, requisitar elas. Caso contrário, o PR é aprovado e o insumo de código é adicionado à develop

Após o travis realizar a build desse novo insumo de código na develop, ele realiza o deploy para o ambiente de homologação

Ao final da sprint é realizado um PR da develop para a master. Assim que esse novo insumo chegar na master, e o travis concluir a build, o deploy é realizado para o ambiente de produção

Todos os ambientes de homologação e produção são feitos à partir de uma imagem gerada pelo travis, com exceção do repositório do front-end, que é executado diretamente pela build gerada pelo npm

3.1 Pipeline