3 4 5 6 7
[Música]
Olá ouvintes Eu sou Adolfo Neto
professor da Universidade Tecnológica
Federal do Paraná E eu sou Gustavo Pinto
professor aqui na Universidade Federal
do Pará E este é o Fronteiras da
Engenharia de Software um podcast feito
para refletir sobre o presente e futuro
da engenharia de software Fronteiras da
Engenharia de Software é um podcast de
divulgação científica que discute
mensalmente diversificados temas da
engenharia de software Os episódios
abordam questões fundamentais da
engenharia do software até os mais
recentes avanços na
[Música]
[Aplausos]
[Música]
área Esse já é o nosso sexto episódio e
hoje a gente conta com a presença do
Iraculesa que é professor na UFRN
Federal do Rio Grande do Norte onde
lidera o grupo de pesquisa CASE
Colaborative and Automated Software
Engineering Nos últimos anos o IR tem
trabalhado bastante com integração
contínua Vem com a
gente Tudo bem você pode se apresentar
para as pessoas que nos escutam olá
pessoal É um prazer estar participando
do Fronteiras de Engenharia de Sorte
Muito obrigado pelo convite E eu sou
professor associado da Universidade
Federal do Rio Grande do Norte há cerca
de 12 anos Antes disso eu fiz meu
doutorado na PUC do Rio meu mestrado na
Universidade de São Paulo capital e meu
minha graduação na Universidade Federal
de Campina Grande Eu também atuei por
cerca de 4 anos em várias spinoffs do
Centro de Estudos Temas Avançados do
Recife E atualmente eu lidero o grupo de
pesquisa e laboratório Case Colaborative
and Automated Soft Engineering Group
aqui na Universidade Federal do Rio
Grande do Norte conduzindo pesquisas na
área de evolução de software e vários
estudos relacionados à mineração de
repositórios
[Música]
Ira eh dentre essas atividades de
pesquisa de evolução de software parece
que você tem trabalhado recentemente
sobre integração contínua Você pode
explicar pra gente o que que seria
integração contínua bom integração
contínua é uma prática de
desenvolvimento software que ela promove
a integração frequente do código fonte
produzido por equipes de desenvolvimento
através da automação do processo de
compilação e integração e teste de novas
tarefas que são desenvolvidas
Particularmente a integração contínua
ela foi proposta como parte da
metodologia de desenvolvimento Extreme
Programming né que foi inventada por
Kentbeck no final do século passado mas
ela com o tempo se popularizou e hoje
ela é usada de forma independente pelas
principais empresas de software do mundo
assim como um grande número de projetos
open source O que que eu preciso de
ferramentas artefatos práticas que eu
possa ter um ambiente de integração
contínua no meu trabalho na minha
empresa eh no meu laboratório qual que
são qual que seria o setup ideal para eu
poder ter essa prática funcionando
adequadamente bom se a gente for olhar
assim talvez uma das formas mais fáceis
de entender o processo de integração
contínua seja entender o workflow e
atividades que acontecem entre uma
equipe de desenvolvimento quando ela tá
usando essa prática né então basicamente
como a maior parte das equipes de
desenvolvimento hoje em dia ela
pressupõe o uso de um repositório
central eh os desenvolvedores que
participam do desenvolvimento baixam né
o código desse repositório central
paraas suas máquinas para fazer seus
desenvolvimentos individuais novas
features correções de bugs e
posteriormente eles submetem esse código
novamente para esse repositório central
Existe uma observação importante que
antes de durante a produção do código
individual e antes de submeter o código
pro repositório central tipicamente ele
deveria produzir algum teste
automatizado né para testar as novas
features que ele tá fazendo e também
executar os testes já existentes
Normalmente teste de unidade de
integração Ele antes também de comitar o
código deveria integrar internamente na
sua máquina todo esse código né e
reexecutar todos os testes e resolver
eventuais conflitos que tenham tido pela
produção de novas evoluções na mainline
que tá no repositório central E aí
finalmente ele pode então atualizar seu
código através de um pull request um me
request no repositório central Bom feito
isso dentro do repositório central
também podem existir pipelines né de
execução de de build de integração e
execução de testes automados do sistemas
Eh normalmente pelo menos um pipeline é
executado para gerar uma versão
executável do sistema e rodar por
exemplo teste de unidade integração Mas
em ambientes mais sofisticados né mais
de um pipe mais de uma etapa pode
existir nesse pipeline para executar por
exemplo posteriormente uma bateria de
testes não apenas de unidade de sistema
né que não envolve a instalação num
sistema num ambiente próximo ao ambiente
de produção mas fazer a instalação
também no ambiente próximo do ambiente
de produção e instalação e executar uma
bateria de teste mais sofisticada que é
como por exemplo testes e sistemas que
precisam de um de um ambiente completo
rodando né incluindo bank dados etc
Então o IR quais são os principais
benefícios da integração contínua por
que eu devo praticar integração contínua
na minha empresa o principal benefício
associado com integração contínua já
desde seu início né desde que Hentbeck
propôs essa prática lá em Extreme
Programming é reduzir problemas de
integração de código né então já desde
aquela época com um Advento de Extreme
Programming que foi que é uma
metodologia de desenvolvimento com
práticas bastante dissonantes né do que
existia até então na engenharia de
software no final da década de 90 que se
percebeu a necessidade do mercado de
produzir software cada vez mais rápido e
com requisitos mudantes então eh que
mudam o tempo todo Então se percebeu que
em função disso foi criada a prática de
integração contínua para reduzir
problemas de integração de código que
aconteciam quando vários desenvolvedores
submam para o mesmo repositório Então o
principal benefício eu diria é esse de
reduzir problemas de integração de
código numa equipe de desenvolvimento
Mas um outro benefício que se observa
bastante principalmente por causa da
presença do uso de testes automatizados
é que ele antecipa e melhora e reduz a
quantidade de bugs que existem num
sistema Então naturalmente usando
integração contínua você vai reduzir
seja problemas bugs esse que eram
gerados durante a integração ou sejam
problemas de bugs normais já que agora
por fazer teste automatizado você vai
ter uma um cuidado maior com o seu
código né então pelo que eu tô
entendendo só confirma para mim esses
benefícios eles fazem sentido também
quando eu trabalho num grupo pequeno
quando eu trabalho sozinho Sim os
benefícios são mais visíveis quando você
trabalha em equipes grandes de fato né e
com intenso trabalho e mudanças
diariamente que eu diria que é realidade
para boa parte dos projetos que a gente
tem hoje Claro que um projeto com uma
duas pessoas vai se beneficiar menos mas
ainda assim se beneficia a partir do
momento que não é mais uma pessoa no
projeto e e a quantidade e intensidade
de mudanças é grande né de comits no
sistema de contribuições Então qualquer
equipe pode se beneficiar até mesmo
equipe de um projeto na universidade por
exemplo Eu irá eu imagino que nem tudo
sejam flores né então tem alguns
desafios que essa prática de integração
contínua pode trazer para
desenvolvedores Uma coisa que eu imagino
é que a gente vai ter que fazer merge o
tempo todo né porque as pessoas vão
estar trabalhando ali nas suas branch
individuais Então eu imagino que
integração contínua tenta facilitar essa
esse merge de branch mas eu acredito que
também passe a ser mais comum esse tipo
de problema Então tem eh outros desafios
né que a integração contínua faz e esse
desafio que eu falei de fazer merge o
tempo todo faz sentido então na verdade
o problema de integração de código ou de
conflitos de integração de código né
eles são inerentes a qualquer projeto
que use um repositório central de
software Toda vez que você tiver vários
desenvolvedores contribuindo para um
repositório central esses conflitos
podem acontecer A integração contínua é
um mecanismo inventado para justamente
antecipar esses conflitos para que eles
não ocorram eh mais do que diariamente
né então quando esses a medida que a
gente vai integrando o código
diariamente ou frequentemente com a
periodicidade até menor que um dia esses
conflitos já vão aparecendo e
necessariamente precisam ser resolvidos
para que o código seja integrado na
máquina central A prática de integração
contínua é um dos mecanismos mais usados
para combater os problemas de resolução
de conflitos de MH Mas eu diria que um
dos maiores desafios atuais da área de
integração contínua é ter disciplina
para produzir testes automatizados Teste
de unidade integração é ainda muito
pouco atacado por muitas equipes de
desenvolvimento em projetos mundo afora
E a automação de teste de sistema já já
é hoje em dia mais comum mas já tem sido
atacado por muito mais equipes mas é não
é difícil você encontrar muitos projetos
que ainda usem integração contínua e não
façam uso e de qualquer forma de
automação de teste Então isso é um
problema à parte é um desafio bastante
grande Então eu diria que produzir
testes gradativamente à medida que você
vai produzindo código esse é o principal
desafio hoje pra integração contínua
Inclusive esse problema de codificar
test hoje em dia como um problema pela
própria comunidade científica que atua
nessa área de testes né eles estão
produzindo várias estratégias para
tentar estimular isso como por exemplo
ferramentas de gamificação Existem
outros desafios técnicos inerentes né
integração contínua como produzir
pipelines builds
virtualização Eles também são desafios
na área de integração mas eu diria que
esses são mais problemas técnicos
inclusive a gente encontra eles muito
mais bem resolvidos em boa parte das
equipes do que a parte de teste que é
muito mais cultural e merece muito mais
atenção Ira mas voltando nessa ideia de
problemas de como é que você vê eh as
ferramentas né não só as ferramentas de
integração contínua mas as ferramentas
que apoiam né eh resolução de conflitos
elas funcionam bem né eu que muito desse
trabalho de relação de conflitos é é
manual né eh mas elas funcionam
decentemente Dá para confiar nelas no
dia a dia dá para usar eh sem ter mais
dor de cabeça que os conflitos trazem
Boa parte das ferramentas que a gente
tem atualmente para fazer MEG de
integração de COD para resolução de
conflitos são chamados ferramentas de
merge não estruturados né ou
simplesmente baseado na análise textual
do código do sistema né existe algumas
ferramentas acadêmicas sendo propostas
que olham mais pra estrutura né
sintática do programa para tentar
capturar melhor esses conflitos e
alertar só aqueles realmentos mais
importantes Mas a grande maioria das que
vêm sendo usadas de fato são de análise
textual Então a gente tem que esperar o
avanço aí dessa dessas ferramentas que
estão sendo produzidas pela academia e
validadas né com projetos da indústria
para ver o quão elas vão ficar afinadas
aí no futuro para ajudar nesse problema
de resolução de conflito De toda forma
como a gente comentou antes né a
integração de código diária e frequente
pode ajudar a reduzir essa quantidade de
conflitos né atualmente né na indústria
o que é que se usa testes automatizados
Então quer dizer os testes automatizados
eles também são um alerta que uma
eventual integração de código uma
eventual resolução de conflito deu
errada né então você pode desfazer né e
tentar refazer aquele merge de código
toda vez que por exemplo um código foi
alertado de algum erro né pelo código
automatizado seja ele de unidade ou de
sistema Inclusive essa é uma coisa que
eu esqueci de observar anteriormente né
que é extremamente recomendado que toda
vez que haja um erro seja ele de teste e
unidade integração ou também de sistema
que a equipe toda pare tudo que tá
fazendo e busque resolver aquele
conflito Então isso é um princípio na
integração contínua né uma prática
dentro uma subprática dentro da prática
de integração contínua Toda vez que algo
atrapalha meu build algum erro é
levantado toda a equipe deveria parar
tudo e priorizar a resolução daquele
erro né então essas são as formas que a
gente tem para resolver esse conflito
Ferramentas textuais que ainda são
bastante limitadas ferramentas no
horizonte aí de eh usando
análise baseada na sintaxe do código e
finalmente testes automatizados que é
uma coisa que já é bastante usada que
pode eventualmente levantar algum
problema semântico né e existe alguma
regra de ouro uma como se diz em inglês
rule of thumb de um limite de tempo que
eu preciso integrar a o a minha branch
com onde eu tô trabalhando numa
funcionalidade com a branch principal eh
15 dias 7 dias 3 dias ou será que isso
varia de projeto para projeto de
organização para organização bom até
onde eu sei é a prática de integração
contínua que quando foi inventada ela
promovia e motivava a integração
contínua diariamente né mas hoje em dia
o que a gente vê é uma maior intensidade
nisso é com a integração praticamente de
novos comits que são lançadas Eu diria
que em projetos open so é muito comum né
você ver essa integração contínua a cada
comite novo que é lançado eventualmente
com autorização de desenvolvedores core
né que dominam aquele projeto que
controlam aquele projeto Mas numa
empresa industrial ou mesmo num projeto
opensoral você pode ter essa criação de
diferentes branches aí minor ou mail
release para ajudar nesse controle Eu
diria que com a integração contínua pelo
menos uma integração diária recomendada
embora eh eu não sei exatamente quais
são as práticas por exemplo em relação à
branch principal né mas eu diria que
quanto mais você demorar para fazer essa
integração mais problemas vão tender a
ocorrer O Irai e com relação à
terminologia né eh tem alguns outros
conceitos ou práticas que tem nomes
similar assim à integração contínua como
entrega
contínua eh ou até mesmo deployment
contínuo Eles são coisas similares eh
eles têm um um o mesmo propósito são
atividades relacionadas Você você
consegue ver uma diferença entre esses
termos sim esses conceitos são
diferentes mas eles são fortemente
relacionados né nós vimos aqui que a
integração contínua é uma prática de
engenharia de software que motiva a
integração diária ou frequente né do
código produzido por uma equipe e que em
seguida ele passa no repositório central
por um processo de compilação integração
e teste automático das novas tarefas
envolvidas ou correções de bugs ou
pequenas melhorias realizadas A entrega
contínua ou continuous delivery ela
objetiva garantir que a tua aplicação
que é integrada ela sempre esteja no
estado pronto para produção depois de
passar para uma série de testes
automatizados inclusive os testes de
aceitação Então a entrega contínua ela
faz o deployment do teu sistema em
servidores internos e em seguida executa
uma bateria considerável de teste para
garantir que ela tá que a sua aplicação
tá sempre pronta para ir pra produção
Finalmente o continuous deployment ou
instalação contínua ela de fato leva a
tua aplicação para os servidores de
produção final né então ela é uma
evolução da entrega contínua né a
entrega contínua é uma evolução da
integração contínua e o deployment
contínuo De fato a instalação final do
software automaticamente nas máquinas de
produção Então toda vez que commits são
submetidos para os servidores passam por
um processo rigoroso né de qualidade de
avaliação de qualidade centrado
sobretudo no na execução de um volume
bastante considerável de testes
automatizados sejam eles de unidade
integração ao sistema para garantir a
qualidade do sistema Então uma coisa
interessante da gente observar aqui é
que a entregue e o deployment contínuo
ele é totalmente fundamentado na prática
de integração contínua Ou seja você não
vai conseguir fazer continuous delivery
ou deployment sem usar a prática de
continuous integration de forma sólida
incluindo aí a parte de teste
automatizado que é uma das maiores
carências como a gente comentou Existem
elementos que são específicos aí da
integra contínua né a e da deployment
contínuo que vão além da integração
contínua embora a integração contínua
como a gente disse é a base né mas a
integra contínua ela pressupõe por
exemplo que a sua arquitetura seja
modularizada em unidades menores né em
módulos menores os chamados
microsserviços de forma que você possa
atualizar essas partes menores esses
módulos específicos eh durante essas
atualizações frequentes que acontecem no
seu ambiente de produção Também
normalmente continuous delivery
deployment eles têm pipeline de tarefas
bem mais sofisticados né porque você vai
agora fazer a instalação do das
atualizações em servidores de produção
Então esse pipeline de tarefas é bem
mais sofisticado os testes também são
bem mais rigorosos para que isso
aconteça É interessante essa pergunta
que vocês fizeram também porque eu já
conversei assim com com amigos né
colegas que trabalham em empresas todos
eles diziam que já estavam fazendo
continuous deliver né deployment E aí eu
fui conversar com ele um pouco mais a
respeito dos testes automatizados que
eram realizados naqueles sistemas né e
aí eles diziam que nem muitos testes
automatizados eram feitos E isso me
intrigou realmente porque falei: "Ah mas
e aí como é que você consegue jogar pra
produção esse COD se você não tem tanta
confiança é nas alterações que você tá
fazendo né?" Então de certa forma eu
rebati para eles a colocação e a gente
sabe que os as grandes empresas do mundo
né os grandes Facebook Google as grandes
empresas que que vêm que tem a maior
quantidade de clientes e usuários e
realmente funcionam 24x7 elas têm
processo bem rigoroso para eh realizar
os testes automatizados seus sistemas e
garantir a qualidade deles Então isso já
é uma prática bastante forte claro da
parte da estruturação da arquitetura em
módulos menores
[Música]
Eh então o Irá seguindo em diante eh a
gente se a gente você mencionou né que
uma dessas práticas vem lá do do livro
do Quentbeck né o livro do Quentbeck tem
15 anos né tem mais de 15 anos que ele
foi publicado E ele já falava ali sobre
testar e integrar código em intervalos
menores né mas curiosamente umas
ferramentas como Traves e Corci elas
elas vêm apoiando essa prática de
integração contínua já algum tempo né
não que eu precise essas ferramentas
para que exista né uma atividade de
integração contínua mas eu já tenho esse
suporte de ferramenta há algum tempo O
Jis por exemplo eh ele enfim tem mais de
10 anos né de existência né curiosamente
no área de pesquisa e integração
contínua parece que houve um uma onda
recente de trabalhos nos últimos 2 tr
anos você tem alguma intuição de porque
eh o interesse em pesquisa veio mais
recentemente assim eu acredito que tenha
vários outros trabalhos que vieram sendo
publicados assim na ao longo da última
década mas muito recentemente
aconteceram muitos trabalhos Você tem
alguma sugestão bom a integração
contínua foi proposta formalmente no
final do século passado né dentro da
metodologia Streaming Programming junto
com várias outras práticas proposta aí
pelo Kentback E aí já no começo desse
século com a adoção da da metodologia
extreme programming também com um
advento com bastante força das
metodologias ágeis né a prática de
integração contínua passou a ser
bastante adotada né em termos de
ferramenta nós e foi até legal você ter
mencionado Jens porque antes mesmo do
Jens ou da Travci essas ferramentas
online de uso de integração contínua
integradas com repous repositório Hoje
em dia a gente teve a ferramenta por
exemplo cruise control né eu lembro que
a gente começou a usar lá no César há
muito tempo atrás quando o extreme
programmente
tava chegando e chegando com força né
agora em termos de pesquisa que que
aconteceu ao longo dessas duas décadas
né no na primeira década houve muitos
relatos de experiências reportados em
conferências que têm mais proximidade
com a indústria com a comunidade ágil
como a a própria conferência Extreme
Programming e a GI Conference né
internacionais Então houve bastante
relatos de experiências do uso de
integração contínua nessa época Agora o
aumento significativo de pesquisas e
trabalhos na nossa área aumentou
bastante porque eh pela disponibilidade
quando a comunidade surgiram esses
servidores online né de integração
contínua como Travis como Circle C E aí
os projetos open source que tão
disponíveis passaram a tá disp eh se
passou a observar que o momento em que
eles estavam adotando esses servidores
de integração contínua e aí muita
pesquisa foi realizada em cima do que
foi produzido em termos de código e o
uso da com o uso da prática de
integração contínua né eh nesses últimos
anos Então a especificamente a
comunidade de mineração de repositório
de software explorou bastante isso nos
últimos anos Então vários trabalhos
surgiram inclusive os que a gente
desenvolveu aqui na UFRN né houve uma
explosão realmente de trabalhos com
resultados bastante significativos e num
volume de análise de projeto bastante
maior que a década passada Então
basicamente é isso que eu atribuo esse
crescimento aí dos trabalhos na área da
gente Assim vale lembrar também que além
desses estudos de mineração de
repositório também foram realizados
muitos estudos de
survey entrevistas né com empresas eh
com empresas que desenvolvem sistemas
bastante grandes Então tivemos algumas
pesquisas aí recentes principalmente
desenvolvida pelo pesquisadores
americanos né que
ressaltam eh vão de encontro aí a olhar
os benefícios através de server
entrevistas que essas empresas
observaram aí ao longo do período em que
elas adotaram Se há Então essa é uma
outra gama de pesquisas que é inferior à
quantidade de pesquisas e mineração de
repositório mas que também é
significativa e recente Aí bastante
interessante Dá uma olhada O irá A
integração contínua tem algum impacto
seja positivo ou negativo em alguma
outra atividade de desenvolvimento de
software por exemplo será que o número
de bugs diminui após adotar a integração
contínua será que eu consigo ter
entregas mais rápidas depois de adotar
integração contínua sim é verdade Nós
temos várias pesquisas que tem mostrado
os benefícios o impacto que continuous
integration pode trazer a
produtividade do desenvolvedor né para
lidar com o número maior de tarefas
Então C impacta positivamente na
produtividade do desenvolvedor e nós
temos também pesquisas mostrando que se
traz grande melhorias na qualidade do
software produzido né então se for se
fosse para citar por exemplo uma
pesquisa nessa linha a gente pode citar
alguns trabalhos do pesquisador Bogdan
Basilesco lá do Carnet M University né
nos Estados Unidos em que ele por
exemplo desenvolveu um estudo em que ele
eles conseguiram descobrir que houve
analisando vários projetos Open Sociub
eles perceberam que houve uma redução no
número de bugs reportado por
desenvolvedores core né desenvolvedores
principais de projetos Open Soci Houve
uma melhoria aí na qualidade em termos
de número de bugs redução do número de
bugs
reportados Também nesse estudo eles
mostraram que houve uma integração mais
rápida de por requests né então houve
uma uma mais por requests foram
integrados foram feito merge né do
branch principal de por requests
aumentando assim a produtividade também
de desenvolvedores do núcleo antes e
após a doação de integração contínua
Então as pesquisas têm mostrado sim os
benefícios que se traz paraa
produtividade paraa qualidade Só que por
outro lado a gente também tem pesquisas
mostrando que aí ainda existem vários
desafios né para desenvolvedores para
organizações para adotar CI Eh se há
inevitavelmente adiciona uma
complexidade extra sobretudo cultural né
como a gente já mencionou na parte de
tests e também de do da necessidade do
aumento da colaboração entre a equipe né
que a equipe precisa est constantemente
em comunicação ter mecanismos de
conversa de interação para que possa
resolver conflitos de integração ou
problemas e erros eh que ocorrem durante
a execução dos testes automatizados ou
geração de builds para serem resolvidos
O IR vocês tiveram um trabalho recente
sobre integração contínua e evolução de
código de teste né o nome do artigo é
inclusive empirical study on the
relationship between continuous
integration and test code evolution Eh
parece um nome bem sugestivo né uma
coisa tem interferência na outra Eh você
falou do trabalho do do Bogdan agora mas
o seu trabalho ele achou alguma coisa
similar você pode explicar pra gente o
que que vocês encontraram nesse trabalho
sim esse é um trabalho bem interessante
que nós publicamos ano passado no ICSME
né no conferência C Software Maintenance
and Evolution uma das
principais do mundo Ele fez parte do
doutorado de Gustavo Cisílio e foi
orientado juntamente com o professor
Daniel Alencar da Universidade de Otávo
Nova Zelândia Basicamente nesse projeto
o que a gente fez foi comparar projetos
que pass que adotaram C versus projetos
que não adotaram C e se o volume de
teste para esses projetos aumentou
durante a adoção de CI ou ao longo do
ciclo de vida para projetos que não
adotaram CI né não apenas o volume de
testes mas também a cobertura de testes
A gente fez análise para um subconjunto
desses projetos Entrando em um pouco
mais detalhes dessa pesquisa né que foi
realizada nós analisamos 82 projetos que
usam CI 82 projetos que não usam CI Nós
fizemos o confronto entre esses 82
projetos de um lado e 82 do outro Esses
projetos foram selecionados de forma
rigorosa né são todos projetos
estrelados e bastante populares do
GitHub Nós selecionamos inicialmente os
3000 mais estrelados Depois nós
filtramos em dois conjuntos conjuntos de
projetos que adotaram servidores de
integração contínua notadamente o travci
e projetos que não tinham indícios de
uso de nenhum servidor de integração
contínua Também buscamos projetos que
estavam antigos com mais ou 4 anos de
existência e que tinham um volume
considerável de artefatos de teste
produzidos E nós analisamos projetos das
cinco linguagens mais populares do mundo
né java Python Ruby PHP e JavaScript
Então uma vez definido esse
data né nós selecionamos 24 meses de
análise desses projetos para analisar o
comportamento dos artefatos de teste
nesse projeto Nos projetos que adotaram
CI eh nós olhamos projetos que passaram
a adotar o Travis C a partir de um dado
momento Nos projetos que não adotaram CI
nós olhamos a mediana no tempo dos
projetos que adotaram CI no ciclo de
vida deles e aplicamos essa mesma
mediana no tempo do ciclo de vida para
os projetos que não adotaram CI de forma
a ter um
parâmetro e justo de
comparação E aí nós analisamos
inicialmente a a primeira a seguinte
métrica o test rati né o test rate
basicamente é o volume do código de
teste produzido divid pelo volume de
código do sistema produzido no mesmo
período né então nós fizemos essa este
ratal de forma a normalizar os dados
para promover a comparação entre os
projetos de diferentes
naturezas né nós usamos uma técnica de
análise da tendência de crescimento ao
longo do tempo do test rate Uma técnica
estatística chamada dynamic time warp
match E basicamente o que a gente
encontrou nessa primeira investigação
foi que todos os projetos analisados CI
nós observamos que 40% dos projetos que
usaram CI tiveram uma tendência de
crescimento do test rate enquanto nos
projetos que não adotaram CI apenas 17%
tiveram essa mesma tendência nos de
aumento nos artefatos de teste Então
isso já foi um resultado interessante
bastante contundente aí dos benefícios
de adoção do CI Nós também
observamos que houve um aumento
consistente no teste ratal dos projetos
C em comparação com os projetos que não
adotaram C Então através de teste
estatístico nós vimos que os projetos
que adotaram C tiveram um aumento muito
mais consistente no test ratal ao longo
do seu ciclo de vida Finalmente uma
última comparação que a gente promoveu
foi em relação à cobertura dos testes né
porque tudo bem que o volume dos testes
estava maior para se mais em relação à
qualidade deles né então cobertura de
testes é um critério para avaliar a
qualidade dos seus testes Então nós
coletamos a cobertura dos testes pros
projetos antes e após adotar CI né
e antes e após o mesmo período de tempo
a projetos que não adotaram CI antes e
após um e 12 meses antes e 12 meses após
um determinado momento no seu ciclo de
vida selecionamos 10 projetos de cada um
do dos 82 de cada grupo né por que que a
gente só selecionou 10 projetos porque
como a gente tinha que analisar a
cobertura ao longo de 12 meses então
para cada projeto a gente teve que gerar
14 baixar né
14 o código fonte de desculpa de 24
meses né daquele projeto gerar o build e
executar os testes para ver a cobertura
do teste para aqueles 24 meses Então
para cada um do 10 projetos de C e 10
projetos não seis nós fizemos isso
Gustavo liderou né obviamente essas
configurações esse todo esse aspecto de
coletar a cobertura E após aplicar
testes estatísticos nós observamos que
dos de dos 10 projetos analisaram que
adotaram C nove deles mantiveram ou
aumentaram a cobertura de teste apenas
um reduziu a cobertura tá certo então
foi um resultado aí que de 10 projetos
novos mantiveram ou aumentaram a
cobertura Enquanto dos projetos que não
adotaram CI apenas quatro mantiveram
aumentaram o nível de cobertura e cinco
deles reduziram a cobertura tá certo
então foi um resultado aí bastante
contundente também das vantagens aí que
se aí trou para aumento da cobertura dos
testes de um dataset um pouco menor mas
com o resultado já bastante contundente
aí para mostrar as vantagens de CI
também pra melhoria da produção dos seus
testes automatizados Então a gente
observou essa correlação Então um outro
incentivo pro desenvolvedor que tá
interessado em convencer o seu gerente
seu product o do benefício de integração
contínua é que implicitamente a
qualidade do código vai melhorar através
da criação de testes
automatizados do aumento da cobertura
que não necessariamente tá ali
explicitamente escrito nos manuais e
livrinhos né muito legal Irá outro
trabalho interessante que você fez né é
sobre o impacto da integração contínua
no tempo de vida do P request Qual foi a
ideia deste trabalho o uso da integração
contínua acelera o tempo de vida do P
request Bom esse trabalho fez parte do
mestrado de João Wellé aqui na UFRN que
foi orientado conjuntamente com o
professor Daniel Alencar da Nova
Zelândia Eh e a questão central que a
gente investigou nesse trabalho foi se a
adoção de CI contribui para melhorar o
tempo de entrega de um purquest de um
projeto Então a gente tava investigando
aqui não mais se um request ele era
merged integrado mais rapidamente mas
também se ele era entregue mais
rapidamente numa release futura ou seja
algo totalmente relacionado com
continuous delivery né então nesse
projeto basicamente teve um setting
parecido né com trabalho de teste que eu
descrevi anteriormente mas nós
analisamos aqui 87 projetos que adotaram
CI ao longo do tempo especificamente
eles passaram a adotar o Travis CI num
dado momento do seu ciclo de vida E nós
analisamos 12 meses antes e 12 meses
após aspectos como o ciclo de vida de um
po request Em que tempo ele é merged ele
é integrado né numa numa branch do
principal do sistema em que em que
momento também esse B request é entregue
de fato numa release que vai ser
disponibilizada pro usuário Então nós
analisamos esses dois tempos e
basicamente o que a gente encontrou
inicialmente foi uma coisa interessante
que a gente descobriu que apenas cerca
de 51% dos projetos eles entregaram os
por request numa release mais
rapidamente após a adoção de se então
houve um bom equilíbrio aí entre a
quantidade de projetos que entregou
esses por requests em releases antes e
após a adoção de CI né apenas 51%
entregaram mais rápido após a adoção do
CI Nós também descobrimos que 50 em 54%
dos projetos analisados o ciclo de vida
de merge deliver do request foi mais
longo após a adoção de novamente um um
certo equilíbrio aí pros projetos antes
e após a adoção de se em seguida nós
fomos analisar a questão do volume de
request analisado nesse mesmo período
antes e após adoção né nos 12 meses
antes e após a adoção de CI E nós
percebemos então que
71 71% dos projetos aumentaram a entrega
de submissões de por requests após a
adoção E vimos então que boa parte dos
projetos tenderam a entregar 3.4 vezes
mais por requests após a adoção de
continuous integration por releases tá
certo bom para cada release após a
adoção se entregou 3.4 vezes mais por
request por projeto Isso foi uma
conclusão bastante interessante Apesar
do tempo de entrega ser bastante
equilibrado antes e após a adoção de
SIAR né 50% para cada lado a quantidade
de pull request entregue após o a adoção
foi 3.4 vezes maior na mediana Então
realmente uma quantidade aí
considerável do das vantagens de usar
SIA A gente até observou também como se
a promete entregar normalmente mais
releases no mesmo período de tempo A
gente verificou se haviam de fato mais
releases sendo entregues após a adoção
no Cai e a gente viu que havido
equilíbrio nessa frequência de release
por ano entre os projetos Ou seja de
fato entregou a mesma quantidade de
release mas esse release novamente
sempre 3.4 vezes mais por request após a
adoção de Cai do que antes da adoção
Então esse foi um trabalho interessante
Esse trabalho também foi uma coisa
interessante foi que ele foi replicado
né por um grupo da Alemanha usando um
arsenal estatístico diferente do que a
gente usou no projeto Então eles
reconduziram refizeram o estudo né com o
mesmo datas set entraram em contato etc
chegaram às mesmas conclusões atestar
essas mesmas conclusões que a gente
chegou Então foi uma um resultado bem
interessante aí que a gente teve Eh uma
coisa interessante é que atualmente e
João L já como parte do seu doutorado
ele tá estudando fazendo estudos
complementares né nós estamos mostrando
esses dados que foram encontrados nesses
projetos para as equipes desenvolvimento
desses 87 projetos nós apresentamos
dados encontrados e ele existe uma certa
dicotomia aí em dar razão a se ou não
para esse aumento no volume de por por
requests entregues né após o a cada
release após a adoção de C Então alguns
atribuem esse ganho a ao aumento da
popularidade do projeto e outros
atribuem esse ganho de fato a CA é um
bom equilíbrio aí nessa resposta né nos
dados preliminares que a gente tá
analisando Mas de fato mesmo o pessoal
que atribui ao aumento da popularidade
do projeto esse aumento de por requests
eles concordam que a adoção da prática
de CI contribuiu para lidar com esse
aumento da popularidade Ou seja em ambos
os casos eles concordam que continuous
integration de fato para lidar com esse
aumento do volume do projeto ou tá
diretamente relacionado com esse aumento
a capacidade de uma equipe poder lidar
com request Então trabalho bem
interessante aí que a gente conduziu que
atesta ainda mais aí as vantagens que se
aí pode trazer né ir a gente já falou
aqui sobre né várias atividades e
práticas que apoiam né o uso de
integração contínua no ambiente de
desenvolvimento Mas se você pudesse dar
alguma recomendação né alguma dica né
para alguma equipe que ainda não tá
praticando qual que seria né eh suas
principais sugestões para essa equipe né
o que que qual é o arsenal eh de
práticas técnicas e ferramentas que essa
equipe precisa ter para praticar
integração contínua
bom em termos de dicas sugestões para
implantar C e uma equipe é óbvio que
inicialmente você tem que ter um um bom
conhecimento técnico né de como por
exemplo montar
pipeline nesses servidores né como
configurar e escrever pipelines nesses
servidores de
forma eh que atenda né suas
necessidades etc Então procurar cursos
técnicos tecnológicos na internet que
atendam isso é bom E tá procurando
grupos de discussão que você possa
interagir com pessoas especialistas né
seja na rede seja na própria empresa que
você trabalha para você conhecer é
fundamental Então esse eu diria que são
as dicas do lado técnico né mas assim do
ponto de vista cultural eu acho que tem
muito mais desafios em buscar implantar
C em sua totalidade Então a gente já vê
hoje muitos projetos que utilizam CI no
que se refere a ter um pipeline que
integra o código e gera builds para eles
né então faz essa parte de compilação
geração de builds mas a gente percebe
que muitas equipes ainda não dão a
devida atenção à parte de automação de
teste que faz parte sim do ciclo de
integração contínua né sejam esses
testes de unidade integração ou até
mesmo sistemas Então considerando a
dificuldade que muitas vezes uma equipe
tem para adotar de cara teste de unidade
integração o que eu recomendo é iniciar
com a automação de alguns testes de
sistema aceitação que garantem uma certa
qualidade pro sistema né teste de
regressão smoked test a seleção de um
conjunto de funcionalidades relevantes e
críticas que devem ser testad
continuamente toda vez que um release do
software é liberado né então aquelas
funcionalidades que são mais críticas e
que são mais usadas para uma equipe de
desenvolvimento Então automatizar esses
testes de sistema ou aceitação com
ferramentas como Selenium ou Behave e
outras ferramentas de BDD Acho que é um
primeiro passo aí bem interessante pra
equipe avançar tendo em vista a
dificuldade de muitas vezes adotar de
cara teste de unidade integração mas que
deve também ser trabalhado em seguida E
aí você inclui esses testes de automação
de sistemas para serem executados por
exemplo pelo menos uma vez por semana ou
duas vezes por semana eh em um
determinado pipeline né então o software
vai ser instalado em uma máquina né
devidamente configurada eventualmente
virtualizada para com a virtualização do
sistema para executar essa bateria de
teste de sistemas Bom é importante
lembrar que apenas após a adoção de CI
de forma sólida com teste automatizado é
que você de fato vai conseguir migrar
seu projeto para também adotar a prática
de continuous delivery Então hoje em dia
é fundamental que você adote passe
também a incluir a parte de teste
automatizado na tua integração contínua
Caso contrário o teu continuous delivery
não vai ser sólido né não vai dar aquele
grau de confiança que se espera para se
fazer continuous delivering ou
deployment Então eh não adianta nada ser
tu ter tua arquitetura totalmente
estruturada em termos de
microsserviços ter pipeline sofisticado
se os teus testes automatizados não
garantir a qualidade do que vai pra
produção de forma automática ou quase
automática de nada vai adiantar seu
esforço Então essa é uma dica bastante
importante Corram atrás da parte técnica
mas não esqueçam desse lado cultural
dessas práticas de teste automatizado
que tem quem é necessariamente ser
seguir Agora que você
falou sugestões para quem quer implantar
C em sua equipe Agora um uma pergunta
que vai satisfazer os nossos ouvintes
mais da academia Quais são os problemas
científicos em aberto quando se fala de
integração contínua eu acho que ainda
existe bastante espaço para conduzir
pesquisas e estudos empíricos que
reforcem e atestem né os benefícios que
a integração contínua traz Então
procurar investigar outros benefícios
que têm sido reportado por artigos e às
vezes não tem sido devidamente
investigado com a profundidade que
merece né um outro tipo de pesquisa
possível também e averiguar a
dificuldade de adotar práticas de
integração contínua em diferentes tipos
de ambiente em spinoffs empresas
públicas né já que no desenvolvimento
open source em grandes empresas essa
prática tá muito bem consolidada Mas sem
dúvida nenhuma uma das principais áreas
abertas aí para pesquisa integração
contínua na verdade entrega contínua e
deployment contínuo né então existe
muita pesquisa para ser feita nessa área
Aí a indústria tá conduzindo e dando as
cartas né nesse sentido Aí acho que a
academia tem como apoiar e buscar
validar conduzir estudos que validem as
práticas que estão sendo
usadas ajudar nesse aprimoramento do que
já vem sendo proposto e utilizado por
eles como é que pode ser adaptado para
diferentes contextos e por aí vai Então
existe bastante espaço nessa área
Finalmente um outro nicho de pesquisa
que existe nessa área de integração e
entrega contínua é a parte de educação
né então é importante que as novas
gerações venham cada vez melhores
formadas né nessas práticas e que elas
se habituem com elas e se familiarizem
já desde os cursos de graduação Então
desde a formação a formação em teste de
software por exemplo tem que ser muito
bem destacada né dada a importância que
ela tem todo esse contexto A gente
conversou bastante sobre isso E nesse
contexto assim até aproveito para fazer
a propaganda que a gente tá começando um
projeto para enfatizar essa parte de
educação deops né e educação de técnicas
que envolve a entrega contínua Então é
uma área bastante interessante aí tem
bastante espaço pra pesquisa
Inicialmente com coisas de integração
contínua mas agora com a chegada de
integra contínua os desafios vão se
ampliar ainda
mais
[Música]
Eu acho que foi um excelente fechamento
agora né o IR com esse eh nosso meia
culpa aí para trazer mais integração
contínua para pra sala de aula para
ambientes né não só de equipe de
desenvolvimento até pra gente fazer com
que a nossa essa próxima geração né já
saia né da graduação né da pós-graduação
já muito bem alinhado com que assim as
práticas são padrões né eh dito isso eh
qual é a recomendação que você poderia
indicar né assim para nós professores
para nós alunos né para nós praticantes
de leitura deh de material de vídeo você
comentou alguma coisa mas tem aquela
pedra fundamental ali que não pode
passar batido tem aquele livro que todo
mundo devia ter na sua cabeceira Qual
Qual que é a sua sugestão de material de
integração contínua bom em termos de
materiais disponíveis pra área de
integração contínua eu recomendo a
leitura inicial dos posts do Martin Fer
sobre continuous integration fazendo
essa busca no Google você vai facilmente
encontrar os posts dele e ele fala de
forma bastante interessante sobre o tema
e organiza também muito material
bibliográfico em torno do que ele fala
né e do que
ele reporta sobre que ele conhece de
integração contínua inclusive na empresa
dele Uma outra referência bastante boa
pra Continuous Delivery é o Jazz Rumble
né ele também mantém um site com
bastante informação sobre continuous
delivery Ele tem um dos principais
livros também da área Outras dicas é
acompanhar sites de coisas práticas né
sobre engenharia de software então sites
comunidade de desenvolvedores mesmo Um
dos mais interessantes que eu acho é o
Infocube então bastante legal para
seguir mas existem outros
similares E
finalmente para toda a parte de teste
configuração de
pipelines é outras tecnologias de
continuous delivery é interessante para
você pode por exemplo fazer cursos da
UDM né existem cursos online disponíveis
a preços
acessíveis ou até mesmo gratuito Então
são fontes também bastante interessantes
e que mostram como usar tal tais
tecnologias sobretudo no em caráter
inicial no introdutório
[Música]
O Irá para você qual é a próxima
fronteira da engenharia de software qual
é a próxima fronteira da engenharia de
software acho que sem dúvida alguma a
próxima fronteira da engenharia de
software é adaptar ajustar a engenharia
de software paraa produção de sistemas
inteligentes né a gente tá vendo em
todas as conferências em todo mundo a
necessidade né de os softwares cada vez
mais adquirirem funcionalidades de
machine learning de técnicas de
inteligência artificial Então sem dúvida
isso já é uma tendência hoje em dia Cada
vez mais essa tendência vai ser forte
Óbvio que tudo o que foi proposto
anteriormente vai continuar valendo né
porque nem toda as partes dos sistemas
produzidas vão vão ser inteligentes mas
o que vai haver de mais desafiante sem
dúvida nos próximos anos é a parte de
engenharia de sistemas inteligentes e o
próprio uso dessas técnicas de machine
learning e para apoiar atividades de
engenharia de software como por exemplo
já é usado em mineração de repositório
de software ou em outras áreas aí
relacionadas Mas um outro uma outra
fronteira um outro desafio que eu acho
que vai ser contínuo sempre paraa área
da gente acho que a gente melhorou e
avançou bastante nisso é a interação com
a indústria né então a gente tem
melhorado bastante a interação com a
indústria tanto com a comunidade open
source né através da de uma maior
interação e uma maior melhor análise dos
projetos que lá existem sobre
desenvolvimento open source assim como
também num contato maior através de
pesquisas eh que promovem uma interação
maior com membros da membros da
indústria desenvolvedores etc Então esse
é um aspecto muito importante para quem
desenvolve pesquisa engenharia de
software tá sempre próximo procurando se
aproximar da indústria seja para
descobrir o problema seja para expor as
soluções do que ele vem propondo né
então eu diria que esses dois aspectos
são muito importante aí engenharia de
software de sistemas inteligentes e a
interação melhorar cada vez mais a
interação com a indústria Então irá
muito obrigado por mais esta entrevista
Foi foi um prazer conversar com você E
um grande abraço Um abraço também Eu que
agradeço o convite e sucesso aí no
podcast de vocês Tô sempre acompanhando
e assistindo e aprendendo aí Assistir os
primeiros Vou assistir com certeza todos
os próximos Obrigado Irá Tchau Tchau
pessoal
[Música]
Olá obrigado por escutar o Fronteiras da
Engenharia de Software Nossa equipe é
formada por Marco Túlio Valente Marcela
dos Santos Leonardo Fernandes Gustavo
Pinto Fábio Petrilo Danilo Monteiro e
Adolfo Neto Sou eu Estamos no Twitter e
no Instagram como
@fronteirases Até o próximo episódio
Abraços
[Música]
Esse podcast foi editado pela produtora
Reis