Não durma com atualizações do código-fonte

Refazer as etapas para manter e atualizar o código-fonte é uma tarefa difícil, especialmente para organizações que dependem de software de código aberto (OSS) com janelas de suporte limitadas. À medida que o tempo passa e o código é lançado com mais frequência, fica mais difícil lembrar o que é o quê, qual versão você usou e por que alguém escreveu o código daquela maneira. E à medida que a dívida técnica aumenta, torna-se cada vez mais difícil voltar atrás e resolver potenciais problemas ou CVEs. Além disso, à medida que as estruturas e ferramentas OSS evoluem, o esforço necessário para migrar para a versão mais recente fica mais pesado.

As organizações que operam em setores altamente regulamentados enfrentam desafios ainda maiores. Para aderir aos mandatos e padrões, as atualizações podem funcionar como um ponto de verificação crítico que deve ser concluído conforme a política ditar ou conforme surgirem CVEs. Fazer essas atualizações apenas como eventos únicos, quando obrigatório, adiciona outra barreira a um pipeline de entrega de aplicativos muitas vezes complicado e com muitos processos.

Vimos isso em primeira mão no final de 2023, quando o fim do suporte OSS para versões da estrutura Java de código aberto Spring Boot (2.x) fez com que muitas organizações tentassem abrir espaço em seu roteiro para atualizar ou estender sua janela de suporte por meio de suporte comercial. .

O valor comercial sempre triunfa

Na época em que entregar um novo código exigia meses de trabalho, quando o código era deixado intacto, funcionando perfeitamente no data center por meio ano, o mantra era simples: “Se não está quebrado, não conserte.” As divulgações trimestrais foram o melhor cenário. Mais frequentemente, as atualizações ocorriam duas vezes por ano, às vezes até anualmente.

A maioria das atualizações de código se concentrava no fornecimento de novas funcionalidades para os negócios, com pouco tempo poupado para resolver problemas técnicos. Segurança e estabilidade, a menos que explicitamente solicitadas pelos usuários finais, eram frequentemente negligenciadas. Engenheiros e arquitetos de software lutaram para defender esses elementos cruciais, apenas para vê-los se transformarem em questões maiores ao longo do tempo. Como tal, corrigir código antigo se tornou uma tarefa hercúlea, à medida que os desenvolvedores mantinham distância da base de código antiga.

Isto fomentou a percepção de que a atualização do código-fonte é um processo complicado, difícil e de baixo valor comercial. A atualização contínua do código-fonte ainda não encontrou o seu lugar no coração da cultura organizacional, e muitas empresas ainda prendem a respiração, recorrendo a qualquer medida para ajudá-las a escapar da ameaça iminente dos CVEs.

Por que as atualizações são importantes: o exemplo Spring/Java

O ecossistema Java/Spring é um ótimo exemplo de por que as atualizações contínuas de código são importantes. Java é uma linguagem notável e, ao longo de seus 25 anos de história, poucas atualizações quebraram o código existente. Um feito incrível – mas uma faca de dois gumes. Embora o código escrito nos anos 90 ainda possa ser executado na versão mais recente do Java, se nenhum patch, nenhuma manutenção e nenhuma atualização de dependência acontecesse ao longo do caminho, você estaria em uma situação ruim.

Hoje as coisas estão avançando mais rápido e há mais ameaças do que nunca à área de superfície dos aplicativos. Numa nota mais positiva, o ritmo da inovação também está a aumentar rapidamente e a procura pelas melhores e mais recentes ferramentas e tecnologias cria mais incentivos para as equipas de desenvolvimento se atualizarem.

Por exemplo, Java 21 e Java 22 são amplamente considerados entre os lançamentos mais significativos na história do Java, fornecendo novos recursos e inovações essenciais para aqueles que fazem a atualização. Embora tenha sido possível continuar com o suporte Java fornecido pela Oracle, muitas organizações estão deixando de lado economias e benefícios potenciais ao não atualizarem.

Algumas organizações resistem às atualizações acreditando que as versões mais antigas são mais estáveis, mas isso geralmente não é o caso. Patches para Spring Boot 3.1 e 3.2 são lançados no mesmo dia e corrigem as mesmas coisas, então não há nada que torne alguém inerentemente mais estável. Mas ao continuar com o 3.1, você está perdendo os novos recursos introduzidos no 3.2.

Por exemplo, a capacidade do Spring Boot de aproveitar a Restauração Coordenada no Checkpoint acelera o tempo de inicialização. Enquanto isso, as Imagens Nativas permitem a criação de áreas de aplicação menores, reduzindo a área de superfície do que está sendo exposto. Essa combinação torna os aplicativos menos vulneráveis ​​a ameaças potenciais e reduz a memória necessária para hospedá-los.

Uma cultura de atualizações contínuas

A criação de uma cultura de atualizações contínuas permite que sua organização acompanhe as inovações e se defenda melhor contra malfeitores. Quando as atualizações se tornam uma parte normal do seu ciclo de vida de desenvolvimento de software, não são mais necessários dois ou três sprints para atualizar e você não precisa dizer ao gerente de projeto que não pode entregar um recurso porque está trabalhando em um projeto. lista de tarefas técnicas. São ferramentas + automação + disciplina para fazer isso conforme você avança. O caminho a seguir não se trata de quão legal e sofisticado você pode ser, mas sim de quão sustentável é seu código. Trata-se de ser capaz de esperar alguns anos e ter certeza de que seu código será mantido e não adicionará mais dívida técnica ao que está em execução na produção. Embora atualizações importantes ainda possam exigir algum trabalho, haverá botões e receitas fáceis de acompanhar.

O objetivo é criar uma cultura onde as atualizações contínuas se tornem tão incorporadas ao seu processo que não exijam uma segunda reflexão. É a garantia de que o que você envia para o mercado hoje resistirá ao teste do tempo, permanecendo seguro e protegido nos próximos anos e garantindo que você atenda aos requisitos de conformidade. Parece ótimo, mas é necessário um investimento para chegar lá.

Construindo seus músculos de atualização

Para organizações que não estão no processo de fazer atualizações e ainda usam versões mais antigas do Java, o músculo da atualização nem sempre é fácil de ativar. Não há código de trapaça para pular o treinamento e fazer isso funcionar em grande escala. Toda organização tem padrões ou métodos (como bibliotecas internas ou APIs antigas) que não podem simplesmente ser conectados a uma receita existente… estarão envolvidas alterações de código.

É hora de ir para a academia – e você precisa de um plano de treino. Aqui estão três dicas a serem consideradas.

1. Comece com a adesão da liderança

Como qualquer grande mudança na forma como as coisas são feitas dentro de uma organização, a mudança cultural defendida pela liderança é crítica para o sucesso. As pessoas responsáveis ​​por mais do que apenas a funcionalidade dos aplicativos devem estar presentes antes que você possa avançar. Isso pode significar que o CIO, o CSO, os arquitetos corporativos e até mesmo os líderes de aplicativos que possuem os portfólios

Os líderes de software não podem mais se dar ao luxo de apostar seus negócios (e os negócios de seus clientes) na segurança de seu código. Reduzir o tempo entre o anúncio de um CVE e a correção do código agora é fundamental.

2. Priorize o planejamento de lançamento e a visibilidade do portfólio

Acima de tudo, um bom plano e visibilidade são os pré-requisitos críticos antes de começar a trabalhar com qualquer código. Isso começa com a compreensão de quais lançamentos estão vindo em sua direção. Por exemplo, houve apenas quatro semanas em 2023 em que o Spring Framework não teve lançamento. A equipe do Spring está continuamente extraindo dependências de terceiros para que tudo em cada versão seja corrigido, testado entre si e validado para funcionar.

Estar ciente do que está por vir e entender o trem de lançamento dessas dependências é valioso, para que você sempre saiba quando tudo foi corrigido.

Igualmente importante, seu CSO também precisa ter uma lista de todos os CVEs conhecidos que estão chegando e visibilidade do que realmente está sendo executado em produção no portfólio de seu aplicativo. À medida que os recursos e a base de código crescem, é fácil perder coisas. Os desenvolvedores estão sempre em busca de soluções para resolver seus problemas, então talvez no caminho eles tenham inserido uma biblioteca aqui e ali para ajudá-los a resolver o que precisavam. Você precisa de visibilidade contínua de tudo isso.

3. Aproveite ferramentas e automação

Ao usar ferramentas de varredura e descoberta de aplicativos, você pode identificar onde estão os maiores riscos em seu portfólio, agrupar os aplicativos em oportunidades fáceis de atualização e identificar o que exigirá um pouco mais de esforço. É aqui que entra a automação.

Ferramentas de automação

Quando estiver pronto para começar a atualizar seus aplicativos, você precisará determinar um ponto de partida razoável que não afete ou interrompa seu pipeline de desenvolvimento existente. Pode não ser sustentável que todas as suas equipes comecem a lidar individualmente com as atualizações; em vez disso, uma equipe pequena e alguma automação podem ser um bom ponto de partida.

Para os aplicativos que sua análise identifica como fáceis de atualizar ou que exigem menos abordagem de luvas brancas, ferramentas como Open-Rewrite oferecem uma maneira simples de começar a automatizar sua refatoração e correção. Open-Rewrite consiste em um mecanismo de refatoração automática que executa receitas de refatoração de código aberto pré-empacotadas para migrações de estruturas comuns, correções de segurança e tarefas de consistência estilística.

Depois de lidar com os aplicativos fáceis de atualizar, você poderá começar a trabalhar nos aplicativos complexos que não possuem receitas existentes. À medida que você aprende mais sobre seus aplicativos que precisam ser atualizados, você pode desenvolver suas próprias receitas para ampliar seus esforços de atualização e estabelecer sua própria estrutura daqui para frente.

Plataformas de aplicativos

Uma questão que pode surgir ao atualizar o código-fonte é como gerenciar o código em execução na produção enquanto trabalha na atualização. Você desativa o aplicativo durante a atualização? É aqui que as plataformas de aplicativos brilham em relação às ferramentas e serviços interligados. De acordo com o relatório State of Cloud Native Application Platforms de 2024, as empresas estão procurando uma experiência de plataforma única que ofereça suporte a vários tipos de aplicativos e padrões de implantação. Uma plataforma de aplicativo nativo da nuvem permite que você execute várias instâncias que podem ser atualizadas ou corrigidas enquanto outras instâncias estão em execução ou altere a camada do sistema operacional para algo em execução em um buildpack nativo da nuvem em produção.

Enxágue, repita e aprenda

Para realmente chegar a um estado de atualizações contínuas, existe o aspecto de “voltar à academia, mesmo quando estiver cansado e dolorido”. Mas depois de encontrar o treino certo para o seu estilo de vida, você o tornará parte regular da sua rotina. Ao trabalhar no processo de atualização, você descobrirá quais padrões funcionarão para sua organização, aprenderá como aproveitar melhor ferramentas como Open-Rewrite e criará receitas e suas próprias estruturas para ajudar a aplicá-las em escala.

Hoje, tudo está acontecendo mais rápido, com mais oportunidades para os malfeitores, mas também mais possibilidades e inovações para aproveitar. Portanto, não aposte seu negócio na forma como as coisas sempre foram feitas; comece a implementar pequenas mudanças hoje e trabalhe para construir sua própria cultura de atualizações contínuas.

A postagem Não durma com atualizações do código-fonte apareceu pela primeira vez em The New Stack.