Integração Contínua em Desenvolvimento Agile

Como métodos agile, integração contínua e orientação a teste aprimoram o design e o desenvolvimento de sistemas complexos

Este artigo explora como técnicas de desenvolvimento agile, continuous integration (CI) e test-driven development (TDD) podem ser empregadas no desenvolvimento de software integrado. Quando aplicadas como parte de uma abordagem baseada em arquitetura, essas práticas combinadas fornecem alta qualidade e flexibilidade de projeto.

Martin R. Bakal, WW Offering Manager, Electronics Industry, IBM

Author1 photoMarty tem mais de uma década de experiência de trabalho em várias funções no segmento de mercado de software e sistemas embarcados, com ampla experiência de cliente no mundo todo em diversos segmentos de mercado, incluindo consumidor, telecomunicações, automotivo e médico. Atualmente, ele é Worldwide Senior Offering Manager para o segmento de mercado de eletrônica na IBM Rational, liderando, nesse cargo, a iniciativa em todo esse segmento de mercado.



Jennifer Althouse, Systems Sales Leader, IBM

author photoJennifer Althouse tem mais de uma década de experiência profissional em diversas capacidades no desenvolvimento de sistemas complexos e projetos de software. Ela tem ampla experiência de cliente em vários segmentos de mercado, incluindo aeroespacial, eletrônica e dispositivos médicos. No momento, Jennifer é Electronics Industry Specialist na IBM Rational.



31/Ago/2012

Por uma década ou mais, as equipes de software beneficiaram-se de métodos de desenvolvimento agile. Elas adotaram essas práticas de desenvolvimento iterativo e incremental, em que as soluções evoluem através de desenvolvimento colaborativo. Normalmente, abordagens tradicionais não agile para a criação de software contam com um fluxo de desenvolvimento mais controlado. Um exemplo disso é o processo em cascata, em que cada atividade de requisitos, design, desenvolvimento e teste é realizada de modo serial.

Embora o desenvolvimento em cascata tenha sido o padrão para o desenvolvimento de sistemas grandes e complexos por muitos anos, ele possui várias falhas notáveis. A primeira é que muito do trabalho é desperdiçado tentando concluir documentos antes de designs, e designs antes de código, embora se saiba que os requisitos mudarão ao longo do tempo. Outra é que, atrasando teste e integração até o final do projeto, os problemas frequentemente são descobertos tarde demais para serem resolvidos sem causar descumprimento de prazos. Esses dois fatores, combinados, podem ter sido toleráveis em um mundo que se movimentava a um ritmo mais lento. Mas conforme a pressão para criar sistemas inovadores aumentou, a habilidade dessa abordagem de atender as necessidades das organizações diminuiu.

Embora tenham sido popularizadas por equipes que desenvolvem sistemas de TI, as práticas agile podem se aplicar igualmente bem ao desenvolvimento de produto em que o produto consiste em hardware, eletrônicos e software. O desenvolvimento de software integrado difere do desenvolvimento de aplicativos de TI, principalmente na disponibilidade limitada dos recursos de destino de implementação, como desempenho do processador e memória. O software integrado, muitas vezes, executa operações em tempo real complexas nessas condições restritas. Pense em um sistema controlado por computador, como os airbags de um carro. Eles precisam ser ativados imediatamente, mas também de maneira confiável. Originalmente, os métodos agile foram projetados para equipes de projeto menores e colocalizadas em segmentos de mercado não regulamentados. Demorou muitos anos para serem estendidos de modo que a abordagem agile pudesse acomodar projetos de desenvolvimento maiores e mais complexos.

Quando aplicados como parte de uma abordagem baseada em arquitetura, continuous integration (CI) e test-driven development (TDD), estendem as práticas agile básicas o suficiente para fornecer alta qualidade e flexibilidade de projeto. Este artigo explora como os métodos agile, CI e TDD podem ser empregados no contexto de desenvolvimento de software integrado. E, além disso, também descreve os benefícios dessa combinação.

Como integração contínua e desenvolvimento conduzido por teste enquadram-se na prática agile

Atualmente, a maioria das pessoas já ouviu falar de métodos agile. Os conceitos que eles trouxeram para o desenvolvimento de software mudaram a maneira como as equipes organizam o trabalho, adaptam-se a requisitos inconstantes e liberam software. A continuous integration (CI) foi criada para desenvolvimento agile, de modo que a abordagem agile está no contexto de qualquer discussão de CI. Ela organiza o desenvolvimento em histórias de usuário funcionais.. Essas histórias são priorizadas em grupos de trabalho menores, ou sprints..

A ideia não é tentar solucionar todos os problemas antecipadamente, mas, em vez disso, focar no que já se sabe. Assim, a equipe projeta, desenvolve e testa o que sabe sobre a funcionalidade desejada. Isso cria um produto de trabalho baseado em um subconjunto dos requisitos completos de produto. Então, a equipe passa para o conjunto de requisitos com a próxima prioridade mais alta e repete o processo. É claro, essa é uma visão muito simplificada, e há muitas variantes desse processo, mas o ponto principal é desenvolver o produto de maneira incremental e tentar melhorar as coisas no processo.

De acordo com Martin Fowler, da ThoughtWorks, integração contínua é uma prática de desenvolvimento de software que requer que os membros da equipe integrem o trabalho com frequência. Todas as pessoas integram, pelo menos, diariamente, o que ocasiona várias integrações por dia. As integrações são verificadas por um desenvolvimento automatizado que executa testes de regressão para detectar erros de integração o mais rapidamente possível. As equipes veem que essa abordagem conduz a, de modo significativo, menos problemas de integração e permite o desenvolvimento de um software coeso com mais rapidez.

Isso proporciona o detalhe final que determina o sucesso da execução de um processo de CI. Se a ideia de integrar de modo contínuo é encontrar problemas rapidamente, dando a cada desenvolvedor feedback sobre o trabalho, então deve haver alguma maneira de avaliar esse trabalho rapidamente. O desenvolvimento conduzido por teste preenche essa lacuna. Com TDD, você cria o teste e, então, desenvolve a funcionalidade até que o código seja aprovado no teste. Conforme cada nova adição ao código é feita, o teste pode ser adicionado ao conjunto de testes que são executados quando você desenvolve o trabalho integrado. Isso garante que novas adições não interrompam o trabalho em funcionamento que veio antes delas, e os desenvolvedores cujo código de fato "interrompe o desenvolvimento" podem ser notificados rapidamente. Uma combinação típica de integração contínua e desenvolvimento conduzido por teste é ilustrada na Figura 1.

Figura 1. Uma prática agile usando integração contínua e desenvolvimento conduzido por teste
Uma prática agile usando integração contínua e desenvolvimento conduzido por teste

Tipos de projetos que se beneficiam de integração contínua

Equipes de menos de 50 pessoas trabalhando em projetos menos complexos eram, com certeza, o campo de testes para desenvolvimento agile e CI. Mas conforme os produtos se tornaram "mais inteligentes", houve um aumento significativo na complexidade.

A quantidade de software integrado indo para produtos tradicionais é incrível. Atualmente, um carro novo é comercializado menos por sua potência e mais por sua tecnologia de software integrada (autoestacionamento, avisos de segurança avançados, eficiência em combustível, sistema de entretenimento informativo, por exemplo). O número de linhas de código escritas para criar um novo carro é maior que o número de linhas escritas para um caça F16.

Esse aumento na complexidade dos produtos veio simultaneamente com uma redução no tempo para comercializar novos produtos. A prevalência de software integrado, junto com prazos mais apertados, trouxe as práticas agile e CI para os desenvolvedores integrados.


Usando métodos agile para o desenvolvimento de sistemas integrados

Os métodos agile permitem que as equipes de software e sistemas respondam rapidamente a mudanças. A abordagem agile reduz o risco de planejamento associado à engenharia de software tradicional, em que a integração de peças de componentes é tratada como um esforço de fase avançada. Essa integração de fase avançada faz interpretações incorretas das especificações de design que serão descobertas tarde demais para que as equipes corrijam os problemas e ainda cumpram os prazos.

Ainda assim, as equipes de sistemas que produzem mais que apenas o componente de software têm sido céticas quanto a certos aspectos da abordagem agile. Elas afirmam que essa abordagem remove demais o planejamento antecipado e você acaba com uma integração fraca de software e hardware. Sem os pontos de verificação antecipada e frequente que validam o processo com relação ao blueprint de arquitetura, uma equipe pode falhar em produzir um componente que possa funcionar no sistema mais amplo. Além disso, para desenvolvedores de sistemas complexos que estão buscando reusabilidade de design ou escalabilidade para requisitos de projeto maiores, os métodos agile podem parecer limitados.

Esses temores são compreensíveis, porque a modelagem e a arquitetura não são o marco das técnicas agile. Mas a abordagem de CI para o desenvolvimento de sistemas oferece várias melhorias sobre métodos agile puros. A CI ajuda as equipes de desenvolvimento de sistemas a serem agile e a responderem a rápidas mudanças de negócio, garantindo, ao mesmo tempo, que o hardware e o software reais em desenvolvimento estejam em constante sincronia. A CI permite aos membros da equipe trabalhar de maneira eficaz em seus grupos de domínio, focados nas tarefas que fazem melhor. Ao fim de cada dia, sabem que suas contribuições ao projeto são integradas e que as peças do componente funcionam juntas. E, se algo não se integrar, isso é rapidamente descoberto.

Vamos considerar alguns dos componentes essenciais do desenvolvimento e da entrega de sistemas complexos e explorar como a CI ajuda a vencer esses desafios.

Arquitetura

Quando você está desenvolvendo um sistema complexo, não pode adicionar recursos continuamente sem um blueprint. Sem um blueprint, tudo o que você obterá com iterações extras é mais oportunidades de retrabalho. Não importa se você se refere a isso como blueprint, modelo ou arquitetura, ele fornece uma base sólida sobre a qual iniciar o processo iterativo.

A arquitetura pode ser útil em projetos menores, com 50 membros da equipe, ou menos, mas quando esse tamanho é excedido, definitivamente é necessário esse trabalho antecipado para entender a divisão em componentes, a reutilização e a variabilidade. Essa análise antecipada permite a divisão em equipes e, ainda, o release de um produto coordenado. O mesmo ocorre quando se tem desenvolvedores de hardware e software trabalhando juntos, como se faz para sistemas complexos com software integrado.

Simulação

Capturando a arquitetura em um modelo de simulação, a equipe pode ver como o sistema responderá a entradas diferentes. Essa forma de teste precoce permite a validação de que o sistema tem o desempenho desejado, cumprindo, portanto, os requisitos. Também permite ao designer visualizar quaisquer consequências não pretendidas do design. Essas consequências não pretendidas são muito difíceis de ver ao examinar o código em texto. Elas tornam-se muito mais óbvias ao visualizar um modelo do sistema, e são ainda mais óbvias ao visualizar esse modelo do sistema em ação.

Assim, a modelagem e a simulação permitem que teste e integração comecem assim que o trabalho de design inicia, eliminando os atrasos que podem ocorrer se o hardware integrado ainda não estiver disponível. Pode, também, economizar um investimento significativo na criação de protótipos antecipada desnecessária de arquiteturas que não são viáveis. Mesmo quando você tem o hardware disponível, a integração contínua requer constantes desenvolvimentos.

Quanto antes for necessário ver os resultados, mais caro será seu ambiente de desenvolvimento. Como o objetivo principal da CI é fornecer resultados o mais rapidamente possível, a simulação permite testar sem custos de hardware extraordinariamente altos. Também fornece uma maneira mais simples de comunicar a funcionalidade de um componente, que pode ser excelente para a programação em par e para a "revisão de código" que é comum em um desenvolvimento agile.

Desenvolver automação

A integração contínua requer automação de desenvolvimento, que é a habilidade de ter o software automaticamente compilado e vinculado a um executável. A velocidade é importante porque grandes compilações podem levar muito tempo. Sem desenvolvimentos rápidos e confiáveis, você carece do insight necessário para resolver os problemas de integração que surgem. Conflitos entre mudanças que tiveram a contribuição de dois ou mais desenvolvedores são identificados para resolução quando o desenvolvimento de integração é executado. Assim, se um problema for encontrado, o desenvolvedor, que trabalha para resolver o conflito do desenvolvimento anterior, pode testar o código revisado através de simulação de hardware sem atrasar os outros desenvolvedores. Mas, para atingir essa eficiência, o desenvolvimento de integração deve ocorrer continuamente, iniciando o novo desenvolvimento assim que o anterior terminar. Isso é muito diferente dos desenvolvimentos de uma vez por dia ou uma vez por semana que os outros processos empregam.

É claro, esse método requer automação do desenvolvimento, porque não seria prático atribuir a uma pessoa a tarefa de iniciar repetidamente um desenvolvimento várias vezes ao longo do dia. Principalmente, o desenvolvimento deve executar rapidamente, o que frequentemente requer que os desenvolvimentos tenham encadeamento múltiplo. Um desenvolvimento com encadeamento múltiplo seleciona diferentes componentes do software e executa-os em paralelo com o desenvolvimento executando em algum outro componente, o que acelera o tempo de desenvolvimento agregado. Requer mais hardware e um script mais complexo. Quanto mais complicado o script se torna, mais valiosa uma ferramenta de gerenciamento de desenvolvimento se torna.

Gerenciamento do trabalho

Um conceito primário agile é o valor de dividir o trabalho em pequenos pedaços gerenciáveis. Essa também é a premissa básica por trás da CI: corrigir os erros cedo e com frequência. Isso impede o acúmulo de problemas maiores e mais difíceis de resolver mais adiante no projeto.

Uma das vantagens que essa técnica fornece é a habilidade de entregar liberações menores e funcionais que são desenvolvidas e testadas em muitas datas ao longo do planejamento do projeto. Cada entrega reduz o risco do projeto, validando a arquitetura, os requisitos e as estimativas de planejamento da equipe. Em métodos agile, o trabalho ainda a ser concluído é chamado de lista não processada.. Conforme você começa a atribuir o trabalho para pequenos incrementos de entrega, chamados sprints, o trabalho alocado a um sprint é chamado de lista não processada do sprint.. O trabalho restante a ser alocado a sprints futuros é chamado de lista não processada do projeto.. A meta é agrupar apenas tantos itens de trabalho em um sprint quantos podem ser realizados no período definido para o sprint.

Esse processo é altamente dependente da coleta de métricas, de modo que uma equipe possa prever com mais precisão a quantidade de tempo que as tarefas exigirão e, assim, o número de tarefas que podem ser na entrega de um sprint. Porém, por mais excelentes que sejam essas métricas, a coleta de dados é muito tediosa mesmo para uma equipe pequena. Conforme você agrupa essas equipes pequenas para produzir um produto mais complexo, a tarefa é bastante pesada para ser realizada manualmente.

Há muitos produtos no mercado que podem ajudar a organizar o trabalho, acompanhar sua conclusão e produzir as métricas associadas a quanto, com que rapidez, quão bem, etc. o trabalho é realizado. Quando as práticas de CI são seguidas, os erros de integração identificados também devem ser adicionados rapidamente a essa lista não processada de trabalho e enviados para o começo da lista como alta prioridade. Nesse sentido, os melhores produtos no mercado oferecem algum nível de integração entre os itens de trabalho e o sistema de gerenciamento, de modo que os erros identificados após cada desenvolvimento possam ser corrigidos rapidamente e integrados aos itens de trabalho existentes, escalados em prioridade e encaminhados para a equipe certa.

Gerenciamento de qualidade

O gerenciamento de qualidade é a prática de ciclo de vida do desenvolvimento de garantir que todos os requisitos para seu produto tenham sido testados. Esse esforço precisa ser organizado e entendido de modo que os testes corretos possam ser atualizados quando os requisitos mudarem. O gerenciamento de qualidade ajuda os gerentes de projeto a responder estas perguntas:

  • Se meu produto precisasse ser liberado na próxima semana, que partes representariam o maior risco?
  • Podemos liberá-lo sem um requisito de nível inferior?
  • Essa será um release de alta qualidade?

Face às pressões de mercado que aceleram os ciclos de entrega, ter repostas rápidas a essas perguntas pode ajudar as empresas a liberar os produtos com confiança no mercado. Os gerentes entendem melhor quais recursos adicionar, onde reduzir recursos do produto e quando reestabelecer datas de entrega para obter a máxima vantagem.

Com desenvolvimento conduzido por teste, o conceito de teste torna-se mais central ao esforço de desenvolvimento. No TDD, você escreve o teste com base no requisito e, então, desenvolve o código até que ele seja aprovado no teste. Isso garante que nenhuma funcionalidade extra seja criada, o que seria algo que as equipes de desenvolvimento chamam de "banhar a ouro". Mesmo que uma função ou recurso adicional pareça uma boa ideia, quando nenhum requisito está conduzindo à decisão, o trabalho extra pode elevar os custos e aumentar o tempo para a entrega. E pode, na verdade, não aumentar a satisfação do cliente com o produto final.

Teste automatizado

Quando você está criando vários desenvolvimentos, a equipe precisa testar novamente as funções determinadas como funcionando em liberações anteriores. Esse processo de testar novamente, antes conhecido como "código válido", é chamado de teste de regressão.. Isso garante que não sejam introduzidos ou reintroduzidos erros no código testado anteriormente por alterações recém-feitas. Com CI, os testes de regressão automatizados têm o script desenvolvido para execução no final de cada desenvolvimento. Isso permite que os desenvolvedores obtenham feedback instantâneo sobre erros encontrados no novo desenvolvimento. Essa é a etapa que alerta os desenvolvedores quando o novo código produzido está (ou não) funcionando como o desejado. Sem os testes de regressão, os desenvolvedores simplesmente sabem que o desenvolvimento está concluído. Como os testes precisam ser criados de qualquer forma, o TDD não adiciona trabalho extra. Ele simplesmente reverte a ordem das coisas criando os testes primeiro, e, então, o código.

Um projeto de desenvolvimento em cascata tradicional pode sobreviver sem qualquer automação de teste. O projeto poderia ser descrito, desenvolvido e, então, testado infinitamente por várias pessoas. Mas assim que você começasse a liberá-lo regularmente, surgiriam problemas com esse processo. Não é viável testar manualmente um sistema que está sendo desenvolvido muitas vezes por dia.

Colaboração

A organização de software IBM ® Rational® há muito tempo defende a colaboração como um componente essencial para o desenvolvimento e a entrega de sucesso do sistema. Mas, em CI, em que estão envolvidas equipes de software e hardware, a colaboração inclui não apenas a entrega de artefatos eficientes de uma equipe para a outra, mas também um entendimento totalmente sincronizado dos prós e contras entre requisitos, recursos e prazos.

Uma boa arquitetura permite esse tipo de colaboração de modo parcial porque as pessoas podem entender melhor as dependências entre os vários componentes que estão desenvolvendo. Com o gerenciamento do portfólio do projeto, é possível entender os recursos, a reutilização e a alocação de recursos. Mas em projetos de hardware e software codesenvolvidos, também é importante gerenciar requisitos e tomar decisões inteligentes sobre quando esses requisitos podem mudar e quando não devem mudar.

Esses projetos normalmente envolvem muitas partes interessadas em vários níveis de tomada de decisão. A boa colaboração ajuda a satisfazer uma porcentagem maior de partes interessadas. Além disso, também garante que o produto certo seja criado e que desvios das metas mais amplas sejam rapidamente identificados. Isso produz um produto que satisfaz melhor a demanda do cliente.


Resumo

De uma perspectiva técnica, a CI ajuda as equipes a trabalharem de maneira mais eficiente. Essas equipes podem ser interfuncionais, criando hardware e software que funcionem juntos. Podem ser geograficamente distribuídas, porque a constante integração de trabalho garantirá que você não tenha designs com desvio. As pessoas podem trabalhar em uma grande equipe, porque os diferentes componentes de um sistema complexo funcionarão juntos com mais certeza. Ela resolve muitas das armadilhas que essas equipes agile não tradicionais poderiam ter experimentado sem CI. Combinar a CI com desenvolvimento conduzido por teste coloca mais pessoas sob o esquema agile, porque permite que métodos agile funcionem com mais eficiência.

De uma perspectiva de negócios, a CI oferece melhores resultados de negócio, permitindo que as equipes provem o próprio trabalho. Ou seja, elas podem levar os produtos mais rapidamente para o mercado, encontrando os problemas quando eles são recentes e pequenos, sem esperar até que estejam grandes e mais difíceis de corrigir. Também pode responder melhor aos requisitos que são apresentados enquanto o produto está em desenvolvimento. Isso cria um produto melhor para o cliente, que é a promessa real de agilidade.

Recursos

Aprender

Obter produtos e tecnologias

  • Faça download de uma versão gratuita do software Rational.
  • Avalie outros produtos de software da IBM da maneira que for melhor para você: faça o download da versão de teste, experimente-a online, use-a em um ambiente de nuvem ou passe algumas horas no SOA Sandbox aprendendo a implementar Arquitetura Orientada a Serviços de forma eficiente.

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Rational
ArticleID=831988
ArticleTitle=Integração Contínua em Desenvolvimento Agile
publish-date=08312012