Concrete Logo
Hamburger button

Integração e Deployment Contínuos como motor de Métodos Ágeis

  • Blog
  • 17 de Fevereiro de 2014
Share

O que IC/DC tem a ver com Agile?

Se considerarmos como fundamentos das metodologias ágeis os 3 pilares transparência, inspeção e adaptação, as práticas de engenharia mencionadas (IC/DC) fornecem as ferramentas necessárias para aumentar a transparência e a nossa capacidade de inspeção. Além disso, ajuda a reduzir o tempo de cada ciclo de entrega, aumentando a oportunidade do time de se adaptar mais rapidamente (terceiro pilar).

De uma maneira geral, essas práticas tendem a aumentar a qualidade do desenvolvimento do projeto, tornando-o mais apto a atender as demandas que virão ao longo de sua vida útil . Portanto, sem precisar entrar em detalhes, já conseguimos observar que IC/DC têm tudo a ver com a cultura ágil.

IC – Integração Contínua

Integração contínua é uma prática de engenharia de software que teve origem no XP (Extreme Programming) e resume-se a integrar partes distintas do código na maior frequência possível, ou seja, continuamente. O problema que ela se propõe a resolver é comumente conhecido como “integration hell”, quando diversas partes do código e/ou projeto funcionam separadamente, mas juntas se tornam incompreensíveis. E pior: Cada parte que funciona de forma independente, por si só, não gera valor. Para esse valor ser gerado as partes precisam ser integradas. Em algumas metodologias tradicionais (waterfall, por exemplo) era comum planejar uma fase de integração no final do projeto, na qual as peças do quebra-cabeça eram encaixadas e tudo deveria funcionar como planejado meses ou anos antes. Obviamente, hoje sabemos que essa abordagem era furada e na esmagadora maioria das vezes não dava certo.

quebra-cabeças

Se pararmos para pensar, isso era de se esperar. Grandes problemas surgem ao integrar partes distintas do sistema, intensificados pela dificuldade ainda maior de prever que tipo de problemas a interação destas distintas e, até então, separadas partes, podem trazer para o projeto. Integração Contínua é o inverso disso: garantimos que as peças do quebra-cabeça sejam encaixadas assim que estejam “prontas” e tenham sido enviadas ao repositório de peças. Essa abordagem diminui o risco, trazendo muitas questões fundamentais para o presente e garantindo que problemas de integração sejam resolvidos o mais rápido possível. Além disso, como essa integração é feita o tempo todo e com pedaços menores de código, é menos propensa a erros, garantindo que o valor do projeto seja preservado. Sabemos o tempo todo que todas as peças funcionam juntas.

Deixando a história de lado, na internet existem diversos textos que explicam com muito mais detalhes e aprofundamento o que é e porque fazer IC, como este artigo do Martin Fowler, por exemplo.

Na prática, o que precisamos ter em mente ao falarmos de IC são alguns passos simples, que serão atendidos por nosso servidor de Integração Contínua:

– Nosso código será integrado a cada push (ou de tempos em tempos). Ou seja, toda vez que as mudanças no código forem sincronizadas com o repositório, o servidor de IC vai fazer o pull do mesmo e o build do projeto.

sincronia

– Testes automatizados rodarão após o build do nosso projeto para garantir que bugs já encontrados não voltem e os cenários de testes continuem a funcionar.

Após cada mudança no código:

– Emails serão enviados para os responsáveis caso o build seja quebrado ou os testes não passem, para que eventuais problemas possam ser corrigidos o mais rápido possível.

– Um artefato (entregável do projeto) será gerado ao final de um build de sucesso, build + testes passando.

– Relatórios serão publicados (são um plus, não são necessários, mas agregam valor ao CI)

DC – Deployment Contínuo

Deployment Contínuo é outra prática de engenharia de software, que começa onde IC termina. Após realizar os passos do IC (baixar o código, integrar, build, rodar os testes e gerar o artefato), faz sentido se questionar sobre o próximo passo.

So, what’s the next step? A resposta simples é “deployar” esse artefato em algum lugar em que ele possa ser visto ou usado de uma maneira igual ou próxima com a qual ele será usado em produção. Vamos ilustrar melhor a ideia:

1 – Imagine que você está desenvolvendo uma API (Application Programming Interface) e, após o push de uma nova funcionalidade, você queira vê-la em QA/produção. Em uma abordagem tradicional, o seu trabalho só começou após o push para o repositório. Agora você precisa “buildar” e “deployar” manualmente para seu ambiente de QA.

É um trabalho chato, repetitivo, propenso a erro e que definitivamente não deveria ser feito mais de uma vez. É exatamente aqui que podemos perceber o valor do Deployment Contínuo trabalhando junto com a Integração Contínua. Após adotar essas práticas, seu trabalho se resume a “pushear” código para o repositório e a sua Deployment Pipeline se encarregara de “buildar”, rodar os testes, gerar o artefato e “deployar” o mesmo no ambiente esperado.

2 – Imagine que você está desenvolvendo uma app IOS/Android. Após terminar uma nova feature, você está querendo mostrá-la para os stakeholders . O que muitas vezes acontece é que você acaba ficando refém de passar o app para os respectivos celulares através de cabo USB e coisas do tipo (muito mais fácil certo? wrong), tornando seu processo de “deploy” um processo 1-1, que é péssimo, cansativo e trabalhoso.

Imagine que você precise passar para 5 celulares pelo USB. Tudo bem, certo? 10 minutos, no big deal. Agora considere que sejam 100 e que você faça dois releases por dia. Já fiquei cansado só de pensar no trabalho.

caveira

Deve existir algum jeito melhor, não? Sim, existe. Como no exemplo anterior, usar Deployment Contínuo faz todo o sentido nesse cenário. Pense que o seu trabalho, após adotar a prática, será “pushear” o código para o repositório. Depois disso o Deployment Pipeline se encarregará de “buildar”, testar, gerar seu apk/ipa , gerar uma url e mandar um email para os stakeholders, que poderão baixar a app com 1 clique. Sounds much better, right? Processo de deploy 1-n.

Exemplos não faltam. E antes que você pense “tudo bem, muito legal, mas não funcionaria no meu sistema ou no meu projeto”, veja esse post do Steve Blank que conta a história da Tesla, fabricante de carros elétricos americana que faz Deployment Contínuo em carros. Se eles conseguiram fazer isso com carros, acredite: você também pode adotar essa prática.  Sim, existem desafios relacionados a como fazer deployment contínuo mas eles não são técnico mas sim de como gerenciar a expectativa do cliente em relação a mudanças no produto.

Experiência

Aqui na Concrete Solutions já faz tempo que nos preocupamos em montar o Deployment Pipeline e adotar estas práticas de engenharia de software nos projetos que temos feito, desde os primeiros passos do desenvolvimento. Após diversos projetos, eu não poderia ter outra palavra para descrever o resultado se não “sucesso”. O aumento da transparência diminui a ansiedade dos stakeholders e normalmente faz com que todos os envolvidos participem mais ativamente do projeto. Fora que, para o time que adota essas práticas, o desenvolvimento fica muito mais leve e tranquilo, pois tarefas chatas e repetitivas são automatizadas.

Scrum por si só, ou qualquer metodologia ágil, representa um avanço, mas com o tempo a adoção dessas outras práticas de engenharia darão sustentação a qualquer mudança, com aumento da produtividade e da qualidade do projeto como um todo, nas mais diversas esferas.

Considerações finais

Por último, quero deixar claro que essas práticas por si só não são garantia de qualidade no código e, consequentemente, melhoria do seu produto final. De nada adianta usar integração contínua se você não tiver testes automatizados, para destacar um exemplo. Essas práticas geram real valor quando combinadas com outras tantas de engenharia de software, muitas originadas do XP (Extreme Programming), tais como pair programming, code review, refactoring, entre outras. Agile é mais uma mudança cultural do que qualquer outra coisa e seu maior beneficio está aí.

time

A ideia é que as práticas e a cultura criem ao redor do time/empresa uma “safety net” que favoreça o aprendizado, a melhoria contínua (kaizen) e o desenvolvimento pessoal. Cultura corporativa é um tópico extenso com muitos exemplos para estudarmos (Google, Facebook, etc). Para fechar, vou deixar esse link de um livro que fala como a Toyota desenvolveu uma cultura corporativa invejada ao redor do mundo, cultura essa que deu origem ao lean, grande influência para as metodologias ágeis.

Tem alguma dúvida? Gostaria de acrescentar alguma coisa? Comente!

PS: Estou publicando uma série de posts sobre integração contínua em iOS. Se você ainda não viu, pode aprender com a parte 1 neste link e a parte 2 neste aqui.