Diferenças entre integração, entrega e deploy contínuos

Diferenças entre integração, entrega e deploy contínuos

Há uma grande confusão sobre esses termos com a popularização das práticas DevOps, sobretudo no que difere o termo Deploy contínuo da Entrega contínua. Mas não há mistérios. São todas metodologias que sugerem a implantação de processos e ferramentas para entrega rápida de novas versões de softwares. Uma metologia é uma evolução da outra nesses processos.

Tudo se inicia na Integração contínua, a metodologia mais importante entre os três e que agrega mais valor ao negócio. A partir dela pode-se evolui para processos e técnicas recomendas pelo método Deploy Contínuo e depois para Implantação contínua. Conheça o significado de cada uma delas e veja até onde é possível otimizar o desenvolvimento e entrega do seu software.

 

Integração Contínua (Continuous Integration)

As metodologias ágeis de desenvolvimento permitiram entregas rápidas com pequenas e frequentes modificações nos códigos, em vez de versões criadas em períodos longos de tempo com grandes alterações. Com essa otimização, logo o trabalho em paralelo dos membros da equipe de desenvolvimento tornou-se possível. Como as entregas são rápidas, um programador pode atuar em uma parte do código enquanto os demais em outras e assim o desenvolvimento é mais ágil. Integração Contínua é um processo essencial dessas metodologias ágeis que permite a integração do trabalho dos membros de uma equipe o mais rápido possível com a execução de builds e testes automatizados do código.

A Integração contínua promove o trabalho conjunto e para isso é essencial que o uso de uma solução de controle de versão, como o Gitlab, Github, CVS ou Subversion. Essas ferramentas criam um repositório principal para armazenar o código e manter versões com cada modificação realizada para que seja possível revertê-las e auditá-las sempre que preciso. Para o trabalho paralelo, são criadas branches (ou trunks) nessas ferramentas que irão conter uma cópia completa do código para que seja modificado por parte da equipe sem que interferência no código principal ou em branches de outros programadores. Concluída a alteração do código de uma branch é preciso integrá-lo ao código principal. Para isso a ferramenta de controle de versão compara o código da branch e do repositório principal e mantêm apenas as diferenças, consolidando os códigos. Mas como as modificações são agéis e frequentes haverão diversas integrações, as vezes várias em um mesmo dia,  é preciso garantir que não irão gerar erros.

O processo de build e aplicação de testes devem então ser executados a cada nova modificação concluída. Desta forma o programador valida o quanto antes sua alteração para que possa atuar em uma eventual correção ou seguir para uma nova modificação o mais rápido possível. Além disso, testar pequenos trechos de códigos modificados facilita o entendimento de eventuais erros se comparados a entregas acumuladas com um grande volume de alterações o que minimiza riscos. Há diversas ferramentas para automatizar o build, como Ant e Maven para códigos Java e Nant e MSBuild para .Net. É imprescindível que o código contenham testes unitários para garantir que as novas implantações funcionem como esperado.

Por fim é preciso utilização de uma ferramenta para integração contínua, como o Jenkins ou Hudson. Elas atuam como orquestradores de todo o processo com a execução dos builds, validação dos testes e integração do código modificado ao principal. A ferramenta valida cada etapa e só segue se a anterior for executada com sucesso e envia notificações para conhecimento do desenvolvedor sobre a operação.
Integração Contínua é portanto o processo que permite integrar frequentemente alterações parciais em desenvolvimento ao código principal, sem intervenções manuais e com garantias de que funcionem como esperado para um trabalho conjunto e contínuo.

Entrega Contínua (Continuous Delivery)

A Entrega Contínua é um conjunto de práticas com o objetivo de garantir que um novo código esteja apto para ser disponibilizado em ambiente de produção. No entanto, o deploy em ambiente de produção não é automático, sendo é uma decisão de negócio a ser aprovada previamente.
A prática incorpora além de todas ações previstas na Integração Contínua, processos adicionais e necessários para que a modificação seja acessível a usuários e assim sejam realizadas inspeções finais, sejam elas manuais e/ou automatizadas.

Assim que um programador entende que sua modificação está pronta para seguir para as validações finais, é feito o deploy automatizado do novo código nos ambientes que antecedem o de produção, normalmente de Desenvolvimento e Homologação. Tudo deve ser feito com um simples apertar de um botão.
Na sequência são executados testes de comportamento para validar a lógica de negócio e/ou visuais, complementares aos testes unitários executados na fase de Integração contínua. O deploy com a nova alteração pode então ser aceita ou rejeitada e notificações são enviadas.

No caso de inspeções manuais, equipes responsáveis pelas validações, como Controle de Qualidade, recebem lotes constantes e pequenos de trabalho que são facilmente validados. Caso um eventual erro seja detectado, o programador será informado rapidamente enquanto ainda lembra dos detalhes de sua alteração. Nesta fase feedbacks são fundamentas como rege a prática DevOps.
Para que os processos da entrega contínua possam funcionar é imprescindível que a infraestrutura dos ambientes em que serão feitos os deploy e realizados os testes estejam sempre funcionais. Por isso é comum esses projetos incorporarem conceitos de Infraestrutura ágil.

Implantação Contínua (Continuous Deployment)

Esta prática é o próximo passo da Entrega contínua. Assim que o programador julga pronto seu código e aciona a solicitação para deploy, são realizadas todas validações previstas nas metodologias anteriores e, se não houverem falhas, o novo código é disponibilizado automaticamente em ambiente de produção.

A Implantação contínua não se aplica a toda empresa. Foi pensada principalmente, mas não exclusivamente, para o desenvolvimento de aplicações para web. Há muitas vezes regras de governança rígidas e necessidade de testes manuais que impedem o uso desta metodologia. Mas recomenda-se as empresas que tenham a possibilidade que tentem aplicá-la porque promove mudanças positivas e profundas na organização. Como o programador tem capacidade de colocar suas alterações em produção de forma autônoma ele passa a ser mais preocupado com questões de qualidade e confiabilidade. Com pequenas mudanças disponíveis constantemente em produção, a empresa passa a receber feedbacks pontuais e realistas de seus clientes e assim pode determinar o valor agregado e assim decidir se deve investir mais na nova funcionalidade

Implantação contínua deve incorporar ferramentas de monitoramento no ambiente de produção para certificar como as alterações influenciaram o uso de recurso. Métricas como quantidade de acesso, volume de tráfego, tempo de resposta, uso de recursos e outras devem ser monitoradas automaticamente.

Anterior Infraestrutura Ágil: TI versionada como um software!
Próxima Ferramentas do mundo DevOps

About author

Rodrigo Rodrigues Dias
Rodrigo Rodrigues Dias 8 posts

Trabalha com Linux desde 2001, onde começou com o extinto Conectiva Linux. Atuou em empresas de Consultoria e Telefonia IP e é certificado LPIC-3 303/304 e Exin DevOps Master. Foi Redator das revistas Linux PC Master e as edições extras com os saudosos CDs com as principais distribuições Linux do mercado. Foi também responsável pelo conteúdo da revista .NET, publicação inglesa adaptada ao Brasil e especializada no desenvolvimento e design web. Também foi o principal redator da Revista do CD-ROM, que marcou época. Atua hoje como Líder de Pré-Vendas da 4Linux onde auxilia clientes na definição de seus projetos Open Source. Já ministrou curso de formação Linux e Alta Disponibilidade, foi responsável pela Infraestrutura e Gerência de Projetos na 4Linux.

View all posts by this author →

Você pode gostar também

Outros assuntos 0 Comentários

Software Livre não é software, é serviço

Software Livre ( FOSS ), apesar de ser um software em seu nome e objetivo, do ponto de vista comercial, deve ser tratado como um serviço e não como um

Desenvolvimento 0 Comentários

Codeception: crie testes automatizados para suas APIs

O uso de APIs para uma comunicação padronizada entre aplicações é cada vez mais comum. Ao utilizar APIs testes precisam ser criados para validar seu funcionamento e garantir a comunicação.

Infraestrutura 0 Comentários

À prova de balas: Redis Sentinel + HAProxy

Aprenda como implantar a solução Redis para otimização de acessos em memória em Alta Disponibilidade e com a criação de um cluster com failover automatizado com Redis Sentinel Redis é

0 Comentários

Ainda não há comentários!

Você pode ser o primeiro a comentar este post!

Deixe uma resposta