IC e ferramentas para automação de builds
•Transferir como PPTX, PDF•
0 gostou•191 visualizações
Conceito de Integração Contínua e Ferramentas como: Jenkins e SonarQube no IV Meetup Qualyteam. Fontes: Martin Fowler, Kent Beck, Booch SubTemas: Continuous Delivery e Deployment, DevOps, ...
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a IC e ferramentas para automação de builds
Semelhante a IC e ferramentas para automação de builds (20)
IC e ferramentas para automação de builds
- 1. 1
- 2. Ranger • Maicon Carlos Pereira • 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 Do Doing Done Contexto Benner Integração Contínua Jenkins Sonar Sonar 3
- 5. + 20 anos de história + 1.200 colaboradores + 150mil usuários ativos + R$ 220 Milhões de faturamento (2015) 5
- 6. 6
- 7. 7
- 8. “Não sou autoridade ou conhecedor do assunto A ideia é apenas compartilhar e iniciar uma conversa sobre o tema” Ranger 8
- 10. O problema é como garantir que ao integrar as partes tudo estará funcionando? 10
- 11. E quem nunca ouviu... Estranho... na minha máquina funciona... 11
- 12. Pronto! Só juntar tudo e liberar a versão 12
- 13. Alguém sabe pq isso parou de funcionar? 13
- 14. Pronto! Terminei! Só falta testar. 14
- 15. 15
- 16. 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 o termo 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 e atualize 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 Fecha o pacote Disponibiliza no ftp e tchau.... Codifica Compila Testa Comita documenta e tchau.... Codifica Compila Testa Comita documenta e tchau.... 22
- 23. automatizar + feedback como garantir que ao integrar as partes tudo estará funcionando? 23
- 24. Teu fonte não tá compilando!! Mas eu tinha testado na minha máquina... 24
- 25. Agora tenho mais 32 testes 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 Notifica a 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 Continuous Integration Continuous Delivery Continuous Deployment 27
- 28. Code Build Testes Testes Aceitação Release Interno Deploy Produção Continuous Integration Continuous Delivery Continuous Deployment System Integration Test User Acceptance Test 28
- 29. DEV OPS 29
- 30. Práticas de Integração Contínua Martin Fowler https://martinfowler.com/articles/continuousIntegration.html 30
- 31. Começa antes da integraçã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 quebras o mais rapidamente • Manter a master estável • Processo / hábito 34
- 35. Build Automatizado • Tudo que 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 • Testes unitá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 Build Rá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 uma có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 para qualquer 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 ver o 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ção do 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
- 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ção e 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úmero de 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ça para realizar mudanças • Confiabilidade no processo 47
- 48. Leva à uma Continuous Delivery / Deployment 48
- 49. Na prática... 49
- 50. Jenkins 50
- 51. 51
- 53. 53
- 55. 55
- 56. 56
- 57. 57
- 58. 58
- 59. 59
- 60. 60
- 61. 61
- 62. 62
- 63. 63
- 64. Dicas... • Alterar conta do serviço do Windows • Não estava conseguindo se autenticar no GIT 64
- 66. 66
- 70. 70
- 73. 73
- 74. 74
- 75. Demo 75
- 76. Sonarqube 76
- 78. 78
- 79. 79 admin admin
- 80. 80
- 81. 81
- 82. 82
- 83. 83
- 84. 84
- 85. 85
- 86. Demo 86
- 87. TeamCity 87
- 89. Docker 89