Integração Contínua de faz-de-conta, qualidade de faz-de-conta: Como Integração Contínua leva a qualidade de software apresentada no The Developer Conference Porto Alegre 2017.
Por Camilla Crispim
OI, EU SOU CAMILLA CRISPIM
SOU TECNOLOGISTA LÍDER NA THOUGHTWORKS BRASIL
ONDE FIZ PARTE DE VÁRIOS PROJETOS DE SOFTWARE COMO DESENVOLVEDORA E LÍDER TÉCNICA
ATUALMENTE EU SOU PARTE DO ESCRITÓRIO DA CTO GLOBAL DA THOUGHTWORKS
ESTRATÉGIA DE TECNOLOGIA DA THOUGHTWORKS: OLHA PARA AS MACRO TENDÊNCIAS DA TECNOLOGIA E COMO ISSO DEVE AFETAR OS NOSSOS CLIENTES E A SOCIEDADE
E SOU PARTE DO GRUPO QUE PRODUZ O RADAR TECNOLÓGICO
BOM…
QUEM AQUI JÁ TEVE BUGS EM PRODUÇÃO? TODO MUNDO NÉ…
QUEM AQUI CONHECE E FAZ INTEGRAÇÃO CONTÍNUA?
E IMPLANTAÇÃO CONTÍNUA?
E ENTREGA CONTÍNUA?
BOM, EU FIZ QUESTÃO DE IR ALÉM DE INTEGRAÇÃO CONTÍNUA PRA PELO MENOS DEIXAR CLARO QUE NÃO SÃO A MESMA COISA… INFELIZMENTE O ASSUNTO É AMPLO E NÃO TEMOS TEMPO DE COBRIR TUDO AQUI…
O FOCO É EM COMO INTEGRAÇÃO CONTÍNUA AJUDA E LEVA A QUALIDADE DE SOFTWARE.
ANTES DE MAIS NADA… EU QUERO ESCLARECER UMA COISA
EU NÃO TO DIZENDO QUE SEM INTEGRAÇÃO CONTÍNUA VOCÊ NÃO TEM E NUNCA TERÁ QUALIDADE...
O QUE EU QUERO DIZER É QUE, SE VOCÊ ACHA QUE FAZ INTEGRAÇÃO CONTÍNUA E NÃO FAZ
VOCÊ PODE ACABAR ACHANDO QUE TEM QUALIDADE QUANDO NÃO TEM…
POR QUE SERÁ QUE TEM UM NÚMERO CONSIDERÁVEL DE PESSOAS AQUI QUE FAZ CI E TAMBÉM TEM PROBLEMAS EM PRODUÇÃO?
MAS, MAIS AINDA, O QUE EU TO DIZENDO É QUE SE VOCÊ FAZ CI DE VERDADE, VOCÊ PODE DESFRUTAR DE TODOS OS BENEFÍCIOS DELE E NA MINHA OPINIÃO, AUMENTO DE QUALIDADE É UM DELES.
E A GENTE VAI VER COMO UM POUCO MAIS NA FRENTE...
MAS ANTES DE MAIS NADA, PARTE 2 -
EU JÁ VI DENTRO E FORA DOS PROJETOS QUE EU PARTICIPEI, MUITA CONFUSÃO SOBRE O QUE É INTEGRAÇÃO CONTÍNUA.
ENTÃO, O QUE É INTEGRAÇÃO CONTÍNUA?
INTEGRAÇÃO CONTÍNUA É UMA PRÁTICA E NÃO UMA FERRAMENTA. É IMPORTANTE TER ISSO BEM DEFINIDO.
NÃO SE DEVE CONFUNDIR CI COM GIT OU ALGUMA OUTRA FERRAMENTA DE VERSIONAMENTO DE CÓDIGO E NEM MESMO COM SERVIDORES DE CI.
É COMUM ESCUTAR "EU FAÇO CI. MEU PROJETO TEM UM JENKINS RODANDO..." - NA VERDADE, VOCÊ TEM UM SERVIDOR DE INTEGRAÇÃO CONTÍNUA, NÃO NECESSARIAMENTE VOCÊ FAZ INTEGRAÇÃO CONTÍNUA.
INCLUSIVE, TEM UM ARTIGO BEM INTERESSANTE DO JAMES SHORE EM 2005 NO QUAL ELE EXPLICA COMO FAZER O PROCESSO DE FORMA MANUAL - CI IS AN ATITUDE, NOT A TOOL - "http://www.jamesshore.com/Blog/Continuous-Integration-is-an-Attitude.html"
A PRÁTICA CONSISTE EM:
DESENVOLVEDORAS FAZEM MUDANÇAS NO CÓDIGO A PARTIR DA ÚLTIMA VERSÃO DA APLICAÇÃO QUE ESTÁ FUNCIONANDO
INTEGRAM ESSAS MUDANÇAS NO REPOSITÓRIO COMPARTILHADO
O SERVIDOR DE CI É DISPARADO A PARTIR DESSA INTEGRAÇÃO E EXECUTA TAREFAS
COMPILAÇÃO DE CÓDIGO
TESTES (EM VÁRIOS NÍVEIS)
E AO FINAL, DA UM FEEDBACK SE A MUDANÇA INSERIDA INTEGRA CORRETAMENTE COM A APLICAÇÃO OU NÃO
FAZENDO UM PARALELO AQUI COM O MANIFESTO ÁGIL, QUE DIZ "SOFTWARE FUNCIONANDO ACIMA DE DOCUMENTAÇÃO COMPLETA"...
INTEGRAÇÃO CONTÍNUA, PRA MIM, É A FORMA DE TER SOFTWARE FUNCIONANDO A QUALQUER MOMENTO
E AQUI, POR FUNCIONANDO, NÃO É APENAS CÓDIGO COMPILANDO, MAS O CÓDIGO FAZER O QUE DEVE SER FEITO, FAZER CORRETAMENTE O QUE SE PROPÕE - E ISSO PRA MIM É QUALIDADE:
ATENDER AS NECESSIDADES DA CLIENTE
E FUNCIONAR CORRETAMENTE
MAS... COMO AFINAL CI LEVA A QUALIDADE DE SOFTWARE?
O PRIMEIRO FATOR SÃO TESTES AUTOMATIZADOS E ABRANGENTES
QUANDO SE FAZ CI DE VERDADE, TEMOS QUE TER CÓDIGO AUTO TESTÁVEL
OU SEJA - TODO CÓDIGO TEM TESTE!
E VOCÊS PODEM PENSAR QUE A RELAÇÃO CI/QUALIDADE AQUI É ÓBVIA, MAS VAI ALÉM DO FATO DE TER TESTES
E TESTES AUTOMATIZADOS
NUM CONTEXTO COMO ESSE AS DESENVOLVEDORAS TAMBÉM ESCREVEM TESTES
A RESPONSABILIDADE VAI ALÉM DO ANALISTA DE TESTES - OU DO TESTE AUTOMÁTICO SER ESCRITO NUMA ETAPA DIFERENTE
A MUDANÇA É NO TIME: EM TERMOS DE PAPÉIS E RESPONSABILIDADES.
AQUI, SILOS FUNCIONAIS (DESENVOLVIMENTO E TESTES) COMEÇAM A SE DILUIR.
ALÉM DISSO, TRAZ BENEFÍCIOS COMO CONFIANÇA E AUTONOMIA PARA AS PESSOAS DO TIME, QUE POR TEREM UMA BOA COBERTURA DE TESTES, SE SENTEM SEGURAS EM FAZER MUDANÇAS E ADICIONAR FUNCIONALIDADES
O SEGUNDO PONTO É: ENXERGUE O BUILD COMO UM TERMÔMETRO
E É POR ISSO QUE ELE TEM QUE ESTAR BEM VISÍVEL PARA TODO O TIME!
O ESTADO E O TEMPO DO BUILD SÃO MUITO IMPORTANTES
COM O ESTADO DO BUILD SABEMOS SE O CÓDIGO INTEGRADO FUNCIONA - TEMOS UM RÁPIDO FEEDBACK DISSO
SE O BUILD QUEBRAR, NÃO TEM PROBLEMA. NÃO DEVE TER ISSO DE "AH, MAS O SEU CÓDIGO QUEBROU".
NÃO. "O NOSSO CÓDIGO JUNTO NÃO FUNCIONA" - "VAMOS PARAR TUDO AQUI E RESOLVER".
O BUILD É DE RESPONSABILIDADE DE TODAS E TER ISSO EM MENTE TRAZ UMA MUDANÇA DE MINDSET TO INDIVIDUAL PARA O COLABORATIVO.
SE FALHAS POR PROBLEMAS EM CONFIGURAÇÃO OU AMBIENTE APARECEM, LEVANTA-SE O QUESTIONAMENTO SOBRE O QUÃO IGUAIS OS AMBIENTES DE DESENVOLVIMENTO, TESTE E PRODUÇÃO, POR EXEMPLO SÃO IGUAIS - O QUE LEVA À MENOS PROBLEMAS DE IMPLANTAÇÃO.
BOM, É INTERESSANTE QUE O FEEDBACK SEJA RÁPIDO. SE O TEMPO DO BUILD ESTIVER MUITO ALTO PODE RETARDAR O PROCESSO DE INTEGRAÇÃO…
MAS, SE POR EXEMPLO, O BUILD ESTÁ DEMORANDO PARA EXECUTAR OS TESTES, CONVERSAS INTERESSANTES SOBRE A ESTRATÉGIA DE TESTES E O FORMATO DA PIRÂMIDE DE TESTES - QUE ACABAM MELHORAM A QUALIDADE DO SOFTWARE QUE ESTÁ SENDO FEITO
TODAS DO TIME DEVEM INTEGRAR SUAS MUDANÇAS PELO MENOS UMA VEZ POR DIA. MAS IDEALMENTE, MAIS QUE ISSO. NO CI DE VERDADE, O IDEAL É QUE TODO COMMIT SEJA INTEGRADO COM SUCESSO AO BUILD.
PRA SER POSSÍVEL FAZER ISSO, É PRECISO, MAIS UMA VEZ MUDAR O MINDSET E COMEÇAR A TRABALHAR COM PEQUENAS MUDANÇAS.
COM ISSO SE TEM MAIS CLAREZA DO QUE PRECISA SER FEITO E DÚVIDAS SOBRE CERTOS COMPORTAMENTOS DO QUE ESTÁ SENDO DESENVOLVIDO SÃO SANADAS AINDA EM DESENVOLVIMENTO. O DESENVOLVEDOR FALA DIRETO COM CLIENTE, SEM PROXY.
ISSO GARANTE QUE ESTAMOS FAZENDO A COISA CERTA, ALÉM DE FAZER CERTO A COISA. ANTECIPA RISCOS E AUMENTA A SATISFAÇÃO DO CLIENTE. IMAGINA CHEGAR NUM SHOWCASE E O CLIENTE DIZER "MAS NÃO FOI ISSO QUE EU PEDI"
MAIS UMA VEZ TEMOS UM FEEDBACK RÁPIDO SE O SOFTWARE CONTINUA FUNCIONANDO E A INTEGRAÇÃO CONTÍNUA, DE PELO MENOS UMA VEZ AO DIA, PROMOVE CONVERSAS SOBRE DESIGN, ABORDAGEM, E ATÉ DEIXA EXPLÍCITO POSSIBILIDADES DE REFATORAÇÃO MAIS CEDO NO DESENVOLVIMENTO.
COMO EVOLUIR O SERVIDOR DE CI? FAZENDO DELE UMA PIPELINE, COM PROCESSO AUTOMATIZADO PARA IMPLANTAÇÃO E ENTREGA DE SOFTWARE EM PRODUÇÃO.
QUANDO SE FAZ INTEGRAÇÃO CONTÍNUA COM TODOS OS ELEMENTOS QUE EU CITEI, SE O BUILD ESTÁ VERDE, TEMOS CONFIANÇA O SUFICIENTE PARA IMPLANTAR AQUELE PACOTE EM PRODUÇÃO.
IDEALMENTE, SEM NENHUM OUTRO PROCESSO "AH, MAS TEM QUE PASSAR POR HOMOLOGAÇÃO" - NÃO. SE O BUILD PASSOU, PODE COLOCAR EM PRODUÇÃO!
PORQUE A PIPELINE AGORA É O SEU PROCESSO AUTOMATIZADO: É POSSÍVEL TER OS MESMOS PASSOS ANTES FEITOS MANUALMENTE PARA TESTE E IMPLANTAÇÃO NOS DIFERENTES ESTÁGIOS DA SUA PIPELINE.
TESTES AUTOMATIZADOS. TESTES MANUAIS EM DIFERENTES AMBIENTES. TESTES DE PERFORMANCE E DE CARGA E ATÉ DE ACESSIBILIDADE.
COM UMA PIPELINE COM TESTES E AMBIENTES IGUAIS AO DE PRODUÇÃO É POSSÍVEL ANTECIPAR PROBLEMAS E NUNCA MAIS TER QUE PASSAR VERGONHA E DIZER "MAS FUNCIONA NA MINHA MÁQUINA"
QUANDO QUISER IR ALÉM - PENSE NA UTOPIA: QUAL O SERVIDOR DE CI DOS MEUS SONHOS? O QUE FAÇO HOJE MANUALMENTE OU NUMA ETAPA SEPARADA QUE PODE SER UM ESTÁGIO DO MEU SERVIDOR DE CI?
A PRIMEIRA COISA É:
FAÇA CI DE VERDADE. NÃO SE ENGANE ACHANDO QUE PORQUE VOCÊ TEM FERRAMENTAS, VOCÊ ESTÁ USUFRUINDO DOS BENEFÍCIOS DE CI
RECAPTULANDO:
1 - TESTES AUTOMATIZADOS E ABRANGENTES: TESTES ESCRITOS POR TODAS E TAMBÉM DURANTE O DESENVOLVIMENTO.
2 - BUILD É O SEU TERMÔMETRO: NÃO IGNORE UM BUILD QUEBRADO OU O TEMPO QUE DEMORA PARA EXECUÇÃO. FIQUE ATENTA AOS INSIGHTS E AS DISCUSSÕES QUE ISSO PODE TRAZER SOBRE A SUA ESTRATÉGIA DE TESTES
3 - INTEGRE CÓDIGO PELO MENOS UMA VEZ AO DIA: SE PUDER, INTEGRE MAIS. COMECE ADICIONANDO PEQUENAS MUDANÇAS. ISSO VAI MUDAR A FORMA COM QUE VOCÊ DESENVOLVE SOFTWARE.
4 - VÁ ALÉM DA INTEGRAÇÃO CONTÍNUA. MIRE EM IMPLANTAÇÃO E ENTREGA CONTÍNUA. NINGUÉM GOSTA DE TER QUE FICAR ACORDADO DE MADRUGADA PRA FAZER UM DEPLOY. E SE QUISER SABER MAIS SOBRE ISSO, A LITERATURA É BEM VASTA E PODEMOS BATER UM PAPO LÁ FORA SOBRE COMO FAZER ISSO ACONTECER.
