Desvendando o DevOps: Entenda a Integração, Entrega e Implantação Contínua

Continuous Integration (Integração Continua), Continuous Delivery (Entrega Continua) e Continuous Deployment (Implantação Continua) são práticas DevOps muito populares nos últimos anos, mas o que são e as diferenças entre elas ainda são assuntos que causam confusão. 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.

Acesse rapidamente o que te interessa:

• Sobre DevOps
• As metodologias Ágeis
• Continuous Integration
• Continuous Delivery
• Continuous Deployment

Sobre DevOps

Antes de tudo é preciso entender a prática DevOps. Fundamentalmente, o objetivo de DevOps é direcionar o desenvolvimento de software ao que realmente agrega valor ao negócio, ou seja, manter os esforços em produzir somente o que os clientes entendem como apropriado e em um ritmo constante. DevOps sugere validar continuamente se o que está sendo codificado e foi planejado tem mesmo valor prático ao cliente para então decidir continuar a investir ou mudar o foco de acordo. Quanto menor e mais recorrente for o ciclo de lançamento, mais eficiente e assertivo será esse processo.

Parece simples, mas há uma série de desafios envolvidos. Entregar continuamente software em desenvolvimento é um potencial risco a estabilidade da operação. Cada nova versão lançada é um evento potencialmente critico e que, caso apresente falhas, pode comprometer a experiência do cliente e consequentemente diminuir o valor do negócio. Então é importante agregar novos valores, como inovações e velocidade, mas é também fundamental garantir que os valores possam ser experimentados adequadamente. Esses dois polos são desafios comuns em qualquer empresa e conhecidos como sistemas SoE (System of Engagement ou Sistema de Engajamento) e SoR (System of Register ou Sistema de Registro)

O SoE é o termo usado para representar as ações da empresa necessárias para se manter ágil e inovadora. Da mesma forma, o SoR representa outra parte que tem como necessidade manter tudo funcional. O problema é como fazer para que SoR possa se adaptar rapidamente às mudanças esperada no SoE para manter a continuidade do negócio. Esse desafio é conhecido como TI bimodal. Equipes de Desenvolvimento é um setor que representa as motivações SoE de uma empresa, enquanto a equipe de Operações as SoR. A prática de DevOps leva a consolidação desses dois sistema para que seja possível ser ágil sem comprometer a continuidade do negócio.

A palavra DevOps designou-se a partir da junção das palavras ‘Desenvolvimento’ e ‘Operações’. DevOps enfatiza a cooperação por toda a organização e a automação de entregas e mudanças na infraestrutura, levando à Continuous Integration, Continuos Delivery e Continuous Deployment

A adoção de DevOps leva aos seguintes princípios:

• Integração Contínua: fácil transferência de controle do Desenvolvimento para Operações e Suporte;
• Implantação Contínua: liberação continua ou tão frequente quanto possível;
• Feedback Contínuo: buscar feedback das partes interessadas durante todas as fases do ciclo de vida

Leia mais sobre O que é DevOps.

As metodologias ágeis

Durante muitos anos os modelos de desenvolvimentos em cascata (waterfall) dominaram. Basicamente gastava-se um bom tempo definindo um escopo extenso e detalhado para então desenvolver por meses uma nova versão de software a ser lançada. Esse modelo apresentava vários pontos críticos:

• Entre o lançamento de uma versão e outra, vários meses se passavam sem que o cliente recebesse algo novo que agregasse valor;
• Cada nova versão acumulava muitas mudanças o que tornava complexa a busca ou correções por bugs;
• Ajustes no escopo não eram bem vindos e o cliente tinha pouca chances de validar e ajustar a entrega antes do lançamento das novas versões.

Esse método é considerado um anti padrão DevOps.

Atualmente as metodologias ágeis de desenvolvimento dominam e permitem criar softwares mais rapidamente e alinhado ao que os clientes precisam. Os métodos ágeis atende melhor as ambições atuais e são uma das bases da cultura DevOps:

• O desenvolvimento é distribuídos em ciclos de lançamentos curtos e recorrentes chamados de Sprint com tempo médio de 2 semanas cada;
• Cada nova versão possui um conjunto mínimo de funções experimentáveis que são mais fáceis de validar e ajustar ;
• Ajustes no escopo são esperados e encorajados. O cliente valida e dá feedbacks sobre as pequenas entregas para receber somente recursos com valores agregados.

Os métodos ágeis permitiram o desenvolvimento rápido de software, o que atende as expectativas SoE (Sistema de Engajamento) das empresas. Mas ainda assim não se conseguia entregar as versões criadas na mesma velocidade em que eram codificadas. Isso porque essas metodologias não lidam com a continuidade do negócio e não atendem  as necessidades SoR (Sistema de Registro) das empresas. Cada nova versão ainda era um potencial risco de implantação.

A cultura DevOps surgiu para solucionar esta questão e permitir elevar o desenvolvimento ágil a um novo nível onde fosse possível lançar em produção novos releases na mesma velocidade – ou muito próxima – em que são criados. DevOps incorpora uma série de automações executadas em sequência em um processo fluído e contínuo que permite validar automaticamente cada novo release para que possa ser implantado com segurança e com baixo risco a continuidade do negócio atendendo assim ao atual desafio bimoldal das empresas.

Continuos  Integration – CI (Integração Contínua)

A prática de CI (Continuos Integration ou Integração Continua) é mais importante prática DevOps e a primeira a ser adotada. Ela permite aos desenvolvedores validarem seus códigos automaticamente para garantir de que estejam livres de erros e que não conflitem com o restante do código da aplicação.

Em um processo de CI a premissa é que o código fonte da aplicação esteja disponível em uma sistema de versionamento como o Gitlab, Github, CVS ou Subversion. E que vários desenvolvedores estejam trabalhando nesse código e gerando continuamente novas funcionalidades. O CI deve garantir que novos códigos em desenvolvimentos estejam livres de erros, em uma qualidade mínima aceitável e que não conflitem com o restante do código da aplicação já desenvolvido. É muito comum em projetos de desenvolvimento surgirem problemas quando preciso integrar diversas novas funcionalidades em desenvolvimento ao código principal (processo de merge). Potenciais problemas muitas vezes são descobertos somente nas fases posteriores de homologações não automatizadas que levam tempo de serem concluídas ou até mesmo depois de implantados em produção. O processo de CI deve reduzir esse riscos e otimizar o tempo das validações.

Integração Contínua é 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

Fluxo CI (Continuous Integration)

Como funciona

O processo de CI inicia-se sempre que um programador concluir o desenvolvimento de uma funcionalidade (chamado de história na metodologia de Desenvolvimento Ágil Scrum) e submete o código ao repositório da aplicação (processo commit). Neste momento, testes unitários são executados automaticamente por alguma ferramenta de automação (como o Jenkins) para garantir que não haja erros no código.

Os testes unitários são fundamentais para CI devem idealmente serem criados com base na metodologia TDD.

Ciclo TDD

Assim que o código passar pelo teste unitário podem ser aplicados testes para validar a qualidade do código (como o Sonar) e assim estimular os desenvolvedores a fatorarem seus códigos.

Em seguida testes de integração devem ser aplicados automaticamente para validar se o novo código não irá comprometer o restante da aplicação. Esses testes devem ser criados sempre que um novo código precisar se relacionar com outras partes da aplicação. Para aplicações que usam linguagens que precisam ser compiladas, o novo código é antes compilado (processo build) automaticamente e disponibilizado em um servidor (comumente chamado de servidor de integração ou de desenvolvimento) onde são executados os testes de integração. Há diversas ferramentas para automatizar o build, como Ant e Maven para códigos Java e Nant e MSBuild para .Net..

Como o processo de CI deve ser contínuo, caso o servidor  de integração não esteja disponível ele deverá ser criado automaticamente durante o processo de validação. Pode-se inclusive criar os servidores sob demanda, eliminado-os quando os testes forem concluídos. Para criação automatizada de servidores deve-se usar alguma ferramenta de provisionamento (como Ansible ou Puppet) ou adotar servidores imutáveis baseados em containers (como o Docker).

O desenvolvedor recebe notificações sobre o sucesso ou não das validações. Ele deve idealmente submeter seu código pelo menos duas vezes ao dia ao processo de CI para não correr o risco de perder tempo desenvolvendo um código que possa conflitar com o restante já criado.

Continuos  Delivery – CD (Entrega Contínua)

Na Integração Continua todas as validações e compilações são feitas em ambiente de desenvolvimento com objetivo de otimizar os processos de criação de softwares. O potencial em criação ainda não pode ser experimentado pelos usuários então o valor agregado ainda não é alcançado pelos clientes. Para um novo release entrar em produção é necessário realizar testes de aceitação que são complementares as validações feitas na fase de CI e fundamentais para determinar se um software está apto para seguir em produção. No entanto, o deploy em ambiente de produção não é automático na Entrega Contínua, sendo uma decisão de negócio a ser aprovada previamente.

Entrega Contínua é um processo complementar ao CI em que são realizados testes de aceitação em ambientes pré-produção e realizadas preparações finais para que um novo código esteja apto para seguir para produção após aprovação

Fluxo Continuous Delivery também conhecido como fluxo CI/CD por incorporar os processos de Continuous Integration

Como funciona

Depois que o processo de CI é concluído o novo código é implantado em ambiente de Homologação (também conhecido como Staging) onde são executados testes de aceitação. Essa etapa pode incluir testes de interface (com a ferramenta Selenium por exemplo) que validam automaticamente funcionalidades esperadas como também podem incluir testes de desempenho, segurança e outros. É comum testes de aceitação manuais e complementares realizados por uma equipe de Q&A serem incluídos nesse processo.Os testes automatizados devem ser evoluídos continuamente até o ponto de cobrirem a maior parte das validações necessárias, restando pouca tarefa para as etapas com verificações finais e manuais.

Pode-se submeter cada nova história concluída ao processo de CD ou restringi-las apenas ao processo de CI para então serem acumuladas para formarem um novo release que então seguiria para CD. Esta estratégia dependerá do plano de lançamento e capacidade de execução de testes de cada empresa. Idealmente, o quanto antes uma nova modificação chegar ao cliente melhor será.

Os servidores em ambiente de homologação devem ser o mais próximos possíveis dos usados em produção e devem também ser criados automaticamente sempre que preciso para que processo seja interrupto. É importante incorporar uma Infraestretura Ágil neste processo para gestão automatizada da infraestrutura e sem interrupções. Para alguns projetos é comum nesta etapa versionar novos componentes já compilados e validados da aplicação em um servidor de versionamento de arquivos binários, como Nexus ou Artfactory.

Notificações são enviadas sobre todo o processo. As equipe de Q&A recebem cargas de trabalho contínuas e pequenas que são fáceis de serem validadas. Desenvolvedores recebem feedbacks sobre eventuais erros nos seus novos códigos rapidamente a tempo de ainda se lembrarem dos detalhes de suas codificações. Clientes recebem novos releases regularmente e podem fornecer feedbacks sobre o que tem mais valor para eles para que o escopo do projeto possa ser sempre ajustado.

Na Entrega Contínua o deployment em produção não é automático, mas deve ser realizado de forma automatizada quando aprovado através de um simples acionamento de botão.

Fluxo de uma implantação CI/CD

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.

Diferença entre Continuous Delivery e Continuos Deployment

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.