Todas as organizações que desejam se manter competitivas hoje estão adotando DevOps. Um dos principais pontos para a sua equipe ser DevOps, é ter implementado a integração contínua em seus processos. Mas o que uma empresa precisa para realizar a implementação da integração contínua?

Uma característica extremamente estranha, mas comum, de muitos projetos de software é que durante longos períodos durante o processo de desenvolvimento a aplicação não está em estado de funcionamento.

Na verdade, a maioria dos softwares desenvolvidos por grandes equipes gasta uma proporção significativa de seu tempo de desenvolvimento em um estado inutilizável. A razão para isso é fácil de entender: Ninguém está interessado em tentar executar toda a aplicação até que seja concluída.

Os desenvolvedores verificam mudanças e podem até executar testes de unidade automatizados, mas ninguém está tentando realmente iniciar o aplicativo e usá-lo em um ambiente de produção.

Isso é duplamente verdadeiro em projetos que usam ramos de longa vida ou adiar testes de aceitação até o fim. Muitos desses projetos programam fases de integração longas no final do desenvolvimento para permitir que o tempo de equipe de desenvolvimento para obter os ramos fundiu, e a aplicação de trabalho para que ele possa ser aceito-testado.

Pior ainda, alguns projetos acham que, quando chegam a esta fase, seu software não é adequado para fins. Esses períodos de integração podem levar um tempo extremamente longo, e pior de tudo, ninguém tem qualquer maneira de prever quanto tempo.

Por outro lado, há projetos que gastam no máximo alguns minutos em um estado onde sua aplicação não está funcionando com as mudanças mais recentes. A diferença é o uso da integração contínua.

A integração contínua exige que toda vez que alguém cometer qualquer alteração, todo o aplicativo é construído e um conjunto abrangente de testes automatizados é executado contra ele.

Crucialmente, se o processo de construção ou teste falhar, a equipe de desenvolvimento para o que eles estão fazendo e corrige o problema imediatamente. O objetivo da integração contínua é que o software esteja em um estado de funcionamento o tempo todo.

Integração contínua representa uma mudança de paradigma. Sem ela, seu software será considerado como não funcional até que se prove que ele funciona, o que normalmente acontece durante o estágio de testes ou de integração.

Com a integração continua, assume-se que o software está funcionando (desde que haja um conjunto considerável de testes automatizados) com cada mudança – você sabe quando para de funcionar e pode consertá-lo imediatamente.

A equipe que usa integração contínua de modo eficaz é capaz de entregar software muito mais rápido, e com menos defeitos, do que equipes que não a usam. Eles são descobertos mais cedo no processo de entrega, e é mais barato consertá-los, o que representa ganhos de custo e tempo. Dessa forma, consideramos a prática essencial para times profissionais, talvez tão importante quanto o uso de controle de versão.

Implementando Integração Contínua

Integração contínua

hnz-blog-lean-e-devops-como-lean-entra-nas-praticas-devops-lean-e-devops

A prática da integração contínua depende de certos pré-requisitos estarem em vigor. Talvez o mais importante, a integração contínua depende de equipes seguindo algumas práticas essenciais. Há três coisas que você precisa antes de começar com a integração contínua.

1. Controle de Versão

Tudo em seu projeto deve estar em um único repositório: código, testes, scripts de bancos de dados, scripts de compilação e implantação, e tudo o que for necessário para criar, instalar, executar e testar sua aplicação. Isso pode parecer óbvio, mas ainda há projetos que não usam qualquer forma de controle de versão. Algumas pessoas não consideram seus projetos grandes o bastante para exigir o uso de controle de versão.

Não há projetos pequenos o suficiente para não usar controle de versão. Quando escrevemos código em nossos próprios computadores, para uso pessoal, ainda assim usamos controle de versão. Existem vários sistemas de controle de versão simples, leves e poderosos.

2. Um processo de compilação automatizada

Você deve conseguir executar seu processo de compilação a partir da linha de comando. Você pode começar com um simples programa que diz ao seu IDE como compilar a aplicação e rodar os testes, ou pode usar um sistema de múltiplos estágios que chamam outros scripts para fazer seu trabalho. Qualquer que seja o mecanismo, deve ser possível para qualquer pessoa compilar, testar e instalar a aplicação de maneira automatizada a partir da linha de comando.

3. Aceitação da equipe

Integração contínua é uma prática, não uma ferramenta. Ela requer um alto grau de comprometimento e disciplina da equipe de desenvolvimento. É necessário que todos se acostumem a fazer o check-in de nova funcionalidade no trunk de desenvolvimento em mudanças pequenas e incrementais, e que todos concordem que a tarefas de maior prioridade no projeto é consertar qualquer mudança que quebre a aplicação.

Se as pessoas não adotarem a disciplina necessária para que isso funcione, qualquer tentativa de integração contínua não levará às melhorias de qualidade esperadas.

Processo a ser seguido quando você estiver pronto para fazer o check-in de uma mudança

Quando rodar a ferramenta de IC pela primeira vez, você provavelmente vai descobrir que a máquina em que ela está sendo executada não possui o software ou as configurações necessárias para o processo de compilação. Essa é uma oportunidade única – anote tudo o que você precisa para fazer a aplicação funcionar e coloque na página do projeto. você deve, então, colocar todas essas aplicações e configuração necessárias no sistema de controle de versão e automatizar o provisionamento de uma nova máquina.

O próximo passo é que todos comecem a usar o servidor de IC. Abaixo está um processo simples a ser seguido quando você estiver pronto para fazer o check-in de uma mudança:

  • Verifique se o processo de compilação está rodando. Se está, espere ele terminar. Se falhar, você precisa trabalhar com o restante da equipe para fazê-lo ter sucesso antes de enviar suas mudanças para o controle de versão.
  • Quando o processo terminar, e os testes forem bem-sucedidos, atualize o código em sua versão de desenvolvimento de controle de versão.
  • Execute os scripts de compilação e de testes na máquina de desenvolvimento, e garanta que tudo está funcionando corretamente em sua máquina, ou use a funcionalidade de compilação pessoal da ferramenta de IC.
  • Se a compilação local funcionar, faça o check-in.
  • Espere que a ferramenta de IC execute com suas mudanças.
  • Se o processo falhar, pare o que estiver fazendo e conserte o problema imediatamente em sua máquina local, voltando ao passo 3.
  • Se o processo for bem-sucedido, pule de alegria e passe para a próxima ferramenta.

Se todos no time seguirem esses passos simples sempre que fizerem uma mudança no código, você saberá́ que sua aplicação executa em uma máquina com as mesmas configurações da máquina de IC continuamente.

Pré-requisitos para a implementação da integração continua

Integração contínua

A prática de integração contínua, por si só́, não resolverá problemas no processo de compilação. De fato, pode ser bem sofrido começá-la no meio do projeto. Para que ela seja eficiente, as seguintes práticas devem ser seguidas antes do início.

Check-ins regulares: A prática mais importante de integração contínua é a de check-ins regulares para o trunk de desenvolvimento. De fato, check-ins devem acontecer regularmente ao longo do dia. Essa prática traz outros benefícios. Torna suas mudanças menores e reduz a probabilidade de falharem. Isso significa que você sempre terá́ uma versão anterior do software se precisar reverter mudanças incorretas ou que foram na direção errada. Também ajuda você a ser mais disciplinado sobre refatoração e se ater a mudanças menores para preservar o comportamento. Ajuda a garantir que mudanças que alterem muitos arquivos tenham pouca chance de entrar em conflito com o trabalho dos outros. Permite que desenvolvedores explorem mais, experimentando ideias e descartando-as ao reverter para a versão anterior. Força desenvolvedores a parar regularmente e esticar seus músculos para evitar a síndrome do túnel do carpo ou lesão por esforço repetitivo (LER). Também significa que, se algo catastrófico acontecer (como a remoção acidental de algum arquivo), você não perdeu muito trabalho.

Crie um conjunto de testes automatizados abrangente: Se você não tem um conjunto abrangente de testes automatizados, uma compilação que foi bem-sucedida significa apenas que a aplicação pode ser compilada. Embora isso já́ seja um grande passo para algumas equipes, é essencial que haja algum nível de testes automatizados para garantir que a aplicação está de fato funcionando. Há três tipos de testes que deveriam ser executados a partir do processo de integração continua: testes unitários, testes de componentes e testes de aceitação.

Mantenha o processo de compilação e de testes curto: Se levar muito tempo para compilar o código e rodar os testes unitários, você acabará enfrentando os seguintes problemas. As pessoas vão parar de rodar a compilação por completo e de executar os testes quando fazem um check-in, o que fará a compilação falhar com mais frequência; O processo de integração contínua demorará tanto que diversos check-ins terão sido feitos até o momento em que a compilação voltar a ser executada, de modo que você não saberá́ qual deles quebrou a compilação, se esse for o caso; As pessoas farão check-ins menos frequentes porque terão de esperar um bom tempo para que o software seja compilado e os testes rodem.

Como gerenciar seu espaço de trabalho de desenvolvimento: É importante para a produtividade e a sanidade dos desenvolvedores que seu ambiente de desenvolvimento seja cuidadosamente gerido. Desenvolvedores sempre devem trabalhar a partir de algum ponto bem conhecido quando começam algo novo. Eles devem ser capazes de executar o processo de compilação, de executar os testes automatizados e de implantar a aplicação em um ambiente de controle. Em geral isso deve ser feito em suas próprias máquinas locais. Apenas em circunstâncias especiais podem ser usados ambientes compartilhados para o desenvolvimento. A execução da aplicação em um ambiente local de desenvolvimento deve usar os mesmos processos automatizados usados no servidor de integração contínua e nos testes de ambiente e, em última instância, em produção.

Newsletter HNZ

Gostou do conteúdo? No artigo seguinte iremos ver nove práticas essenciais que a sua equipe deve ter para que o processo de integração contínua ocorra de forma correta. Se cadastre na nossa newsletter clicando aqui e não perca nenhum conteúdo!

HNZ

HNZ

Leave a Reply