Baixar para ler offline
Carregado porMaicon Carlos Pereira
Integração Contínua
O documento discute a prática de integração contínua no desenvolvimento de software, enfatizando a importância de integrar frequentemente as alterações para detectar erros rapidamente. Apresenta conceitos, benefícios e práticas recomendadas para uma integração contínua eficaz, como automação de builds e testes, além de citar ferramentas como Jenkins e SonarQube. O objetivo é facilitar a comunicação, identificar e resolver bugs mais rapidamente, além de aumentar a segurança nas mudanças de código.
![[Lady talks]Continuous Delivery](https://cdn.slidesharecdn.com/ss_thumbnails/ladytalkscontinuousdelivery-160106185532-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Uff] Continuous Delivery: Entrega Contínua de Software de Valor](https://cdn.slidesharecdn.com/ss_thumbnails/uffcontinuousdelivery-entregacontinuadesoftwaredevalor-151121215654-lva1-app6892-thumbnail.jpg?width=640&height=640&fit=bounds)
![[DevOps Carioca] Continuous Delivery](https://cdn.slidesharecdn.com/ss_thumbnails/devopscarioca-continuousdelivery-160407131054-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Agile Brazil] Entrega Contínua na Infoglobo: gerando valor em 2 horas](https://cdn.slidesharecdn.com/ss_thumbnails/ab-entregacontinuanainfoglobo-151023191526-lva1-app6892-thumbnail.jpg?width=640&height=640&fit=bounds)
Integração Contínua
- 1.
- 2. Ranger • Maicon CarlosPereira • Formado em Ciência da Computação • MBA em Gerenciamento de Projetos • Profissional da área a mais de 10 anos... • Benner Sistemas desde 2010 2
- 3. Meetup Backlog To DoDoing Done Contexto Benner Integração Contínua Jenkins Sonar Sonar 3
- 4.
- 5. + 20 anosde história + 1.200 colaboradores + 150mil usuários ativos + R$ 220 Milhões de faturamento (2015) 5
- 6.
- 7.
- 8. “Não sou autoridadeou conhecedor do assunto A ideia é apenas compartilhar e iniciar uma conversa sobre o tema” Ranger 8
- 9.
- 10. O problema écomo garantir que ao integrar as partes tudo estará funcionando? 10
- 11. E quem nuncaouviu... Estranho... na minha máquina funciona... 11
- 12. Pronto! Só juntar tudoe liberar a versão 12
- 13. Alguém sabe pq issoparou de funcionar? 13
- 14. Pronto! Terminei! Só faltatestar. 14
- 15.
- 16.
- 17. “Integração Contínua éuma pratica de desenvolvimento de software onde os membros de um time integram seu trabalho frequentemente, Martin Fowler geralmente cada pessoa integra pelo menos diariamente – podendo haver múltiplas integrações por dia. 17
- 18. Cada integração éverificada por um build automatizado (incluindo testes) para detectar erros de integração o mais rápido possível. Muitos times acham que essa abordagem leva a uma significante redução nos problemas de integração e permite que um time desenvolva software coeso mais rapidamente.” automatizar + feedback 18
- 19. integração contínua nãoé nenhuma novidade..... Não é novo não??? 19
- 20. Grady Booch Cunhou otermo e o propôs a “Integração Contínua” em 1991 em sua metodologia de desenvolvimento de software chamada Booch Method. “Os releases internos representam uma espécie de integração contínua do sistema, e existem para forçar o fechamento do micro processo” 20
- 21. Kent Beck “Integre eatualize as versões do sistema várias vezes por dia, cada vez que uma tarefa for terminada...” 21
- 22. “Comita” as alterações Servidor Fontes Codifica Compila Testa Comita Documenta Fechao pacote Disponibiliza no ftp e tchau.... Codifica Compila Testa Comita documenta e tchau.... Codifica Compila Testa Comita documenta e tchau.... 22
- 23. automatizar + feedback comogarantir que ao integrar as partes tudo estará funcionando? 23
- 24. Teu fonte não tá compilando!! Maseu tinha testado na minha máquina... 24
- 25. Agora tenho mais 32testes unitários! Pronto! Construi tudo com TDD.. como validar que os testes ainda estão passando? 32 testes comitados... 25
- 26. Servidor Fontes “Comita” as alterações Servidor IC Notificaa falha ou sucesso Verifica se tem alterações Build • “Baixa” os fontes • Baixar os pacotes nuget • Compilar os projetos Test Build Testar • Testes Unitários • Testes de Integração Post BuildPost Build • Notificar via E-mail • Notificar via Chat • Armazenar artefatos • Métricas 26
- 27. Code Build Testes Testes Aceitação Release Interno Deploy Produção ContinuousIntegration Continuous Delivery Continuous Deployment 27
- 28. Code Build Testes Testes Aceitação Release Interno Deploy Produção ContinuousIntegration Continuous Delivery Continuous Deployment System Integration Test User Acceptance Test 28
- 29.
- 30. Práticas de Integração Contínua MartinFowler https://martinfowler.com/articles/continuousIntegration.html 30
- 31. Começa antes daintegração.... • git pull .... • coding... • build... • test... • git pull... • resolve conflitos • build... • test... • git push... Meu código Meu código junto com os demais 31
- 32. Repositório Único • Éraro mais ainda existem projetos sem • tudo que você precisa para fazer uma build deve estar incluído no repositório: • scripts de teste, • arquivos de configuração, • esquema de banco de dados, • scripts de instalação e • bibliotecas de terceiros 32
- 33. Máquina de Integração •Cada commit deve atualizar o repositório principal em uma máquina de integração • Manualmente • Automaticamente • Por que? • Disciplina • Ambientes diferentes • Quem fez a build não a considera terminada enquanto ele não recebe uma notificação 33
- 34. Corrigir as quebraso mais rapidamente • Manter a master estável • Processo / hábito 34
- 35. Build Automatizado • Tudoque for além do F5 do Visual Studio, deve ser automatizado... • qualquer um deve ser capaz de ir em uma máquina virgem, pegar as fontes do repositório, e com um único comando ter o sistema rodando • Build deve inclusive pegar o schema do banco de dados do repositório e colocá-lo no ambiente de execução 35
- 36. Builds Auto-Testáveis • Testesunitários • TDD • Fácil execução • Avaliação dos resultados MSTest 36
- 37. “Commits” frequentes /diários • Usar a integração como meio de comunicação; • encontrar rapidamente se existe algum conflito entre as versões; • conflitos que não são detectados por semanas podem ser difíceis de serem resolvidos. • Os códigos comitados devem ser estáveis (compiláveis e testáveis) 37
- 38. Mantenha a BuildRápida • Build Rápida == Feedback rápido • Separar • Primária: Testes Unidades / Rápidos • A cada build • Secundária: Testes de Interface / Carga / Stress / ... Lentos.. • A cada X tempo ou em paralelo • Sempre que uma build secundária falhar, avalie se é possível criar um teste na build primária. 38
- 39. Teste em umacópia do ambiente de produção • Quanto mais parecido for o ambiente de testes com o de produção maior a chance de detectar problemas • Mesmo hardware, mesma versão de SO, mesma versão do .Net e demais ferramentas instaladas.... • Rodar testes em containers Docker 39
- 40. Torne fácil paraqualquer um ter o último executável. • qualquer um envolvido no projeto deve ser hábil para ter a última versão executável e ser capaz de roda-la: • para demonstrações, • testes exploratórios ou • simplesmente ver o que mudou esta semana. • Simplifique o acesso • Disponibilizar container atualizado 40
- 41. Todos podem vero que esta acontecendo. • Comunicação / Feedback • Estado da Build • Informações sobre a duração dos builds • Que alterações lançaram o build 41
- 42. Automatize a Implantaçãodo Sistema (Deployment) • Ter scripts que permitam facilmente implantar o software em um ambiente de produção • Reduz erros • Reduz o tempo necessário, se fosse manual • Algumas práticas: • Balancear a parte da carga do web site para o node que contém a nova versão 42
- 43.
- 44. Reduz o risco •Não se espera até o fim do projeto ou desenvolvimento da funcionalidade para integrar as partes 44
- 45. Facilita a identificaçãoe solução de Bugs • Não nos livras dos bugs • Commits frequentes e checados por códigos auto-testáveis • Commits pequenos • “Fresco” na memória 45
- 46. Reduz o númerode Bugs • Bugs são cumulativos • Quanto mais bugs você tiver, mais difíceis são se serem removidos • Janela quebrada • Pessoas tem menos energia para encontrar e eliminar os bugs quando há muitos deles • Desde que se tenha uma boa suíte de tests, a IC ajuda a reduzir o número de Bugs 46
- 47. Aumenta a segurançapara realizar mudanças • Confiabilidade no processo 47
- 48. Leva à umaContinuous Delivery / Deployment 48
- 49.
- 50.
- 51.
- 52.
- 53.
- 54.
- 55.
- 56.
- 57.
- 58.
- 59.
- 60.
- 61.
- 62.
- 63.
- 64. Dicas... • Alterar contado serviço do Windows • Não estava conseguindo se autenticar no GIT 64
- 65.
- 66.
- 67.
- 68.
- 69.
- 70.
- 71.
- 72.
- 73.
- 74.
- 75.
- 76.
- 77.
- 78.
- 79.
- 80.
- 81.
- 82.
- 83.
- 84.
- 85.
- 86.
- 87.
- 88.
- 89.
- 90.