Last active
May 7, 2020 01:30
-
-
Save regiszanandrea/ccdec0f044b39c0fed94ab548cca186e to your computer and use it in GitHub Desktop.
Gist sobre para anotações sobre Entrega Continua (Continuous Delivery)
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
Principal fundamento: Fazer entregas pequenas e rápidas ao invés de grandes entregas de uma vez | |
Integração Contínua (CI) significa integrar as alterações no mainline (master ou trunk) diariamente | |
Aplicando Integração Contínua corretamente, diminuímos os problemas de integração (como merge hell), melhoramos a comunicação entre desenvolvedores e antecipamos a descoberta de bugs | |
Branching models (Estratégias de ramificação): | |
Feature branch: Cada nova feature a ser implementada é separada em uma branch. Principal desvantagem é o distanciamento da branch principal. | |
Github flow: Tudo que possui na feature branch, mais pull-requests. Principal vantagem é o code review porém isso pode ser visto como um impedimento. | |
https://guides.github.com/introduction/flow/ | |
Gitlab flow: Tudo que o githubflow possui mais a adição de Environment branches | |
https://docs.gitlab.com/ee/topics/gitlab_flow.html | |
Testes fazem parte da construção do software | |
Não existe entrega continua sem testes | |
A cada commit, deve ser rodado os testes para verificar se o commit não quebrou algum teste. Como também, | |
o commit deve seguir com teste referente a modificação. | |
Tipos de testes: Unit Tests, Integration Tests, Funcional Tests | |
Unit Tests: testes pequenos, rápidos e procuram testar funções e classe | |
Integration Tests: testa modulos em conjunto, por exemplo: acesso ao banco de dados | |
Funcional Tests: Testa funcionalidades, como uma user story, por exemplo: salvar um comentário em um post. | |
Smoke Tests: Testar apenas as funcionalidades mais importantes do software, conhecido como build verification tests | |
Build: | |
O build do projeto deve ser simples e totalmente automatizado | |
Utilize Unit tests, pois eles são rápidos e garatem uma boa cobertura | |
Utilize cache | |
Builds rápidos que falham rápidos, normalmente menos que 10 minutos | |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment