Hora de NetOps adotar a implantação contínua

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

CI/CD (Integração Contínua/Entrega Contínua) é o domínio dos desenvolvedores. É o modelo abrangente para melhorar a velocidade de entrega – o que realmente significa “pronto para implantação” para aqueles acostumados a vê-lo em um contexto mais ativo e relacionado ao usuário.

Isso não significa que o NetOps pode ignorar CI/CD. Pelo contrário. Mas isso não significa que a NetOps tenha que manter uma proporção de implantação para entrega de 1:1. A frequência com que os aplicativos estão "prontos para implantação", especialmente se os desenvolvedores do seu aplicativo aperfeiçoaram a arte da entrega contínua, pode ser impressionante, principalmente se o NetOps ainda não aperfeiçoou a arte da implantação contínua.  Mas há espaço para acomodar uma frequência maior de implantação que, em alguns casos, certamente terá o sabor de implantação contínua para os desenvolvedores e para a empresa. 

O segredo está na diferença entre “pequenas mudanças” e “grandes mudanças” em um aplicativo.

A pesquisa NetDevOps Fall 2016 descobriu que pequenas mudanças estavam sendo introduzidas na produção com muito mais frequência do que somos levados a acreditar. Quase 51% dos entrevistados estão implementando pequenas mudanças na produção mais de uma vez por dia. Mais de um em cada três estava promovendo grandes mudanças entre 1 e 5 por mês, com outro terço confessando que fazia grandes mudanças menos de uma vez por mês.

Infelizmente, a definição de mudanças “maiores” e “menores” não é quantificada, mas, como geralmente acontece, tais descritores relativos são frequentemente peculiares não apenas a um setor ou organização, mas frequentemente a cada aplicação. Ainda assim, parece que um bom número — um pouco mais da metade — está implementando grandes mudanças na produção de forma muito regular.

O que significa que, no grande esquema das coisas, estamos dando pequenos passos na direção da implantação contínua. O problema é que implantar um aplicativo novo e brilhante não é a mesma coisa que implantar atualizações em um aplicativo existente. Mesmo se estivermos adicionando novos serviços de rede ou aplicativo, ainda é muito diferente na escala de "potencial de interrupção" do que a implantação de um aplicativo totalmente novo.

Então digamos que, por enquanto, novos aplicativos brilhantes exigirão mais coordenação e planejamento. Ainda temos o que certamente são a maioria dos aplicativos em produção como alvos potenciais para implantação contínua. Uma das coisas que podemos fazer para incentivar isso é contextualizar as mudanças “menores” versus “maiores” com relação ao seu impacto nos ambientes de produção.

Pequenas alterações podem ser restritas àquelas que impactam o aplicativo internamente. Mudanças na lógica, por exemplo. Eles podem incluir patches ou atualizações para a pilha de aplicativos (servidor web, servidor de aplicativos, etc.), bem como para sua infraestrutura de aplicativo de suporte. Basicamente, pequenas mudanças impactam apenas o aplicativo. Elas não exigem mudanças na rede ou nos serviços do aplicativo que realmente entregam e protegem esse aplicativo em seu uso típico.

Grandes mudanças, então, seriam aquelas que impactam qualquer coisa na rede ou nos serviços de aplicativo que dão suporte ao aplicativo. Grandes mudanças podem exigir ajustes em uma política de entrega (ative a compressão, ok?) ou a inserção de um novo serviço, como filtragem de URL ou inspeção de solicitação para evitar a exploração de uma vulnerabilidade descoberta recentemente. Essas são mudanças importantes porque impactam um conjunto mais amplo de sistemas de produção que podem ou não impactar outras aplicações.

Pode até ser que você crie um sistema de pontuação mais detalhado que leve em consideração o impacto em serviços externos. Um novo serviço provavelmente é mais disruptivo do que um ajuste em um serviço existente. Uma nova política requer mais atenção à implementação do que uma política existente com uma pequena atualização.

Depois de concordar com o “sistema” que você vai usar, fica muito mais fácil concordar em permitir pequenas alterações sob demanda. Basicamente, você está migrando para a implantação contínua ao permitir que a entrega do aplicativo flua para a produção , desde que seja considerado que isso terá impacto potencial mínimo se algo der errado. Pequenas mudanças, pequenos riscos. Pelo menos é o que se supõe.

O que isso faz é permitir que pequenas mudanças técnicas , que poderiam ser grandes mudanças comerciais , cheguem às mãos dos usuários mais rapidamente. Porque essas tarefas geralmente são realizadas em organizações grandes e tradicionais. Mesmo uma pequena alteração na interface do usuário pode ser adiada por semanas – ou mais – devido a conflitos de agendamento e decisões tomadas por conselhos de controle de mudanças com base nas prioridades ou políticas do projeto. Mesmo que essa pequena mudança possa representar uma melhor experiência do usuário, resultando em maiores taxas de conversão ou retenção de clientes. Se essa pequena mudança afeta apenas o aplicativo , ou seja, é uma mudança "menor", as políticas de TI são realmente um motivo para retê-la?

A implantação contínua não é apenas habilitar tecnicamente envios automatizados para produção, mas também destruir construções tradicionais que impedem os processos que determinam quando os aplicativos e atualizações entram em produção (isso é cultura).

Ao estabelecer um critério comum para diferenciar entre atualizações "menores" e "maiores", entre aquelas que têm o potencial de impactar sistemas fora do aplicativo e aquelas que não têm, as organizações podem permitir a implantação contínua de algumas alterações sem incorrer em riscos adicionais ou desestabilizar a produção. E isso pode significar um impacto positivo para o negócio, o que significa que todos ganham.