Engenharia de Software - Integração contínua

E aí [Música] o Olá eu sou o professor Marcelo Fantinato e essa é a disciplina de engenharia de software vamos falar nessa aula sobre a integração contínua Lembrando que nós estamos num tema maior que a chamada de entrega continua a entrega contínua é pensando em que você quer entregar para o ambiente de desenvolvimento ou para de produção Aliás para o ambiente de produção ou para o cliente é continuamente você quer fazer entrega para ele né fazer essas entregas e para você conseguir fazer essas entregas continualmente você precisa por por exemplo de testes automatizados porque se

você não conseguir fazer teste de forma muito rápida e ágil você não vai conseguir fazer essas entregas contínuas Mas além disso Você também precisa de uma abordagem de integração contínua perto e é o que a gente vai ver na aula de hoje então é o que é a integração com O que é a prática de fundir Ned integrar só para usar um outro verbo aqui né é a para a prática de fundir os componentes com o incremento de software em evolução Então você tem um já um pedaço do software que está em constante evolução e

você quer fugir por novos é pedaços né novos componentes é uma ou mais vezes ao dia então isso é o que representa integração contínua antigamente Talvez para vocês isso seja até um para os alunos mais novos que já trabalham na indústria de desenvolvimento de software e já conhecem já trabalham nesse ambiente de integração continuou Talvez esteja até estranho mas antigamente não era assim que acontecia né é a prática era construir novas funcionalidades que é isso que está destacada em azul era construir novas e de forma isolada E integrá-las no fim do ciclo de desenvolvimento então

cada engenheiro de software ia fazer nas suas a vai fazendo evoluindo e melhorando testando e melhorando de repente uma integrar tudo vamos Olha o que acontecia na ponte de pau né é um monte de erro a ideia agora na integração continuou não é faz um pedacinho em pé entrega integra e entrega integra e entrega faz mais outro pedacinho integra naquilo entrega aí aquilo vai crescendo faz outro pedacinho integra entrega faz o outro pedacinho integra entrega então aquele pedacinho vai aquele pedacinho inicial vai aumentando e sempre um novo pedacinho vai sendo integrado Qual o qual o

quão com qual frequência é uma vezes ou duas vezes no dia certo O que é considerada integração contínua é esperado que você faça pelo menos uma vez ao dia isso é bastante comum em métodos Lages na verdade esse termo integração continuar nasceu no método XP Extreme programming um dos métodos ágeis mais antigos na verdade isso já era feito antes né a quase nada de dos métodos ágeis que foi totalmente criado do zero na verdade eram boas práticas que já existiu mas não eram tão usadas e os seus criadores então resolveram incentivar mais o seu uso

mas o termo integração contínua a primeira vez que ele aparece apareceu foi com o XP Então significa que essa integração tem que ser ágil então o teste que acontece no integração lembra que nós temos o teste de unidade teste de integração teste de sistema enfim Agora nós estamos falando da Integração significa que o teste de integração a ser ágil não basta você integrar de forma rápido você tem que testar essa integração de forma rápido e qual a melhor forma para você fazer um teste de forma rápida automatizando esse teste por isso que as coisas estão

todas inter-relacionadas dentro desse grande tema que é a entrega com Tima bom Ah é mesmo organizações que não usam métodos ágeis podem usar integração contínua de fato uma grande parte faz estima-se que mais de cinquenta por cento das organizações desenvolvedoras de software atualmente usa integração contínua e provavelmente nós não temos um número tão grande assim de organizações que usam métodos ágeis então provavelmente mais em organizações mesmo organizações que não usa o método vaso a esposa uma integração com tima e é uma possível abordagem para se fazer para fazer a a integração contínua é usar o

teste fumaça o teste de fumaça ele é composto por três etapas a e em que na primeira etapa componentes de software recém codificado são integrados na nova built-in Basicamente aquilo que eu já tava falando antes você tem uma bild que está estável Mas você está desenvolvendo novos componentes e aí você quer integrar esse novo componente esses novos componentes nessa bild Então você entrega então a mil devem incluir todos os arquivos de dados bibliotecas modos reusáveis e componentes necessários para implementar uma ou mais funções do produto bom uma vez que você integrou os novos componentes na

nova bild vai para o número 2 uma série de testes é criada para expor erros que impedem hábil de executar corretamente sua função Então os o teste o teste fumaça é composto por um conjunto de testes que é pensando bom e é eu quero os testes mais básicos que houver para verificar se existem problemas muito básicos nessa bild que impedem inclusive deu opera da forma mais básica possível de eu fazer a é o até mesmo a testes adicionais certo então busca-se encontrar erros que sejam bloqueadores do inglês Show stoppers mostrar bloqueadores que apresentam a mais

alta probabilidade de atrasar o cronograma do software Então veja que eu o teste fumaça não é um teste exaustivo como vai aparecer no próximo slide ali abilde é integrada as outras builds e o produto inteiro passa diariamente pelo teste de fumaça né uma ou duas vezes ao dia então teste e fumaça ele tenta exercitar o sistema a fim a fim de início até de uma ponta à outra ponta passando por todos esses e é ele não precisa ser exaustivo mas deve ser capaz de Expor os principais problemas caso ele eles existam deve ser bastante rigoroso

pois ao passar pelo que um sistema passa pelo teste fumaça entende-se que os testes adicionais de aceitação e sistema podem ser iniciados lembra que a gente tem o teste de integração unidade integração e aceitação e sistema se passar pelo de integração significa que os de aceitação e sistemas podem ser iniciados E por que ele se chama teste fumaça não tá escrito aqui mas eu conto para vocês ele se chama teste fumaça porque ele foi originário não aquele que ele se originou Mas é uma alusão aos testes de componentes eletrônicos se você não liga na você

monta um componente uma placa eletrônica um circuito se você liga na tomada e começa a sair fumaça Pronto já tem alguma coisa errada você desliga falar eu já não tá funcionar alguma coisa bem complicada bem grave e tá ali porque eu já tá até saindo fumaça Então essa é a ideia é então você tem uma Build de um Foster você quer executar para ver se tá saindo fumaça porque se tiver saindo fumaça nem o básico está funcionando a outras pessoas chamou esse teste de teste de sanidade que é para ver se o software não tá

assim totalmente louco totalmente maluco né se ele não passar no teste de sanidade é porque ele não sabe fazer nada né Então passou pelo teste de sanidade significa o que significa que ele não é não é louco não é maluco ele tem a o mínimo para passar pelos testes mais é mais complexo certo E como você tenta passar por todo o teste definir assim você tá aí na verdade exercitando a integração entre os vários modos entre os vários componentes no teste de unidade você testou individualmente cada unidade agora você tenta testar a integração e traça

as unidades para depois testar então o sistema como um todo é bom a a integração continua na prática como é que ela funciona os desenvolvedores eles realizam os comites de pequenas atualizações regularmente então desenvolver um pedacinho vou lá faço comer desenvolvi um pedacinho vou lá Faça o convite de forma regular e isso dentro de um ambiente de que a gente chama um ambiente de integração contínua com testes automatizados e tudo mais é Lembrando que se eu sou desenvolvedor Eu já também desenvolvi os testes de unidade de forma automáticos testes automatizados de unidade então quando eu

faço o commit das pequenas atualizações significa que eu tô fazendo committee do código que vai integrar uma nova funcionalidade do sistema e no teste que testa aquele código Eu já faço commit das duas coisas vai para o ambiente de integração contínua o a e integra faz os testes e me dá um retorno né então eu vou ser eu como desenvolvedor eu serei notificado rapidamente se essas alterações que eu fiz e submeti se elas provocam falhas no sistema e desenvolvimento dependendo do que acontecer eu a minha a minha o meu convite defeito né a para eu

poder verificar o que eu fiz de errado para não atrapalhar os outros desenvolvedores é a Então essa integração contínua ela deve ser um processo simples e de repetibilidade e e é vai ser parte do fluxo de trabalho Diário Dos desenvolvedores a para reduzir custos e corrigir defeitos o mais rápido possível como acho que fica um pouco Óbvio conforme É eu tô aqui explicando para vocês aqui tem uma figura que mostra como é a integração continua na prática eu já comentei com vocês a como isso funciona né mas aqui a gente tem do lado os desenvolvedores

envolvendo em algum momento eles vão fazer o commit no novo código acompanhado já dos Testes de unidade automáticos isso vai para um repositório de controle de versão né as novas versões do código e dos Testes existe um servidor de Lee que em Portuguesa que deveria ser diferente a integração contínua que é uma máquina de integração que vai ficar olhando para o repositório é de e sempre que existe uma nova um novo Comet e uma nova versão ele pega aquela nova versão integra testa e gera um relatório um feedback para o desenvolvedor dizendo passou ou não

passou certo isso é feito através de um script é em que compila o código-fonte executa testes gera relatórios e se deu tudo certo de Claro aquela como sendo a nova versão oficial se não deu certo não devolve né Faz um blowback devolve fala olha não passou vai corrigir e isso fica no ciclo e a bom E aqui era só para destacar aqui esse convite é feito usando alguma ferramenta de controle de versão como cvs svn e e o servidor de integração contínua ele vai ficar constantemente monitorando através aqui de um Pool é o repositório de

controle de versão para saber se tem uma nova versão para ele integrar e testar é bom como vantagens e benefícios da Integração contínua nós temos um risco minimizado para o processo de integração porque eu vou sempre integrar e testar Pedacinho por pedacinho eu não vou fazer isso de uma vez só para ter um risco muito grande de dar errado vou ter uma qualidade melhorada do produto final justamente porque eu vou garantir que as coisas são feitas de forma muito mais controlada e quando eu chegar no produto final eu não vou ter surpresas diagnóstico e correção

de erros é simplificado quase não é necessário o processo de depuração para encontrar erros os defeitos que causam as falhas porque sempre que um erro uma falha ocorre é porque um pedacinho do software foi integrado E aí então é só ir direto naquele pedacinho eu não preciso ficar depurando o software inteiro Todo o código para saber onde de onde vem o defeito e a avaliação de progresso é facilitada porque eu vou a sabendo a de uma forma mais controlado o progresso do software à medida que eu vou ter no integrações contínuas dia a dia até

mais do que uma por dia então eu não fico sem saber em que ponto tá né Se cada desenvolvedor tá fazendo a sua parte para integrar só daqui duas semanas daqui um mês eu não sei aqui ponto que tá né Se todo mundo tem que entregar todo dia integrar todo dia eu fico mais a par do que realmente está acontecendo Oi e aí então é recapitulando a com a aula anterior fazendo uma ligação com a aula anterior espera-se que os testes criados para a integração continua sejam obviamente automatizados justamente para compor um conjunto de testes

de regressão para as próximas integrações O que é o teste de regressão né teste de regressão é um conjunto de testes que você desenvolve para executar ser executado para garantir que o software não regrediu porque imagina que você tem uma versão do software estável E aí você insere alguma alteração e aquilo que funcionava parou de funcionar então ele regrediu mas você pode fazer um ter um conjunto não é uma suíte de casa de testes automatizados que sempre que você faz uma nova alteração você não vai executar automaticamente apenas os pés e é relativos àquela alteração

mas sim os testes relativa tudo que já estava funcionando antes para garantir que o que o seu sistema não regrediu por isso que ele é chamado um teste de regressão Tá Na verdade é um teste antes de regressão mas ficou chamado como peste de regressão e a bom em termos de ferramentas de apoio à integração contínua nós temos uma lista aqui de várias ferramentas que podem ser usadas para dar suporte para apoiar a integração contínua algumas com apoio automação de testes com apoio ao controle de versão é a maioria delas atualmente ferramentas que que permite

você fazer Deploy e armazenamento e controle na nuvem né mas enfim aqui apenas para listar algumas dessas ferramentas talvez você já conhece alguma dessas ferramentas e uma das bibliografias que estão indicadas para leitura é comenta um pouco sobre essas ferramentas é bom como referências é nós temos novamente o livro do Fresno de Maxim engenharia de software uma abordagem profissional décima edição de 2021 usado para compor os slides essa aula e também o livro de Polo validação e teste de software de 2019 é isso então com essa aula obrigado a [Música] [Música]