É hora de o NetOps adotar a implantação contínua

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

A implantação contínua não precisa significar que todas as mudanças sejam implementadas imediatamente, todas as vezes. Mas é preciso começar por algum lugar.

CI/CD (Integração Contínua/Entrega Contínua) é uma área voltada aos desenvolvedores. É o modelo abrangente para agilizar a entrega — o que, para quem está acostumado a vê-la em um contexto mais ativo e relacionado ao usuário, na verdade significa “pronto para implantação”.

Isso não significa que a equipe de NetOps possa ignorar a CI/CD. Pelo contrário. Mas também não significa que ela precise manter uma proporção de 1:1 entre implantação e entrega. A frequência com que os aplicativos ficam “prontos para implantação”, especialmente se os desenvolvedores tiverem dominado a arte da entrega contínua, pode ser excessiva, sobretudo se a equipe de NetOps ainda não tiver dominado a arte da implantação contínua. Mas há espaço para comportar uma frequência maior de implantações que, em alguns casos, certamente parecerá uma implantação contínua para os desenvolvedores e para a empresa.

O segredo está na diferença entre “pequenas alterações” e “grandes alterações” em um aplicativo.

A pesquisa NetDevOps do segundo semestre de 2016 constatou que pequenas alterações eram implantadas em produção com muito mais frequência do que geralmente somos levados a acreditar. Quase 51% dos entrevistados implantavam pequenas alterações em produção mais de uma vez por dia. Mais de um em cada três implantava de uma a cinco grandes alterações por mês, enquanto outro terço admitiu fazer grandes alterações menos de uma vez por mês.

Infelizmente, a definição de mudanças “grandes” e “pequenas” não é quantificada, mas, como geralmente acontece, esses descritores relativos costumam ser específicos não apenas de um setor ou de uma organização, mas também de cada aplicação. Ainda assim, parece que um número considerável — pouco mais da metade — está implantando grandes mudanças em produção com bastante regularidade.

Isso significa que, no panorama geral, estamos dando pequenos passos rumo à implantação contínua. A questão é que implantar uma aplicação nova em folha não é o mesmo que implantar atualizações em uma aplicação existente. Mesmo que estejamos adicionando novos serviços de rede ou de aplicação, isso ainda é muito diferente, na escala de “potencial de interrupção”, da implantação de uma aplicação totalmente nova.

Então, vamos considerar por enquanto que aplicativos novinhos em folha exigirão mais coordenação e planejamento. Ainda assim, certamente a maioria dos aplicativos em produção continua sendo um possível alvo para implantação contínua. Uma das coisas que podemos fazer para incentivar isso é contextualizar as mudanças “menores” em comparação com as “maiores” no que diz respeito ao impacto delas nos ambientes de produção.

Pequenas alterações podem se limitar àquelas que afetam o aplicativo internamente. Alterações na lógica, por exemplo. Elas podem incluir correções ou atualizações na pilha do aplicativo (servidor web, servidor de aplicativos etc.), bem como na infraestrutura de suporte ao aplicativo. Basicamente, as alterações pequenas afetam apenas o aplicativo. Elas não exigem alterações na rede nem nos serviços de aplicativos que efetivamente disponibilizam e protegem esse aplicativo em seu uso habitual.

As mudanças de grande porte, portanto, seriam aquelas que afetam qualquer elemento da rede ou dos serviços de aplicação que dão suporte ao aplicativo. Mudanças de grande porte podem exigir ajustes em uma política de entrega (que tal ativar a compactação?) ou a inclusão de um novo serviço, como filtragem de URLs ou inspeção de solicitações, para impedir a exploração de uma vulnerabilidade descoberta recentemente. Essas mudanças são consideradas de grande porte porque afetam um conjunto mais amplo de sistemas de produção que, por sua vez, podem ou não afetar outros aplicativos.

Talvez você até desenvolva um sistema de pontuação mais detalhado, que leve em consideração o impacto sobre serviços externos. Um novo serviço provavelmente causará mais transtornos do que um ajuste em um serviço existente. Uma nova política exige mais atenção durante a implementação do que uma política existente que receba uma pequena atualização.

Depois de chegar a um acordo sobre o “sistema” que será usado, fica muito mais fácil concordar em permitir pequenas alterações sob demanda. Basicamente, você está adotando a implantação contínua ao permitir que a entrega de aplicativos flua para a produção desde que se considere que o impacto potencial seja mínimo caso algo dê errado. Pequenas alterações, pequenos riscos. Pelo menos essa é a premissa.

Isso permite que pequenas mudanças técnicas que podem representar grandes mudanças para o negócio cheguem mais rapidamente às mãos dos usuários. Isso porque elas costumam ser postergadas em organizações grandes e tradicionais. Até mesmo uma pequena mudança na interface do usuário pode ser adiada por semanas — ou mais — devido a conflitos de agenda e decisões tomadas por comitês de controle de mudanças com base em prioridades de projetos ou questões políticas. Mesmo que essa pequena mudança possa proporcionar uma experiência melhor ao usuário, resultando em taxas mais altas de conversão ou retenção de clientes. Se essa pequena mudança afetar apenas o aplicativo, ou seja, se for uma mudança “pequena”, será que as questões políticas da TI são realmente motivo para adiá-la?

A implantação contínua não se resume a viabilizar tecnicamente o envio automatizado para produção; ela também envolve derrubar estruturas tradicionais que atrasam os processos que determinam quando aplicações e atualizações entram em produção (isso é cultura).

Ao estabelecer critérios comuns para diferenciar atualizações “menores” de “maiores” — entre aquelas que podem afetar sistemas externos ao aplicativo e aquelas que não podem —, as organizações podem viabilizar a implantação contínua para algumas mudanças sem gerar riscos adicionais nem desestabilizar o ambiente de produção. E isso pode até ter um impacto positivo nos negócios, o que significa que todos saem ganhando.

Sobre o autor

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.

Mais publicações de Lori Mac Vittie