Escolhendo Versões de Software para Implantação

Algo que vejo ser discutido com muita frequência nos círculos de TI é “qual versão de software devo instalar”. Isso pode se aplicar a um banco de dados, a uma aplicação, a um firmware ou, provavelmente com mais frequência, a sistemas operacionais e, com o iminente fim do ciclo de suporte do Windows XP, o tema atingiu um nível febril.

Existem, na prática, dois lados nessa discussão. Um lado acredita que o software mais recente e, presumivelmente, melhor deve sempre ser usado. O outro acredita que o software precisa amadurecer e adota uma abordagem de “esperar para ver”, ou até considera cada versão como um produto diferente, e não como um contínuo de desenvolvimento.

Ambas as abordagens têm seus méritos, e nenhuma deveria existir completamente sem a outra. Atualizar software cegamente, a esmo, não é prudente, e evitar correções e atualizações sem motivo também não é prudente. A consideração cuidadosa dos fatores e a empatia pelo processo de desenvolvimento de software são importantes de se ter em mente ao tomar essas decisões.

Primeiro, há dois cenários completamente diferentes a considerar. Um é a atualização do software atual, já existente. O pressuposto é que o estado atual das coisas está “funcionando”, com a possibilidade aceita de que “funcionando” possa incluir uma exposição de segurança que foi descoberta e que exige atualização para ser fechada. O outro cenário é uma nova implantação, em que não há nada no momento e estamos começando do zero.

Vamos começar pelo segundo caso, por ser muito mais fácil fornecer orientação a respeito dele.

No caso de novas implantações de software (ou de novos sistemas operacionais), use sempre a versão atual, mais recente, do software, a menos que haja uma limitação tecnológica claramente conhecida que o impeça ?? como bugs conhecidos ou incompatibilidades de software.

Software não é como outros tipos de produtos, especialmente não no mundo atual de lançamentos de correções e atualizações online. Presumo que a mentalidade de que versões antigas de software possam ser preferíveis às atuais venha de uma combinação de produtos físicos (relógios, carros, louças, móveis, vinho), em que um ano ou modelo específico pode ser superior a um modelo mais novo por várias razões, e de modos legados de entrega de software, em que produtos de software finalizados eram simplesmente ??jogados por cima do muro? e o estado final era, muito simplesmente, o estado final, sem quaisquer oportunidades razoáveis de atualizações, correções ou consertos. Nenhum desses casos se aplica ao software empresarial moderno (com apenas as mais raras exceções).

O desenvolvimento de software é, grosso modo, um contínuo. Os processos normais de desenvolvimento fazem com que o novo software seja construído sobre o software antigo, seja diretamente (criando atualizações para uma base de código existente) ou indiretamente (reconstruindo com base no conhecimento adquirido ao ter construído uma versão anterior do software). A ideia é que cada versão subsequente do software seja superior à que a precede. Isso não é garantido, claro; existem conceitos como erros de regressão e simplesmente mau desenvolvimento, mas, de modo geral, o software melhora com o tempo – especialmente quando falamos de software de classe empresarial usado em empresas e sob desenvolvimento ativo. O novo software não é apenas a próxima fase do software antigo; ele também representa, em quase todos os casos, o estado atual de correções, consertos de bugs, atualizações e, quando necessário, mudanças de abordagem ou técnica. O novo software, vindo de fábricas de qualidade, é quase exclusivamente melhor do que o software antigo. O software evolui e amadurece.

Além da qualidade do software em si, há o conceito de investir no futuro. Software não é algo que possa ficar na prateleira para sempre. Ele precisa permanecer, em certa medida, atualizado, ou para de funcionar porque a plataforma sobre a qual roda muda, algum novo artefato vem à tona, falhas de segurança são descobertas ou as necessidades mudam. Instalar software antigo significa que há um investimento no passado, um investimento em instalar, aprender, usar e dar suporte a tecnologia antiga. Isso se chama “dívida técnica”. Essa tecnologia antiga pode durar anos ou até décadas, mas o software antigo perde valor com o tempo e se torna cada vez mais caro de manter, tanto para os fornecedores, se continuarem a dar suporte a ele, quanto para os usuários finais, que precisam mantê-lo.

O mesmo conceito de dívida técnica se aplica aos fornecedores de software em questão. Há um custo muito grande na criação de software e, especialmente, na manutenção de múltiplas versões desse software. Os fornecedores de software têm muito incentivo para reduzir o suporte a versões mais antigas a fim de concentrar recursos nos lançamentos de software atuais (esta é uma das principais razões pelas quais as implantações de SaaS são tão populares: o fornecedor controla as versões disponíveis e pode eliminar versões legadas por meio de atualizações). Se os clientes exigem suporte para versões antigas, o custo precisa ser absorvido em algum lugar, e muitas vezes é absorvido tanto em impacto monetário para todos os clientes quanto em uma diminuição do foco no novo produto, pois as equipes de desenvolvimento precisam se dividir para dar suporte à correção de versões antigas, além de desenvolver a nova. Quanto mais esforço precisa ser dedicado a versões antigas, menos esforço pode ser empregado em novas melhorias.

Dentro do contexto do que já disse, é importante falar sobre maturidade de código. Frequentemente, a maturidade do código é apontada como razão para implantar “código antigo”, mas penso que isso é um mal-entendido de TI sobre os processos de desenvolvimento de software. Se pensarmos em uma linha de código lançada, só porque ela está lançada e em uso não a torna realmente mais madura. O código não muda quando está “solto no mundo”; ele apenas permanece ali. Sua maturidade fica “congelada” no dia em que é lançado. Se for corrigido, então sim, ele “amadureceria” após o lançamento. Versões posteriores do mesmo software, baseadas na mesma base de código, porém mais atualizadas, são, na verdade, o código mais “maduro”, pois foram revisadas, atualizadas, testadas, etc., em maior grau do que o lançamento inicial do mesmo código.

Isso é contraintuitivo em relação a, digamos, um carro, em que cada lançamento é algo novo, com novas oportunidades de problemas mecânicos e diferentes preocupações de confiabilidade – em que esperar alguns anos lhe dá a chance de ver quais problemas de confiabilidade são descobertos. O software não é assim. Portanto, o conceito de querer um software mais maduro o empurraria a implantar o “mais recente e melhor”, em vez do “consagrado e testado”.

Se pensarmos nos números de versão do software como se fossem idades, isso fica claro. O Linux 3.1 é muito mais antigo, em termos de amadurecimento de software, do que o Linux 2.4. Ele tem uma década adicional de desenvolvimento.

Vamos usar um exemplo do mundo real que é muito relevante hoje. Você está em uma empresa prestes a instalar seu(s) primeiro(s) servidor(es). O Windows Server 2012 R2 acabou de ser lançado. Você deveria instalar o Windows Server 2008, o 2008 R2 (2010), o Server 2012 ou o Server 2012 R2 (final de 2013)?

Para muitas empresas, isso soa como se estivéssemos falando de algo entre dois e quatro produtos inteiramente diferentes, que provavelmente teriam razões distintas para a escolha de cada um. Isso, em grande parte, é falso. Cada versão mais nova é simplesmente uma atualização, um aprimoramento, uma correção e um acréscimo de recursos em relação à anterior. Cada uma, por sua vez, é mais avançada e madura do que a que a precede. Cada nova versão se beneficia do trabalho feito no lançamento original de sua antecessora, bem como das correções de bugs, dos patches e dos acréscimos de recursos realizados no intervalo entre o lançamento original e o lançamento sucessor. Cada novo lançamento é, na realidade, um “lançamento secundário” do anterior. Se observarmos os números de revisão do kernel, em vez dos nomes de marketing dos lançamentos, talvez faça mais sentido.

O Windows Server 2008 era o Windows NT 6.0. O Windows Server 2008 R2 era o Windows NT 6.1, obviamente uma revisão secundária ou até um “patch” do lançamento anterior. O Windows Server 2012 era o Windows NT 6.2, e nosso atual Windows Server 2012 R2 é o Windows NT 6.3. Se usássemos os números de revisão em vez dos nomes de marketing, soaria quase insano instalar intencionalmente uma versão antiga, menos madura, menos atualizada e menos corrigida. Queremos as atualizações mais recentes, as correções de bugs mais recentes e que os problemas de segurança mais recentes tenham sido tratados.

Para novas implantações de software, quanto mais novo o software instalado, melhor a oportunidade de aproveitar os recursos mais recentes e maior o tempo até que a inevitável obsolescência cobre seu preço. Todo software envelhece, então instalar software mais novo oferece a melhor chance de que esse software dure o maior tempo possível. Isso proporciona a melhor flexibilidade para o futuro desconhecido.

Seguir essa linha de raciocínio poderia nos levar a sentir que implantar software pré-lançamento ou até beta também faria sentido. E, embora possa haver casos específicos em que isso faça sentido, como em “grupos de teste” para avaliar um software antes de liberá-lo para a empresa como um todo, em geral não faz. A natureza do software pré-lançamento é que ele não tem suporte e pode conter código que nunca terá. Usar tal código de forma isolada pode ser benéfico, mas para uso geral não é aconselhável. Existem processos importantes que são seguidos entre os lançamentos de prévia ou beta e os lançamentos finais de código, não importa em que nível de maturidade o produto como um todo se encontre.

Isso nos traz à outra situação, aquela em que estamos atualizando software existente. Esse, claro, é um cenário completamente diferente de uma instalação nova, e há muitos, muitos mais fatores envolvidos.

Um dos maiores fatores na maioria das situações é o do licenciamento. Atualizar software regularmente pode incorrer em taxas de licenciamento que precisam ser consideradas na equação de benefícios e custos. Alguns produtos, como a maioria dos softwares de código aberto, não têm esse custo e podem ser atualizados assim que novas versões estiverem disponíveis.

O outro fator realmente grande na atualização de software é o custo do esforço humano para atualizar – ao contrário de uma instalação nova, em que o esforço de instalação é, na prática, equivalente entre software antigo e novo. Na realidade, o software novo tende a ser mais fácil de instalar do que o antigo, simplesmente devido a melhorias e avanços. Manter uma única versão de software por uma década significa que recursos não foram dedicados, durante esse tempo, a processos de atualização. Atualizar anualmente durante esse período significa que recursos foram usados dez vezes para realizar atualizações separadas. Isso torna a atualização muito mais difícil de justificar em termos de custo. Mas há mais do que apenas o esforço do próprio processo de atualização; há também o treinamento contínuo necessário para os usuários finais, que serão forçados a vivenciar mais mudanças, com mais frequência, por meio de atualizações constantes.

Isso pode fazer a atualização de software soar como algo negativo, mas não é. É simplesmente uma equação em que cada lado precisa ser ponderado. Atualizações regulares frequentemente significam mudanças pequenas e incrementais, em vez de grandes saltos, permitindo que os usuários finais se adaptem de forma mais natural. Atualizações regulares significam que os processos de atualização são frequentemente mais fáceis e previsíveis. Atualizações regulares significam que a dívida técnica está sempre gerenciada e que os benefícios das versões mais novas — que podem ser recursos, eficiências ou melhorias de segurança — estão disponíveis mais cedo, permitindo que sejam aproveitados por um período mais longo.

Tomando o que aprendemos com os dois cenários acima, no entanto, há outra conclusão importante a ser encontrada aqui. Uma vez tomada a decisão de realizar uma atualização, a pergunta frequentemente é “para qual versão atualizamos?”. Na realidade, porém, toda atualização que vá além de um processo padrão de aplicação de correções é, na verdade, como uma miniatura de uma decisão de compra de “software novo”, e a lógica do porquê “sempre” instalamos a versão mais recente disponível ao fazer uma instalação nova também se aplica aqui. Então, ao realizar uma atualização, quase sempre deveríamos atualizar tanto quanto pudermos – com sorte, para a versão atual.

Para aplicar o exemplo da Microsoft novamente, podemos considerar uma organização que tem o Windows XP implantado hoje. A empresa decide investir em um ciclo de atualização para uma versão mais nova, não apenas na aplicação contínua de correções. Existem várias versões da plataforma desktop do Windows que ainda estão sob suporte ativo da Microsoft. Estas incluem o Windows Vista, o Windows 7, o Windows 8 e o Windows 8.1. Atualizar para uma das versões menos atuais resulta em menos tempo até o fim da vida útil dessa versão, o que aumenta o risco organizacional; usar versões mais antigas significa investimento contínuo em tecnologias já antigas, o que significa um aumento da dívida técnica e menos acesso a novos recursos que podem se mostrar benéficos quando disponíveis. Neste exemplo específico, as versões mais novas também são consideradas mais seguras e exigem menos recursos de hardware.

Toda empresa precisa encontrar o equilíbrio certo para si nos ciclos de atualização de software existente. Toda empresa e todo pacote de software são diferentes. Softwares empresariais como o Microsoft Windows, o Microsoft Office ou um banco de dados Oracle seguem muito bem esses modelos. Pequenos projetos de software e aqueles que se aproximam da faixa sob medida podem ter um ciclo de lançamento mais dinâmico e imprevisível, mas geralmente ainda seguirão a maioria dessas regras. Considere aplicar empatia ao processo de desenvolvimento de software para entender como você e seu fornecedor de software podem firmar a melhor parceria para entregar o maior valor à sua organização, e combine isso com sua necessidade de reduzir a dívida técnica para aproveitar seu investimento em software da melhor maneira possível para a sua organização.

Mas as regras práticas são relativamente simples:

Ao implantar de forma nova ou atualizar, busque a versão razoável mais recente do software. Use qualquer oportunidade de implantação para eliminar a dívida técnica tanto quanto possível.

Quando o software já existe, pondere fatores como esforço humano, custos de licenciamento, consistência do ambiente e testes de compatibilidade contra os benefícios em recursos, desempenho e dívida técnica.