Integração Contínua em Desenvolvimento Agile

Prévia do material em texto

05/04/2016 Integração Contínua em Desenvolvimento Agile
http://www.ibm.com/developerworks/br/rational/library/continuous­integration­agile­development/ 1/8
Desenvolva e implemente
seu próximo aplicativo na
plataforma de cloud do
IBM Bluemix.
Comece seu
trial gratuito
IBM Bluemix Desenvolva na nuvem em um clique!
Comece seu trial gratuito
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.
Marty 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 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,
developerWorks Brasil Itens Técnicos Rational Biblioteca técnica
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
05/04/2016 Integração Contínua em Desenvolvimento Agile
http://www.ibm.com/developerworks/br/rational/library/continuous­integration­agile­development/ 2/8
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
05/04/2016 Integração Contínua em Desenvolvimento Agile
http://www.ibm.com/developerworks/br/rational/library/continuous­integration­agile­development/ 3/8
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 significativona 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
05/04/2016 Integração Contínua em Desenvolvimento Agile
http://www.ibm.com/developerworks/br/rational/library/continuous­integration­agile­development/ 4/8
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
05/04/2016 Integração Contínua em Desenvolvimento Agile
http://www.ibm.com/developerworks/br/rational/library/continuous­integration­agile­development/ 5/8
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
planejamentoda 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?
05/04/2016 Integração Contínua em Desenvolvimento Agile
http://www.ibm.com/developerworks/br/rational/library/continuous­integration­agile­development/ 6/8
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
05/04/2016 Integração Contínua em Desenvolvimento Agile
http://www.ibm.com/developerworks/br/rational/library/continuous­integration­agile­development/ 7/8
Recursos
Aprender
Escute o podcast Continuous integration comes of age.. Para localizar esse
podcast, procure por #204.
Acompanhe o webcast gravado Continuous integration for agile embedded
software development.
Para obter mais informações sobre gerenciamento de qualidade:
Leia o artigo de Moshe Cohen, Smarter quality management: The fast track
to competitive advantage (White Paper IBM Software Thought Leadership,
junho de 2011, download de PDF).
Explore as páginas da web IBM Quality Management and Testing .
Para saber mais sobre integração contínua, consulte a seção Practices of
Continuous Integration do website de Martin Fowler.
Visite a área do software área do software Rational no developerWorks para
obter recursos técnicos e boas práticas para os produtos do Rational
Software Delivery Platform.
Assine a newsletter semanal de email do developerWorks e escolha os
tópicos para seguir.
Fique por dentro dos eventos técnicos e Webcasts do developerWorks com
foco em uma variedade de produtos da IBM e tópicos do segmento de
mercado de TI.
Participe de um briefing ao vivo e gratuito do developerWorks para se
atualizar rapidamente sobre produtos e ferramentas IBM, bem como
tendências do segmento de mercado de TI.
Acompanhe as demos on demand do developerWorks, variando de demos de
instalação e configuração de produtos para iniciantes a funcionalidades
avançadas para desenvolvedores experientes.
Obter produtos e tecnologias
Programa Global de
Empreendedorismo da IBM
Faça parte do programa que busca
por empreendedores que ajudam a
modificar a maneira como o
mundo funciona.
Demos IBM BluemixConfira a série de demos sobre a
plataforma PaaS da IBM, conteúdo
100% em português
Cursos EAD
Capacite­se nas tecnologias IBM
sem custo
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.
05/04/2016 Integração Contínua em Desenvolvimento Agile
http://www.ibm.com/developerworks/br/rational/library/continuous­integration­agile­development/ 8/8
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
Faça parte da fóruns do software Rational para fazer perguntas e participar
de discussões.
Faça e responda a perguntas, e aumente seu conhecimento participando dos
Fóruns do Rational, cafés e de wikis.
Faça parte dos comunidade Rational para compartilhar seu conhecimento em
software Rational e ficar conectado a seus colegas.
Classifique ou revise o software Rational. É rápido e fácil.