PRÁTICAS ÁGEIS INTEGRAÇÃO CONTÍNUA

O texto abaixo é a uma tradução autorizada do artigo escrito pelo Martin Fowler. Para acessar a versão original em inglês, clique aqui . Caso você tenha sujestões para tornar a tradução melhor, compartilhe através da seção de comentários no final da página. The text bellow is an authorized translation of the article written by Martin Fowler. To access the original english version, click here . If you have any sujestion to make the translation better, share it via comments section at the end of the page.

Construindo um componente usando Integração Continua
Para mim, a forma mais fácil de explicar o que Integração Contínua (IC) é e como trabalha é mostrando um pequeno exemplo de como isso funciona com o desenvolvimento de uma pequena parte do sistema. Vamos assumir que eu tenho que fazer alguma coisa para uma parte do sistema, não importa realmente que tarefa é - por enquanto vou supor que isso é pequeno e que pode ser feito um poucas horas ( vamos explorar tarefas maiores e outros problemas mais tarde ). Começo pegando uma cópia atual do código fonte e colocando na minha máquina de desenvolvimento. Faço isso utilizando um sistema de controle de código para ter uma cópia de trabalho a partir do código principal. O parágrafo acima irá fazer sentido para pessoas que usam sistema de controle d código, mas não será e para aqueles que não usam. Então deixe-me explicar rapidamente: um sistema de controle de código mantém todo o código fonte de um projeto em um repositório. O estado atual do sistema geralmente é chamado de mainline( ou linha principal). Em qualquer momento um desenvolvedor pode fazer uma cópia da versão principal em sua máquina, e isso é chamado de check out. A cópia em uma máquina de um desenvolvedor é chamada de cópia de trabalho (na maior parte de tempo você estará atualizando sua cópia de trabalho junto a principal). Agora eu pego minha cópia de trabalho e faço o que preciso para completar minha tarefa. Isso irá consistir em alterar o código de produção e também adicionar ou alterar os testes automatizados. Integração Contínua assume um alto nível de testes que são automatizados no software: uma facilidade que eu chamo de self-testing code ( ou código auto-testável). Frequentemente estes usam uma versão da popular framework de teste xUnit. Um vez que eu terminei (e isso geralmente acontece em vários lugares quando eu estou trabalhando), eu faço uma build (ou desenvolvimento de uma versão) automatizada na minha máquina de desenvolvimento. Assim, o código fonte em minha cópia de trabalho é pego, compilado e transformado em um executável - e então é executado os testes automáticos. Somente se todas as builds e testes não tiverem erros que tudo será considerado bom. Com uma boa build, eu posso então pensar em colocar minhas alterações no repositório. A questão é, claro, que outras pessoas podem fazer (e geralmente fazem) mudanças na versão principal antes de eu ter a chance de fazer um commit ( ou atualizar o repositório principal com a minha versão do código). Sendo assim, primeiro eu atualizo minha cópia de trabalho com as mudanças feitas pelos outros e crio uma nova build. Se as mudanças deles chocarem com as minhas mudanças, será exibido erros tanto na compilação quanto nos testes. Neste caso é minha a responsabilidade de corrigir estes erros e repetir o processo até que minha cópia local esteja sincronizada com a versão principal. Uma vez que tenho as alterações na minha própria build de uma cópia devidamente sincronizada eu posso finalmente fazer o commit na versão principal, que atualiza o repositório. Entretanto meu commit não termina meu trabalho. Nós fazemos uma build novamente, mas agora em uma maquina de integração baseada na versão principal do código. Somente com o sucesso desta build poderemos dizer que as minhas alterações foram feitas. Sempre existe uma chance de eu ter esquecido alguma coisa na minha máquina e o

grandes e complicadas de instalar . Custo não é um problema por causa da boa qualidade das ferramentas open-source disponíveis. De qualquer modo o erro é detectado rapidamente. tenha certeza de usar um sistema decente de controle de código fonte. mas o Subversion é uma escolha moderna). particularmente quando existem várias pessoas envolvidas. mas tudo que você precisa para fazer uma build deve estar incluído la: scripts de teste.repositório não ser atualizado corretamente. É interessante como eu converso com desenvolvedores e descubro que a maioria dos gerenciadores de código fonte comerciais são menos aceitos que o Subversion. ambiente de desenvolvimento Java ou sistema básico de banco de dados são exemplos típicos. . A build de integração pode ser executada manualmente por mim ou ser feita automaticamente usando o Cruise. Caso não. esquema de banco de dados. mas devem ser consertadas rapidamente. Em um ambiente de Integração Contínua você nunca deve ter uma build de integração com falhas por muito tempo. sistema de controle de versão. Más builds podem ocorrer de tempos em tempos. como um passo fundamental. e fazer sua build voltar a funcionar corretamente. Um bom time deve ter muitas builds corretas por dia. Isto é raro. A única ferramenta que eu tenho ouvido pessoas falarem que é digna de ser paga é o Perforce. Uma vez que você tenha um sistema de gerenciamento de código fonte. Eu vou focar agora em práticas chaves que efetivarão a IC . um erro comum que vejo é que eles não colocam tudo no repositório. Estas ferramentas . Embora muitos times usem repositórios. para pagarem o código fonte. Portanto. a build de integração deve falhar. Eu conheci projetos que colocavam seus compiladores no repositório (importante nos dias antigos de vários compiladores de C++). Logo não é surpresa que através de anos equipes de desenvolvimento tem construído ferramentas para gerenciar tudo isso. tenha certeza de que isso esteja em um lugar conhecido por todos. gerenciamento de configuração. isso geralmente é pego quando o segundo desenvolvedor atualizar sua cópia local com as builds feitas pelos outros. Um sistema operacional. e ainda é bem melhor que nada. Manter todos esse arquivos exige um grande esforço. A triste e surpreendente questão é que essas ferramentas não fazem parte de todos os projetos. Somente quando minha build de alterações for lançada com sucesso na máquina de integração é que o meu trabalho terminou. Práticas da Integração Contínua A história anterior é uma apresentação da Integração Contínua e de como ela funciona diariamente. repositórios ou outros nomes são uma parte integrante na maioria dos projetos de desenvolvimento. Projetos de softwares envolvem vários arquivos que precisam serem "orquestrados" juntos para se construir um produto. mas eu participo de projetos que não usam algo como um sistema mas usam um combinação confusa de drivers locais e compartilhados.chamadas de ferramentas de gerenciamento de código fonte. Se um choque ocorrer entre as versões de dois desenvolvedores. fazer um checkout (ou pegar uma cópia de todo o código) e conseguir rodar o sistema completamente. Se as pessoas usam um repositório. scripts de instalação e bibliotecas de terceiros. arquivos de configuração. Ninguém deve sequer perguntar "Onde estão os arquivos?". eles vão por o código lá. Somente poucas coisas devem ser feitas na máquina virgem . Nesse momento a tarefa mais importante é consertar os problemas. O repositório open-source atual que escolho é o Subversion ( o antigo CVS continua sendo usado largamente. O regra básica é que você consiga por o projeto em uma máquina virgem. Tudo deve estar no repositório. Manter um único repositório de código.geralmente coisas que são estáveis. Colocar isso tudo pra funcionar sem problemas envolve obviamente mais coisas do que foi dito.

movimentação de arquivos. Nós tivemos bons resultados automatizando um projeto anterior usando Microsoft COM com o Ant. a comunidade Java desenvolveu o Ant. mas nada do que você já executou. Pedir pessoas para digitarem comandos estranhos ou clicar em caixas de dialogo é uma perda de tempo e uma forma suscetível a reprodução de erros. Tenha uma versão principal: um único branch do projeto atualmente em desenvolvimento. Entretanto esses arquivos são sempre proprietário a IDE e frequentemente frágeis. emitir um único comando e ter um sistema rodando na sua máquina. para manipular diferentes fluxos de desenvolvimento. Alguns componentes podem ser construídos isoladamente. mas eu considero que isso é um sinal. geralmente uma incapacidade para recriar as builds confiantemente. Isso é uma característica útil. mas eles não necessariamente ter que ser assim. Logo. Geralmente você deve guardar no controle de código tudo que você precisa para executar tudo. Basicamente todos de vem trabalhar fora desta linha principal a maior parte do tempo ( um número considerável de branches são correção de bugs de uma versão futura e experimentos temporários). entretanto você pode por também outros materiais com que as pessoas geralmente trabalham. Esteja certo de que você pode gerar e lançar o seu sistema rodando os scripts em um único comando. Dependendo do que você precisa. em um projeto Java nós estamos livres para ter desenvolvedores fazendo a build em seus IDEs. alguns tem usando Ruby ( o sistema Ruby Rake é um script build muito bom). Você lançar um sistema com ou sem código de teste. Ambientes automatizados de builds são características comuns de sistemas. ou com diferentes conjuntos de testes.NET desenvolveu o Nant e agora tem o MSBuild. Entretanto é essencial ter uma build principal que é usável em um servidor e executável a partir de outros scripts.e portanto deve ser automatizada. carregar schemas nas bases de dados e por ai vai.Você precisa por tudo que a build precisa no sistema de controle de código. Configurações de IDE são boas para colocar lá porque este é um modo fácil para as pessoas compartilharem as mesmas configurações. Além s disso eles necessitam da IDE para funcionar. O mundo Unix tem feito isso há décadas. Muitos de nós usamos IDEs. pegar as fontes do repositório. boa parte das tarefas nesta parte do desenvolvimento de software pode ser automatizada . uma indicação de um problema mais profundo. A build deve incluir pegar o schema do banco de dados do repositório e colocá-lo no ambiente de execução. Entretanto. Reserve-se a usar os branches ao mínimo. e a maioria das IDEs tem algum tipo de processo de gerenciamento de build dentro delas. Algumas pessoas guardam os produtos das builds no controle de código. Outra característica dos sistemas de controle de versão é que eles permitem você criar múltiplos branches (ou linhas de desenvolvimento) . Não existe problema se os usuários da IDE configurarem seus próprios arquivos de projetos e usarem para o desenvolvimento individual. você pode querer que diferentes tipos de coisas estejam na build. Faça sua Build ser auto-testável Tradicionalmente uma build significa compilação. Embora a maioria dos nossos projetos são em Java e usam o Ant. Um script de build deve permitir você usar métodos alternativos em casos diferentes. Scripts de build podem ter varias formas e frequentemente são particulares a uma plataforma ou comunidade. Eu vou elaborar minha regra anterior: qualquer um deve ser capaz de ir para uma máquina virgem. Um erro comum é não colocar tudo na build automatizada. linkagem e todo o material adicional necessário para ter . mas a build principal deve usar o Ant para assegurar que isso possa rodar um servidor de desenvolvimento.mas frequentemente é usada de maneira abusiva o que coloca as pessoas em problemas. Automatize a Build Frequentemente pegar os fontes e transformá-los em um sistema rodando é um processo complicado envolvendo compilação. quer dizer essencial . a comunidade .

. Isto é uma coisa boa. Testes não são perfeitos (claro). Para uma build ser auto-testável a falha de um teste deve fazer com que a build falhe. O único pré-requisito para um desenvolvedor lançar suas alterações na versão principal é que ele ele consiga executar perfeitamente o código. desde que muita coisa não tenha sido mudada. As ferramentas xUnit tem sido muito valorosa para nós na ThoughtWorks e eu sempre sugiro as pessoas que as usem. Desde que a build seja autotestável. Desde que existam apenas algumas horas de diferença entre os commits. mas isso não significa que foi feito da maneira certa. mas alguma coisa pode acabar passando desapercebida. para então fazer os testes passarem . Watir. Além disso. Um programa pode rodar. tornam fácil para você configurar um ambiente completo para testes automatizados. Isso claro. Integração permite os desenvolvedores dizerem uns aos outros sobre as alterações que eles fizeram. Como com qualquer ciclo de lançamento de código. Frequentemente comunicação permite pessoas descobrirem rapidamente como as alterações aconteceram. FITnesse e muitas outras que eu não vou listar aqui. Com desenvolvedores lançando suas alterações a cada hora. existem apenas alguns locais onde o problema pode estar se escondendo. que teve Kent Beck como pioneiro. Fazendo isso frequentemente. Sahi. então ele estará liberado para lançar suas alterações na versão principal. Conflitos que não são detectados por semanas podem ser difíceis de serem resolvidos. Para ter o código auto-testável você necessitará de uma suite de testes automatizados que possa checar uma grande parte da base do código para achar problemas. Ambas as abordagens acertam que se escreva testes antes que você escreva o código. mas eles podem pegar muitos bugs . Os testes necessitam estar aptos para rodarem com um simples comando e serem checados automaticamente. Através dos últimos anos em que o TDD tem crescido. Integração antes de tudo trata sobre comunicação. os desenvolvedores irão encontrar rapidamente se existe algum conflito entre as versões. Selenium. você também detecta conflitos no código em execução. onde nós temos requisitos mais fracos de código auto-testável (embora TDD é minha maneira preferida de produzir código auto-testável). Se a build passar. mas não é necessariamente do propósito da IC.o que o torna fácil de ser solucionado. Estas ferramentas. Atualmente. e em um ponto não muito avançado . resolve qualquer conflito e então gera a build em sua máquina local. inclui passar pelos testes da build.o suficiente para ser útil. Leitores regulares do meu trabalho irão notar que sou um grande fã de TDD e XP. Ferramentas xUnit são certamente o ponto inicial para tornar seu código auto-testável. entretanto eu quero ressaltar que nenhuma dessas abordagens são necessárias para ganhar os benefícios de um código autotestável. O fato de que você gerou uma build quando você atualizou sua cópia de trabalho significa que você detectou os problemas de compilação como também conflitos textuais. um conflito pode ser detectado dentro de poucas horas desde seu acontecimento. Cada um lança suas modificações todos os dias. ele popularizou a família de ferramentas open source xUnit que são ideais para esse tipo de teste. O resultado da suite dos testes em execução deve indicar se estes falharam.desta forma os testes exploram muito mais o design do sistema do que capturam erros. você pode usar um diff-debugging para lhe ajudar a encontrar o problema. Linguagens modernas estaticamente tipadas podem achar muitos bugs. Os últimos conflitos são conflitos particularmente incômodos de se encontrar se eles persistirem não detectados por um longo tempo em seu código.um programa executando. Um bom modo para pegar erros mais rápida e eficientemente é incluir testes automáticos no processo de build. o desenvolvedor primeiro atualiza sua cópia de trabalho para coincidir com a versão principal. O segredo para solucionar problemas rapidamente é encontrá-los rapidamente. incluindo FIT. existem um grande número delas. Você deve também procurar por outras ferramentas que focam em testes mais voltados ao software em funcionamento.

Não é uma coisa ruim a build do repositório principal falhar. e notifica para quem fez o commit o resultado da build. menos lugares você terá que procurar por erros de conflito. ele precisa monitorar o repositório principal para que possa corrigir qualquer problema que possa ocorrer. nós somos grandes fãs de servidores de integração contínua . Quem fez a build não a considera terminada enquanto ele não recebe uma notificação . .NET. Outra é que existem diferenças de ambiente entre as máquina dos desenvolvedores. Nem todos preferem usar um servidor de IC.geralmente por e-mail. Quando a build do repositório principal quebrar.na verdade nós gerenciamos o desenvolvimento original do CruiseControl e do CruiseControl. e se a build for feita com sucesso ele finaliza seu commit (veja também a descrição de Jim Shore's). Existem duas formas principais que eu vejo para assegurarmos que isso ocorra: usando um processo manual de build ou um servidor de integração contínua. Uma vez que eles ficam muito tempo no sistema. e temos sido muito felizes com os resultados. Cada commit deve atualizar o repositório principal em uma máquina de integração Usando commits diariamente. O ponto principal da IC é ajudar a encontrar os problemas o mais rápido possível. embora se isso acontecer o tempo todo é sinal que as pessoas não estão sendo cuidadosas o suficiente em atualizar e realizar a build localmente antes de realizarem o commit. um servidor open-source de IC largamente usado. Um servidor de integração contínua age como um monitor para o repositório. Desde então nós também construímos o servidor de IC comercial chamado Cruise. coisas continuam dando errado. Na prática. O desenvolvedor vai para a máquina de integração. entretanto. Nós usamos um servidor de IC quase que com todos os projetos que nós fazemos. tipo toda noite. Isso ajuda a dividir o progresso e causa um senso de progresso. eles demoram um longo tempo para serem encontrados e removidos. um time tem builds frequentemente testadas. Quanto mais frequentemente você fizer um commit. Descrever a abordagem da build manual é simples. Isso deveria significar que o repositório principal esta em um estado saudável. A idéia central de se estar trabalhando com a IC é que você sempre desenvolve em uma base conhecida e estável. Builds noturnas significam que os erros ficam desapercebidos durante um dia inteiro antes que qualquer um os descubram. Toda vez que um commit é feito no repositório o servidor automaticamente checa as fontes na máquina de integração. Na ThoughWorks. A consequência desta responsabilidade é que ele não deve ir para casa até que a build do repositório principal tenha passado por qualquer commit ele tenha realizado durante o dia. O ponto chave de se ficar fazendo a build de integração é que se a build do repositório principal falhar.Muitas organizações fazem builds regulares em um tempo marcado. Um razão é a disciplina: pessoas não estão atualizando suas versões e fazendo uma build antes de fazerem seus commits.Minha regra geral é que cada desenvolvedor deve atualizar o repositório todo dia. Jim Shore deu uma boa descrição do porquê ele prefere uma abordagem manual. geralmente é útil os desenvolvedores lançarem suas atualizações com mais frequência que uma vez ao dia. checa a versão do repositório principal ( que é o último commit feito da casa) e faz a build de integração. Na prática. Isso não é a mesma coisa como uma build contínua e não é o suficiente para a IC. mas nós temos encontrado que esta teoria e prática ajudam os desenvolvedores a aprender. e mais rapidamente você os consertará. Frequentemente as pessoas começam sentir que não conseguem fazer alguma coisa significativa em poucas horas. Commits frequentes encorajam os desenvolvedores a quebrar seus trabalhos em pequenos pedaços de poucas horas cada. Eu concordo com ele que IC é muito mais que somente a instalação de qualquer software. Como uma possível solução você deve assegurar que as builds ocorram em uma máquina de integração e somente se a build de integração passar com sucesso é que o commit deve ser considerado feito. ela será corrigida no jeito certo. inicia a build. Levando em consideração que o desenvolvedor que realiza o commit deve ser responsável pelo mesmo. Todas as práticas citadas aqui são feitas efetivamente na IC. Mas igualmente muitos times que fazem IC acharão bom um servidor de IC para ser uma ferramenta útil. Essencialmente ela é similar a build local que um desenvolvedor faz antes de lançar suas alterações no repositório. Ele verifica todo este processo.

frequentemente esta é uma das coisas mais difíceis para se resolver. as builds secundárias são frequentemente testes puros. Quanto as equipes que são iniciantes na IC. não serão encontrados. Neste cenário as pessoas usam o primeiro estágio com a commit build e a usam para os seus ciclos principais da IC. Nada é mais prejudicial as atividades da IC que uma build que toma muito tempo. Máquinas adicionais podem rodar novas rotinas de testes na build que precisa de mais tempo. Isto é digno de se concentrar esforços para fazer com que aconteça. O segundo estágio roda em uma suite diferente de testes que acessam a base de dados real e envolve um comportamento de ponta-a-ponta. dentro da linha de 10 minutos. A idéia por trás de uma staged build é que existe de fato multiplos builds feitas em sequência. A maior parte dos meus colegas consideram que uma build de uma hora é totalmente sem sentido. desde que estes testes causem lentidão. Na verdade a build secundária não tem que ser sempre boa. ao menos. particularmente se ela estiver trabalhando sobre uma base existente de código. tão logo os problemas sejam identificados e tratados em poucos dias. Entretanto qualquer problema que envolva uma escala maior de interações. Entretanto existem testes novos e lentos que você pode começar a fazer. Para aplicações empresariais. Eu me lembro de equipes sonhando que poderiam fazer isso tudo muito rápido e que ocasionalmente eles continuam rodando certos casos onde é muito difícil ter builds nesta velocidade. portanto não desista. Se você estiver começando com uma build de uma hora. O segundo estágio é formado por uma build secundária que roda quando possível. Para ajudar a evitar o quebramento do repositório principal.entretanto. Para a maior parte dos projetos. Como neste exemplo. enquanto mantem funcionando a build de commit. começar a fazer a build cada vez mais rápido pode parecer intimidante. O commit no repositório principal aciona a primeira build. nos temos visto que o principal gargalo é testar . pegando os executáveis da ultima build válida para novos testes. com razão. entretanto. ela economiza muito tempo. então isto não terá o mesmo "pare tudo". mas o time precisa ter o objetivo de corrigir os problemas tão rápido quando possível. é importante que seja corrigida rapidamente. . Uma vez que a commit build é boa. ou também build encadeada). Provavelmente o ponto mais importante é começar trabalhando na configuração de uma staged build (ou build por estágios. Um exemplo simples disto é uma build de dois estágios. Isso pode até mesmo ser assustador começar a trabalhar em um projeto novo e pensar em manter as coisas rápidas. A commit build é a que tem que ser feita rapidamente. particularmente aqueles envolvendo a base de dados real. a linha de build do XP de 10 minutos é. A maioria dos nossos projetos modernos conseguem atingir isso. O truque é balancear a necessidade de procurar bugs e a velocidade para que haja uma commit build estável o suficiente para que outras pessoas possam trabalhar. Paciência e constância geralmente são boas dicas. Uma equipe deve lutar para o quanto antes conseguir ter o hábito de trabalhar em builds da versão principal. Neste ponto eu tenho que admitir que existia um pouco de velho cara que considerava que uma build tinha que ser longa. que eu chamo de commit build. O primeiro estágio deve realizar a compilação e rodar os testes que são mais focados nos testes unitários com a base de dados vazia. Essa suite pode tomar algumas horas para rodar. então outras pessoas podem trabalhar no código com confiança. Uma vez que a IC demanda commits frequentes. A commit build é a build que necessitou ser executada quando alguém atualizou o repositório principal. Tais testes podem rodar muito rápido. como consequência esta tomará alguns atalhos que diminuirão a capacidade de se achar bugs. porque a cada minuto que você reduz o tempo da build é um minuto salvo para cada desenvolvedor a cada momento que ele realiza um commit.particularmente testes que envolvam serviços externos como uma base de dados. você pode considerar usar uma pending head. Mantenha a Build rápida O foco da IC é prover um feedback rápido. Se a build secundária falhar. perfeita.

mas o principio básico pode ser extendido para qualquer número de builds posteriores a principal. dentro possível. Use o mesmo endereço IP e portas. isso é um sinal que a commit build poderia fazer outro teste. Torne fácil para qualquer um ter o último executável. você necessitará fazer testes duplos. Este exemplo é de uma build de dois estágios. você pode adicionar testes apropriados para a commit build. esta opção faz cada vez mais sentido. Assegure-se o tanto quanto possível que qualquer falha na build secundária te leve a novos testes na commit build onde você deve pegar o problema. dentro de condições controladas. Máquinas virtuais podem ser salvas com todos os elementos necessários juntos na virtualização. Felizmente. Um parte significante disto é que o ambiente onde eles irão rodar deve ser como o de produção. entretanto. Eu tive notícias em um crescente interesse em usar virtualização para tornar fácil juntar ambientes de testes. Bom. ou simular várias máquinas em uma rede com uma única máquina.Se a build secundária detectar um problema.e estou esperançoso para incentivar alguns dos desenvolvedores a escreve-las). Frequentemente. Da mesma forma. Apesar destes limites. para que os problemas fiquem corrigidos na commit build. rodando no mesmo hardware. então se você tem duas horas de testes secundários você pode melhorar o tempo e resposta do processo tendo duas máquinas que rodam metade dos testes cada. use a mesma versão do sistema operacional. é comum ter um ambiente muito artificial para os tests de commit. porque os sistemas responderão lenta ou intermitentemente. na maior parte do tempo. dentro do processo regular de build (eu tenho rodado muitas técnicas interessantes como essa assim que visitei muitos projetos da ThoughtWorks nos últimos anos . seu objetivo deve continuar sendo duplicar o ambiente de produção tanto quanto possível e entender que os riscos que você estará aceitando por cada diferença entre os ambientes de teste e produção. Uma das partes mais difíceis de desenvolvimento de software é ter certeza de que você esta construindo o . Além disso. isto permite a você rodar multiplos testes em uma máquina. Existem casos onde não existem como construir um teste que rode rápido e que exponha o erro. Teste em uma cópia do ambiente de produção O ponto central dos testes é trazer a tona. Desta forma os testes de commit são reforçados sempre que alguma coisa passar por eles. para ser uma cópia exata do seu ambiente de produção. incluindo teste de performance. toda diferença resultará no risco das situações sob teste não acontecerem em produção. Como um resultado. Uma solução para isso é que você configure seu ambiente de teste. Bote todas as bibliotecas que estão no ambiente de produção para o ambiente de teste. alguns ambientes de produção podem ser caras demais para serem duplicadas (embora eu tenho encontrado frequentemente falsas economias não duplicando ambientes nem tão caros assim). mesmo que o sistema atualmente não as use. É relativamente simples instalar a última build e rodar os testes. na verdade existem limites. então você pode decidir somente testar aquela condição na build secundária. As builds posteriores a commit build pode também serem feitas em paralelo. Como o ônus da performance tem diminuido. sem ter que fazer muitas comunicações incomodas. você pode rodar sua commit build em um ambiente copiado. qualquer p roblema que o sistema vai ter em produção. e usar uma cópia da produção para os testes secundários. Use o mesmo software de banco de dados. Se você testar em um ambiente diferente. Se você tem uma configuração boa e simples. Us ando builds secundárias paralelas desta forma você pode introduzir todos tipo de novos testes automáticos. com as mesmas versões. Se você esta escrevendo um software desktop não é prático testar em uma cópia em todos os desktops possíveis com todas as partes terceirizadas do software que as diferentes pessoas estão rodando.

permitindo membros da equipe ter uma boa informação das recentes atividades no projeto. Demostrações. Cada time faz suas próprias escolhas sobre esses sensores da build . Se você estiver usando o Cruise existe uma ferramenta embutida no site dele que irá mostrar a você se existe uma build em progresso e o qual foi o estado da última build da versão principal. testes exploratórios ou simplesmente ver o que mudou esta semana. Cruise também provê um histórico de mudanças. em particular. Pessoas acham mais fácil ver algo que não é bom o bastante e dizer como isto precisa ser alterado. mas geralmente existem pessoas longes onde seja bom que tenham idéia de como as coisas estão. Frequentemente você tem algo para ser posto na mesa de qualquer um que esteja fazendo atualmente a build (novamente alguma coisa boba como uma galinha de borracha é uma boa opção). Muitos times gostam de fazer esta informação chamar mais a atenção colocando um display mostrando o sistema de build . Outra vantagem de usar um site é para aqueles que não estão próximos fisicamente poderem ter uma idéia do status do projeto.com as populares luzes verde (quando a build funciona) e vermelha (quando ela falha). Se você estiver usando um processo de IC manual.é bom ser informal com sua escolha (recentemente eu vi alguém experimentando por um coelho dançando). As páginas dos servidores de IC pode trazer mais informações que estas. Se você estiver seguindo um processo com iterações bem definidas. Tudo sobre Integração Contínua esta relacionado a comunicação. então geralmente vale a pena por a última versão para alguma coisa necessária para quem estiver mostrando o software Todos pode ver o que esta acontecendo. mas quais mudanças ele fez.não somente para indicar o estado da build mas também para indicar por quanto tempo tem permanecido cada estado. Os processos de desenvolvimento ágeis incentiva explicitamente e tomam vantagem desta parte do comportamento humano. Para a versão mais recente você deve por o último executável que passou nos testes de commit . Eu conheço equipes que gostam de usar isto para ter um senso do que as pessoas tem feito e manter uma idéia das mudanças feitas no sistema. Cruise oferece um indicador não somente de quem esta fazendo a build. O monitor da máquina de build pode mostrar o status da build da versão principal. Um dos meus a painéis favoritos foi de um projeto que estava começando na IC. Um jeito particular é por algo como as lampadas de lava verde e vermelha . a visibilidade deste continua sendo essencial. como um som de um sino. claro. Pode ser útil pôr muitos executáveis em um lugar comum. Para ajudar a fazer este trabalho. Bolhas em uma lâmpada vermelha indica que a build tem quebrado por muito tempo.gerando um status simples e automático dos diferentes projetos.software certo. Um bom painel de informações não são somente aqueles em uma tela de comput dor. Nós temos visto que é muito difícil especificar adiantadamente o que você quer e estar correto. qualquer um envolvido com um projeto de software deve ser hábil para ter a última versão executável e ser capaz de roda-la: para demonstrações. Ele tinha uma história longa de problemas . geralmente é sábio por também junto o resultado final das builds da iteração.como um executável. O site também é útil para as equipes para manter junto informações de builds de vários projetos . ele deve ser estável. Normalmente eu prefiro ter todos que estão trabalhando ativamente no projeto juntos. precisam do software cuja as características são familiares. então você precisa ter certeza que todos possam facilmente ver o estado do sistema e as mudanças que tem sido feitas nele. Uma das coisas mais importantes para se comunicar é o estado da build da versão principal. Faça isto ser bem simples: tenha certeza que existe um bom lugar conhecido onde as pessoas possam pegar o último executável. Geralmente as pessoas gostam de fazer um som simples avisando boas builds.

e o pior é que é muito difícil saber o quão longe você terá que ir neste processo. E isto é também uma opção barata desde que você use somente as mesmas configurações que você usa nos deploys dos ambientes de teste . Uma consequência natural disto é que você deve ter scripts que permitam você implantar o software dentro do ambiente de produção tão facilmente quanto nos outros ambientes. substituindo gradualmente a aplicação durante o curso de poucas horas. Todo dia o grupo de controle de qualidade (QA) colocaria um adesivo verde quando recebia uma build estável que passou nos testes. La as pessoas estavam no final (ao menos acreditavam) de um longo projeto. Se você implantar alguma função extra no ambiente de produção você deve checar se isto terá um rollback (ou reverter) automático. Benefícios da Integração Contínua Olhando isso tudo eu penso que o maior e mais abrangente benefício da Integração Contínua é a redução de riscos. você tem também que assegurar que os dados migraram corretamente. Implantação automatizada aliada a uma boa disciplina de IC é essencial para fazer isso funcionar. Um empecilho para muitas pessoas que fazem releases frequentes é a migração de banco de dados. O time então vê como essa versão limitada é usada antes de decidir se implantada o sistema para todos os usuários. Coisas ruins podem acontecer de tempos em tempos. O artigo é uma tentativa rápida de captar a informação descrita em maiores detalhes pelo livro do Pramod e Scott Amblers sobre refatoração de banco de dados. você vai querer fazer isso automaticamente.com seu propósito cumprido. Isto permite você testar novas funcionalidades de interfaces com o usuário antes de prosseguir para uma versão final. encorajando as pessoas a realizarem deploy ( entrega e implantação de uma versão) com mais frequência e assim ter novas funcionalidades para entregarem para os usuários rapidamente. Mudanças na base de dados são dolorosas porque você não pode simplesmente mudar os schemas do banco de dados. O resultado é que você esta . Você pode não implantar o software no ambiente de produção todos os dias (embora em tenho rodado projetos em que isso aconteça). Uma variação particular e interessante disto que eu tenho visto surgir com a aplicação web pública é a idéia de implantar uma versão limitada para um grupo menor de usuários. um para rodar os testes de commit (ou commit build). Então é importante ter scripts que permitam você implantar a aplicação dentro de qualquer ambiente facilmente. O problema com aquela forma de integração narrada é que é muito difícil saber o quão longa ela será. mas implantações automáticas ajudam tanto a tornar o processo mais rápido quanto a reduzir erros.em fazer builds estáveis. Uma vez que você esteja movendo os executáveis entre estes ambientes várias vezes por dia. um ou mais para rodar os testes secundários. e se algo não der certo é bom ser capaz de desfazer rapidamente tudo para a última versão boa conhecida. Com o passar do tempo o calendário revelou que o estado do processo de build mostrava um cre scimento estável até que os quadrados verdes eram tão comuns que o calendário desapareceu . Veja o artigo relacionado Evolutionary Database Design. Em ambientes em cluster nós temos visto processos de implantação acontecerem onde um novo software é implantando em um nó por vez. ou. colocaria um adesivo vermelho. sem ainda uma idéia real de quão longo isto deveria ser antes de terem terminado. Ser capaz de reverter automaticamente também reduz muita tensão durante a implantação. ( A comunidade Ruby on Rails desenvolveu uma ferramenta chamada Capistrano que é um bom exemplo de uma ferramenta que faz esse tipo de coisa). Automatize a Implantação do Sistema Para fazer a Integração Contínua você precisará de multiplos ambientes. Este artigo descreve técnicas usadas por meu colega Pramod Sadalage para fazer a refatoração automática e a migração dos bancos de dados. Nós colocamos um calendário na parede que mostrava um ano inteiro com um pequeno quadrado para cada dia. Minha mente continua flutuando de volta para aquele projeto de software anterior que eu mencionei no meu primeiro paragrafo.

pondo completamente a si mesmo em um ponto cego justamente em uma das partes mais tensas do projeto . Quanto mais bugs você tiver.pessoas tem menos energia para encontrar e eliminar os bugs quando existem vários deles um fenômeno que os programadores pragmaticos chamam de síndrome da Janela Quebrada. Integração Contínua não nos livra dos bugs. Ter todo que você precisa dentro do seu controle de código para que você possa então ter todo o sistema com um único comando. O grande responsável por este aspecto é o código auto-testável. tornando difícil ter o resto do software funcionando corretamente. projetos com IC tendem a ter dramaticamente menos bugs. Você deve entender que não tão difícil construir uma suite de teste que faça uma diferença notável. entretanto. leva um tempo antes que o time consiga chegar ao mesmo nível dos bugs que eles tem que procurar. mais difíceis são se serem removidos. Se você trabalha com IC. você não tem que olhar muita coisa. Enquanto ainda não tem um Integração Contínua. Bugs no trabalho em progresso entram em seu caminho. Não existe uma integração longa.mas você não precisa começar com tudo isso. você elimina completamente o ponto cego. em um projeto existente . Bugs . O bugs também são cumulativos. Não existe uma aqui receita fixa . Introduza alguns testes automatizados na sua build. Desde que aquele pedaço do sistema é o pedaço com que você trabalhou. as Bugs no software implantando fazem os usuários ficarem com raiva de você. Se você introduzir um problema e detecta-lo rapidamente.por onde você começa? Eu mostrei acima todo o conjunto de práticas para te mostrar todos os benefícios . Em todo tempo você sabe onde você esta. onde as falhas são apresentadas como o resultado de múltiplos erros . Introduzindo a Integração Contínua Então você imagina tentar a Integração Contínua . novamente tornando fácil de encontrar o problema.comparando a versão corrente do sistema com uma versão anterior que não tinha o bug. Em parte isto acontece porque você tem interações entre os bugs. ele ainda esta fresco em sua memória. Integração Contínua reduz completamente este problema. Mas aqui estão algumas coisas que nós temos aprendido pra ter as coisas funcionando. Um dos primeiros passos é ter uma build automatizada.barreiras que eu acredito serem as maiores barreiras para desenvolvimento de software com sucesso. Para uma resposta a isso. tanto em produção quanto em desenvolvimento.muita coisa depende da natureza do seu ambiente e do seu time. As frequentes implatações são valorosas porque elas permitem seus usuários terem as novas funcionalidades mais rapidamente. ou simplesmente fazer uma build noturna automatizada. Para muitos projetos isto não é uma coisa pequena isso é na verdade essencial para qualquer uma das outras coisas funcionarem. para darem feedback mais rapidamente sobre estas funcionalidades e geralmente se tornarem mais colaborativos no ciclo de desenvolvimento. Você também pode usar um diff debugging (ou um avaliador de diferenças) . Isto ajuda a quebrar as barreiras entre os desenvolvedores e os clientes . Geralmente. Entretanto eu devo ressaltar que o grau deste benefício esta diretam ente amarrado a quão boa sua suite de testes é. o que não funciona e os bugs pendentes que você tem em seu sistema. o que funciona. E isto também é psicológico . Tente identificar as áreas onde geralmente as coisas dão erradas e faça testes automáticos que exponham estas falhas. Particularmente. este remove uma das maiores barreiras na implantação frequente. Inicialmente você pode fazer a build sob demanda. bagunçam os cronogram e as reputações. é mais fácil remover os problemas.tornando cada erro cada vez mais difícil de ser encontrado. mas os tornam dramaticamente mais fáceis de encontrar e remover. Avançar este nível envolve trabalhar constantemente e melhorar seus testes. ter uma build noturna automatizada é um bom passo. Desde que você modificou somente uma parte pequena do sistema.mesmo que você esteja em um dos raros casos de ainda não estar atrasado.estes são as coisas sórdidas que destroem a confiança.

Se você não estiver usando Integração Contínua eu recomento fortemente você a tentar.mais do que eu já tenha alcançado).e nós temos visto outros usando IC ao redor do mundo. Isto geralmente requer algumas cirurgias sérias em sua base de código. Pode custar algum dinheiro ter um mentor. é difícil introduzi-la quando você não sabe como o resultado final deve parecer. Não existem muitas coisas sendo escritas sobre builds por estágios mas existe um ensaio escrito por Dave Farley na The ThoughtWorks Anthology que é útil (também disponível aqui). e eu espero que possamos continuar aprendendo e melhorando isso ainda mais. Você deve começar com o pensamento em algum lugar especifico. mas você pode também pagar por tempo e produtividade perdidos se você não sabe fazer isso. Tente agilizar a commit build. mas diminuir para o número mágico de 10 minutos é bem melhor. a Integração Contínua tem se tornado a principal técnica para o desenvolvimento de software. comece com a Integração Contínua desde o início. ( Aviso: sim. Nós temos aprendido muito sobre Integração Contínua nos últimos anos. Agindo rapidamente você irá fazer as reestruturações necessárias antes que a base de código fique tão grande que isso se transforme em um problema maior. .ao contrário de algumas das mais controversas práticas do Extreme Programming. Mantenha os olhos nos tempos da build e tome alguma ação logo quando quando começar a ficar mais lento que a regra dos 10 minutos. Para explorar a Integração Contínua em maiores detalhes. Pensamentos Finais Desde que Matt e eu escrevemos a versão original desde artigo. Leitura Indicada Um ensaio como este pode somente cobrir por alto algumas coisas. Encontre alguém que tenha feito integração contínua antes que possa ajudar você. Se você você estiver usando. eu sugiro dar uma olhada no livro do Paul Duvall sobre este tema (que ganhou um prêmio Jolt . Afinal de contas nós cometemos a maior parte dos erros que podem ser feitos). talvez algumas idéias pode ajudar a você fazer isso mais efetivamente. Acima de tudo tenha alguma ajuda.é difícil ter realmente uma boa suite de testes funcionando rapidamente . Integração Contínua com uma build de poucas horas é melhor do que nada. Dificilmente qualquer projeto da ThoughWorks acontece sem isso .leva tempo para construir os testes. Como qualquer técnica nova. como quebrar as dependências das partes lentas do sistema. Se você estiver começando em um projeto novo. Dificilmente eu ouço coisas negativas sobre esta abordagem . nós da ThoughtWorks fazemos algumas consultorias nesta área.

TDD (Test-driven Development) .

Sign up to vote on this title
UsefulNot useful