-
Notifications
You must be signed in to change notification settings - Fork 9
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Sprint 09 release
- Loading branch information
Showing
137 changed files
with
8,336 additions
and
1,397 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -8,10 +8,6 @@ addons: | |
| - 159.203.182.32 | ||
| env: | ||
| global: | ||
| - SITE_URL: https://fga-gpp-mds.github.io/2018.1-Dr-Down/ | ||
| - GH_USER_NAME: "Robot Down" | ||
| - GH_USER_EMAIL: [email protected] | ||
| - GH_REF: github.com/fga-gpp-mds/2018.1-Dr-Down.git | ||
| - secure: "wrb7hIKvhTmybgkW/kAubZmmdnIeKlXG6vczz8ct2ZbvVBvPflOQCDLQuqoRWDHDPs8PdLHwLZ6J3zlFCtkxBX0AKrSC1fCedkZSoTYEzrI3hj3k+IhTthWPao1GYuIyE+/GUIY82+4b8AHuE3weTSjl0JlOVpxIFfOXL9T2oRhZxjxdGJmUkJgWLXZIsDjvX1bmBZ/SbdMgGGer1YSu8UoiAAr94IrEU5dyJ9Yc8sX6HTZnCdkGgMckPMyZkVwbW9sw9DcjSCB0W/h3aYIP86zocBUk1xGD0tzbnd1mEYaScXRU1rxVBYoe0XnTmFAhyAae1NTtw+6Pqrz1RDudbfTxJBLvkkaBse1w5XN3oBUeuOFLGyoagItnxqzbprt3QN6Tno23LLrefhShVAvzemRceB/Ie6NWRmyhDbsEJpLgAhUpdAGY+Phh2iFRjAsfCnsHT1AKJIoNBoJoi8d79dSOHTK1XxgdBJi9zfhIXB3jjFPhKIx0UHd4aNsIzfuTQWWC8cm05UcdWiTAxunWumoh94jQ6flkIk7RdNyeM+dytJW9mqTvw2lxCRAuyYo7eGs5jqTMqokSAuSDzRFPMUDlP+t/lewAsuwLsxXVOjrMn8TnT28yimay4bK4ZocYP6M3EJPg1DsJ/QOyCqFIFqEMs8lAqJDNky/cJ/79ZIY=" | ||
| - CC_TEST_REPORTER_ID=bf64f4cd10722061b8cad12ca638ebfa7d3c1494df117613b2acd357bfd7aeb0 | ||
| notifications: | ||
|
|
@@ -21,11 +17,20 @@ notifications: | |
| services: | ||
| - docker | ||
| before_install: | ||
| - sudo apt-get remove docker docker-engine docker.io | ||
| - sudo apt-get update | ||
| - sudo apt-get install -o Dpkg::Options::="--force-confold" --force-yes -y docker-ce | ||
| - docker-compose --version | ||
| - sudo apt-get install apt-transport-https ca-certificates curl software-properties-common | ||
| - curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - | ||
| - sudo curl -L https://github.com/docker/compose/releases/download/1.21.0/docker-compose-$(uname -s)-$(uname -m) -o /usr/local/bin/docker-compose | ||
| - sudo chmod +x /usr/local/bin/docker-compose | ||
| - sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | ||
| - sudo apt-get update | ||
| - sudo apt-get install docker-ce | ||
| - docker-compose version | ||
| - docker version | ||
| - sudo apt-get install texlive-latex-base texlive-fonts-recommended -y | ||
| - sudo apt-get install texlive-fonts-extra texlive-latex-extra -y | ||
| - sudo apt-get install python-sphinx -y | ||
| - python3 -m pip install pip -U | ||
| - python3 -m pip install mkdocs | ||
| before_script: | ||
|
|
@@ -36,23 +41,25 @@ before_script: | |
| - docker-compose -f local.yml pull | ||
| - docker-compose -f local.yml up --build -d | ||
| script: | ||
| - echo $DOCKER_ID_USER_PASSWORD | docker login -u $DOCKER_ID_USER --password-stdin | ||
| - docker-compose -f local.yml run --rm django py.test | ||
| - docker-compose -f local.yml run --rm django coverage run -m py.test | ||
| - docker-compose -f local.yml run --rm django coverage xml | ||
| after_sucess: | ||
| - make -C docs/ latexpdf | ||
| - mv docs/_build/latex/drdown.pdf docs/drdown.pdf | ||
| - if [[ $DEPLOY_DOCS == "true" ]]; then echo "Preparing to build and deploy documentation" ; ./mkdocs-build.sh ; echo "Completed deploying documentation" ; fi | ||
| deploy: | ||
| # deploy develop to the staging environment | ||
| - provider: script | ||
| script: bash staging-deploy.sh | ||
| skip_cleanup: true | ||
| on: | ||
| branch: develop | ||
| # deploy master to production | ||
| - provider: script | ||
| script: bash production-deploy.sh | ||
| skip_cleanup: true | ||
| on: | ||
| branch: master | ||
| after_script: | ||
| - ./cc-test-reporter after-build --exit-code $TRAVIS_TEST_RESULT -t coverage.py | ||
| - make -C docs/ latexpdf | ||
| - mv docs/_build/latex/drdown.pdf docs/drdown.pdf | ||
| - if [[ $DEPLOY_DOCS == "true" ]]; then echo "Preparing to build and deploy documentation" ; ./mkdocs-build.sh ; echo "Completed deploying documentation" ; fi | ||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,14 @@ | ||
| # MINDMAP | ||
|
|
||
| | Data | Versão | Descrição | Autor | | ||
| |----|------|---------|-----| | ||
| |10/05/2018|0.0.1|Primeira Versão do mindmap|Mariana De Souza Mendes e João Pedro Sconetto| | ||
|
|
||
|
|
||
| ## v.0.1. MINDMAP | ||
|
|
||
|  | ||
|
|
||
| [Clique aqui para ampliar a imagem](https://uploaddeimagens.com.br/images/001/411/446/original/Captura_de_tela_de_2018-05-10_15-12-22.png?1525975986) | ||
|
|
||
| [Ou aqui para acessar a imagem no próprio mindmap](https://www.mindmeister.com/1091544081/login?fullscreen=1) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,122 @@ | ||
| # Pipeline CI/CD | ||
|
|
||
| ## Histórico de Revisões | ||
| |Data|Versão|Descrição|Autor| | ||
| | --- | --- | --- | --- | | ||
| |06/05/2018|0.0.1|Versão inicial do documento do pipeline|João Pedro Sconetto e Mariana Mendes| | ||
|
|
||
| ## Processos de DevOps | ||
| O presente documento visa esclarecer e registrar todos os processos, a cultura implementada e os padrões que foram utilizados no projeto __Dr. Down__ no viés das práticas de DevOps, a fim de unificar o desenvolvimento e as operações inerentes do projeto supracitado. | ||
|
|
||
| O documento se divide em duas partes: | ||
|
|
||
| * Integração Contínua (CI - _Continuous Integration_) | ||
|
|
||
| * Deploy Contínuo (CD - _Continuous Deploy_) | ||
|
|
||
| No qual a primeira parte irá mostrar as técnicas e itens aplicados ao projeto no propósito de, como o nome da técnica diz, integrar continuamente o trabalho desenvolvido pela equipe. A segunda parte irá mostrar as técnicas e itens aplicados ao projeto com o objetivo de fazer a implantação contínua do projeto na infraestrutura utilizada pela equipe, de forma automatizada. | ||
|
|
||
| ### Integração Contínua: | ||
|
|
||
| #### Padrão de _Commit_ | ||
|
|
||
| ##### Por questões de padronização documentamos o seguinte estilo de _commit_: | ||
|
|
||
| * Os _commits_ devem ser todos em __inglês__; | ||
|
|
||
| * Ele deve conter um título curto e objetivo do que foi feito naquele _commit_; | ||
|
|
||
| * Após esse título, deve-se descrever, com um pouco mais de detalhes, todas as atividades executadas. | ||
|
|
||
| * Caso esteja trabalhando com algum associado assine nos seus _commits_ os seus parceiros | ||
|
|
||
| __Exemplo:__ | ||
|
|
||
| Creating project community files (Título curto e objetivo) | ||
|
|
||
| Adds project license (Descrição de uma das atividades) | ||
|
|
||
| Adds project code of conduct file | ||
|
|
||
| Adds project contributing file | ||
|
|
||
| Adds project issue template file | ||
|
|
||
| Adds projects pull request file | ||
|
|
||
| Co-authored-by: John Doe <[email protected]> (Assinatura de parceria) | ||
|
|
||
| #### Política de _Branchs_ | ||
|
|
||
| Tendo como meta manter a integralidade e confiabilidade do código do projeto, foi proposta a utilização de política de branches. | ||
| Essa Política de Branches deverá guiar os desenvolvedores na forma de organização de suas contribuições ao projeto. | ||
|
|
||
| __OBS__: A política de _branchs_ foi idealizada para trabalhar em conjunto com a ferramenta do _git flow_, sua documentação e mais informações podem ser acessadas [aqui](https://github.com/nvie/gitflow). | ||
|
|
||
| * __master__ - Branch principal do repositório, onde será permitida somente a integração de software consolidado e testado. Essa branch será exclusiva para a entrega de Releases, ou seja, um conjunto maior de funcionalidades que integram o software. Aqui estará a versão _**stable**_ do software. | ||
|
|
||
| * __develop__ - Branch para integração de novas funcionalidades, onde será permitido a entrega das features desenvolvidas e que estão em um estágio avançado de completude. Será a branch base para o início do desenvolvimento das features e da correção de bugs. Aqui também serão _mergeadas_ as releases. | ||
|
|
||
| * __feature/<nome-da-feature>__ - Branch utilizada para o desenvolvimento de novas features do _backlog_. Caso a feature tenha sida proposta por uma _issue_ do repositório e aceita no _backlog_ o nome deverá conter o número da _issue_. | ||
| Ex: feature/1-<nome-da-nova-feature> (Considerando que a feature tenha sido solicitada na _issue_ #1) | ||
|
|
||
| * __bugfix/<nome-do-bug>__ - Branch utilizada para corrigir bugs de baixa/média urgência e que não estão presentes na branch __master__. Caso o bug tenha sido reportado por uma _issue_ do repositório o nome deverá conter o número da _issue_. | ||
| Ex: bugfix/1-<descrição-do-bug> (Considerando que o bug tenha sido reportado na _issue_ #1) | ||
|
|
||
| * __hotfix/<nome-do-bug>__ - Branch utilizada para corrigir bugs de alta urgência e que estão presentes na branch __master__. Caso o bug tenha sido reportado por uma _issue_ do repositório o nome deverá conter o número da _issue_. | ||
| Ex: bugfix/1-<descrição-do-bug> (Considerando que o bug tenha sido reportado na _issue_ #1) | ||
|
|
||
| * __release/<versão-da-release>__ - Branch onde será feito os ajustes finais/build antes da entrega de uma versão do produto de software. Constará no nome da branch a versão da release a ser entregue. | ||
|
|
||
| * __support/<tema-ou-natureza>__ - Branch onde serão executadas tarefas de suporte relacionadas ao software, como elaboração de documentações, correções de natureza de gerência de configuração e etc. | ||
|
|
||
| #### Testes e Estilo de Código | ||
|
|
||
| Com o objetivo de garantir a qualidade de código, assim como a sua manutenibilidade, a equipe definiu técnicas e padrões a serem seguidos, quanto ao estilo de código foi definido uma folha de estilo que é considerada a padrão por programadores Python, se trata da [PEP8](https://www.python.org/dev/peps/pep-0008/). Com isto é possível verificar, com o auxílio da ferramenta Code Climate o quão manutenível é o código que está sendo feito. | ||
|
|
||
| Em complemento ao estilo do código a equipe acordou em manter todo o código testado, pois com a união das duas técnicas é possível assegurar uma maior qualidade de código. Para isso foram usados técnicas padrões de teste do Python/Django, com o auxílio do [Coverage.py](https://coverage.readthedocs.io/en/coverage-4.5.1/) e do [pytest](https://docs.pytest.org/en/latest/), estes que, também, servem de _input_ para o Code Climate analisar a manutenibilidade do software. | ||
|
|
||
| Ficou acordado entre os membros da equipe que a cobertura de teste deveria ser igual ou superior a 90% em todos os momentos do projeto. | ||
|
|
||
| #### _Pull Requests_ | ||
|
|
||
| Ao término da execução da codificação é necessário a abertura de um _Pull Request_ no repositório oficial do software para que possa ser apreciado o código solução. Com isso as ferramentas de CI/CD automático irão executar a fase de _build_ e teste para verificar se etapa de teste e estilo de código foram implementadas corretamente. Caso não tenha dívidas nessa fase, cabe a dois membros da equipe de EPS (com foco no P.O. na análise) analisar o produto para verificar se atende os critérios de aceitação e se está de acordo com o que foi definido para ser entregue. Com todas as técnicas e fases entregues em conformidade, cabe aos membros aprovarem o _pull request_ para que o mesmo possa ser _mergeado_ em branchs de entregue de _feature_. | ||
|
|
||
| #### _Build_ e Testes | ||
|
|
||
| Com o auxílio de ferramentas de automatização essa fase é executada, via [Travis-CI](https://travis-ci.org/), a fim de garantir a fase de Teste e Estilo de Código. Com isso a ferramenta vai verificar o código, executar todos os testes para procurar erros na lógica do software e após tentar construir (_build_) os _containers_ da aplicação. Caso qualquer passo dessa fase tenha algum problema a ferramenta irá informar (via e-mail e via repositório) que algo está errado e é preciso correções antes de avançar no pipeline. | ||
|
|
||
| ### Deploy Contínuo: | ||
|
|
||
| Com a execução de todos os passos da integração contínua a ferramenta de automatização irá executar os passos de deploy, caso não tenho encontrado nenhum erro, que seguem com o deploy/entrega da aplicação no ambiente de homologação e produção. Os passos executados são: | ||
|
|
||
| * Publica a última versão integrada na _branch_ no docker hub da aplicação; | ||
|
|
||
| * Acessa as máquinas de deploy (Hosts no Digital Ocean); | ||
|
|
||
| * Baixa a última versão do docker hub no host; | ||
|
|
||
| * Executa atualizações necessárias com as novas funcionalidades (migrações, modificações no banco, traduções e etc); | ||
|
|
||
| * Caso tenha algum problema a máquina envia um log para a ferramenta de logs (sentry.io). Caso contrário, o sistema mantém o funcionamento contínuamente. | ||
|
|
||
| ### Pipeline v0.0.1 | ||
|
|
||
|  | ||
|
|
||
| #### Legenda | ||
|
|
||
| Primeiro Estágio: | ||
| * No primeiro estágio estão as culturas de política de _branches_, padrão de _commits_, estilo de código e testes, onde durante o desenvolvimento a equipe segue as culturas propostas até a publicação do código com as novas adições. | ||
|
|
||
| Segundo Estágio: | ||
| * Aqui o código publicado com as adições, chamada de versão, é alcançada pela ferramenta de CI, executado os testes (todos os implementados e os novos adicionados) e é feito a build, caso haja erro nesse estágio retorna-se ao primeiro fazendo as adições necessárias. | ||
|
|
||
| Terceiro Estágio: | ||
| * Aqui a nova versão está em um estágio estável do seu ciclo de vida, se todas as adições esperadas para esta versão estiverem prontas a equipe espera uma abertura de um novo _pull request_ solicitando a junção dessa versão com a versão atual do software. Nesta fase é feito a verificação manual da concordância das adições, tanto com os estágios anteriores quanto com as especificações de produto levantado pelo _Product Owner_, caso positivo o pipeline avança, do contrário retorna a estágios anteriores. | ||
|
|
||
| Quarto Estágio: | ||
| * Aqui com a nova versão aprovada e consolidada ela é direcionada para o ambiente o qual deve integrar (homologação ou produção) e a ferramenta de CI/CD faz o deploy e entrega automática dessas novas adições. | ||
|
|
||
|
|
||
| __OBS__: Os principais artefatos que estão inclusos no, e participam do, pipeline são: ```.travis.yml```, ```codeclimate.yml```, ```mkdocs-build.sh```, ```production-deploy.sh``` e ```staging-deploy.sh```, todos estão disponíveis no repositório da aplicação no [GitHub](https://github.com/fga-gpp-mds/2018.1-Dr-Down). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.