Muitas vezes aparece a dúvida sobre quando fazer o upgrade de uma versão do .NET.
Será que vale a pena pular de LTS em LTS ou vale a pena pegar as STS’s no meio do caminho?
Empresas burocráticas, devem mudar suas políticas ou não?
Hoje vamos tratar desse assunto, com os meus argumentos, mostrando as recomendações que faço mais ou menos desde 2017~2018.
Disclaimers
- Você é totalmente livre, para não concordar, para não seguir essa recomendação.
- Meu objetivo não é te convencer, nem te recomendar nada.
- Meu 1° objetivo é mostrar o que recomendo e por que recomendo.
- Meu 2° objetivo é parar de responder essa pergunta tendo de escrever em um chat, boa parte das vezes com uma grande limitação de caracteres.
Contexto
O primeiro ponto que preciso citar aqui é minha experiência com .NET. Desde a versão 1, lá em 2002, levei alguns meses ter a permissão para trabalhar com .NET, lá na Petrobras, em 2003.
Desde então NUNCA abandonei o .NET.
Estive presente e usei absolutamente todas as versões do .NET sem pular nenhuma, isso desde 2003 até hoje.
Já conduzi ao menos 2 centenas de migrações de projetos pessoais, e muitas migrações em projetos de clientes, acredito que mais de 500 projetos, em ao menos umas 50 solutions.
SemVer
Para ficar claro como podemos ver SemVer aqui no .NET, vamos pegar a versão mais recente do .NET instalada no meu desktop hoje, no dia em que escrevo esse post:
Então a versão mais recente é a versão 8.0.300-preview.24203.14 que se apresenta como na tabela abaixo:
| MAJOR | MINOR | PATCH | BUILD |
|---|---|---|---|
| 8 | 0 | 300 | preview.24203.14 |
O que esperar quando uma versão muda?
MAJOR
Sempre que temos uma MAJOR nova, temos mais impacto, temos breaking changes, mudanças que demandam algum tipo de reescrita de código.
MINOR
Sempre que temos uma MINOR nova, temos um impacto menor, sem breaking changes, em geral, estamos falando da adição de features.
PATCH
Sempre que temos um PATCH novo, temos uma correção. De qualquer natureza. Seja um bug, uma correção de segurança, algo que resolve qualquer tipo de problema sem adicionar recursos novos.
BUILD
O build é um um número não relacionado aos demais, ele caminha isolado. É usado internamente para determinar qual build gerou uma determinada versão.
Se quisermos identificar qual versão dos fontes foram usados, voltar à pipeline de CI/CD, e encontrar essa task com o ID do build. Olhando os logs encontraremos exatamente qual versão do repositório de fontes foi usada para gerar aqueles artefatos.
A Microsoft usa essa abordagem há muitos anos.
O ciclo de vida do .NET
No passado, na época do .NET Framework a Microsoft possuia um ciclo de releases que parecia mais moderado aos olhos desatentos.
| Versão | CLR | Release Date |
|---|---|---|
| 1.0 | 1.0 | Jan/2002 |
| 1.1 | 1.1 | Abr/2003 |
| 2.0 | 2.0 | Out/2005 |
| 3.0 | 2.0 | Nov/2006 |
| 3.5 | 2.0 | Nov/2007 |
| 4.0 | 4.0 | Ago/2010 |
| 4.5 | 4.0 | Ago/2008 |
| 4.5.1 | 4.0 | Out/2013 |
| 4.5.2 | 4.0 | Mai/2014 |
| 4.6 | 4.0 | Jul/2015 |
| 4.6.1 | 4.0 | Nov/2015 |
| 4.6.2 | 4.0 | Ago/2016 |
| 4.7 | 4.0 | Abr/2017 |
| 4.7.1 | 4.0 | Out/2017 |
| 4.7.2 | 4.0 | Abr/2018 |
| 4.8 | 4.0 | Abr/2019 |
| 4.8.1 | 4.0 | Ago/2022 |
Note que embora o ciclo de releases seja elevado, o ciclo de novas CLR’s é muito baixo, se mantendo o mesmo desde 2010.
Em agosto completamos 14 anos com a mesma CLR no .NET Framework.
E qual o impacto disso? Baixa evolução.
Toda mudança que não gere mudança na CLR é incremental, novas bibliotecas, novas recursos, mas sob uma mesma baseline. Sobre um mesmo core.
O .NET Framework é um ambiente de execução de runtime que gerencia os aplicativos destinados ao .NET Framework. Ele consiste no Common Language Runtime, que fornece gerenciamento de memória e outros serviços do sistema, além de em uma biblioteca de classes extensa, o que permite que programadores usem o código robusto e confiável para todas as áreas principais do desenvolvimento de aplicativos.
Introdução ao .NET Framework
Em linhas gerais, as grandes mudança ocorrem quando você mudava de versão da CLR, as demais mudanças eram incrementais e retrocompatíveis. Ou seja, o nível de impacto era muito baixo, embora sempre fosse necessário instalar uma nova versão do .NET.
Essas versões intermediárias traziam novos recursos, com zero ou quase zero impacto para os aquilo que já funcionava.
Outro aspecto importante, principalmente na era do Windows Server e do IIS, era a compatibilidade. Na mesma CLR tínhamos baixíssimos conflitos, mas manter 2 CLR’s simultaneamente no mesmo servidor sempre trouxe necessidade de cuidados especiais, principalmente na precedência da instalação do .NET e cuidados relativos à chamadas ao aspnet_regiis.exe para configurar o IIS com a versão desejada.
Outro cuidado necessário nessa época pré-containers, é a necessidade de isolar Application Pools do IIS por versão do .NET.
Hoje nada disso é necessário com .NET Core, principalmente com o Kestrel embarcado no .NET.
Com o uso massivo de containers, não temos mais conflitos entre versões do .NET, já que todo o grafo de dependências é resolvido dentro do container, com componentes que já vieram embarcados na imagem, isso faz com que possamos ter 10 versões diferentes sem que nenhuma afete as demais.
Mas antes dos containers, sempre foi tenso!
A era do .NET Core e nova visão da Microsoft
Embora a lista de releases possa ser intensa, como demonstrado na tabela do tópico anterior, e talvez tão intensa quanto hoje, a gente nunca sentia tanto impacto como sentimos hoje.
As mudanças de major nas releases do .NET Core fizeram com que tivéssemos mais retrabalho do que tínhamos no passado, com .NET Framework.
Isso porque, na prática, no passado só era preocupante e só demandava mais esforço para compatibilizar código, quando mudávamos de versão da CLR.
Aliás, se olharmos com certo cuidado, veremos que as mudanças de CLR coincidem com mudanças de MAJOR versions, portanto podemos dizer a única mudança, nesses mais de 20 anos, é a frequência com que MAJOR versions são lançadas, entretanto a frequência com que releases são disponibilizadas, se manteve.
| Versão | Release Date |
|---|---|
| .NET Core 1.0 | Jun/2016 |
| .NET Core 1.1 | Nov/2016 |
| .NET Core 2.0 | Ago/2017 |
| .NET Core 2.1 | Mai/2018 |
| .NET Core 2.2 | Dez/2018 |
| .NET Core 3.0 | Set/2019 |
| .NET Core 3.1 | Dez/2019 |
| .NET 5 | Nov/2020 |
| .NET 6 | Nov/2021 |
| .NET 7 | Nov/2022 |
| .NET 8 | Nov/2023 |
| .NET 9 | Nov/2024 (projected) |
| .NET 10 | Nov/2025 (projected) |
Então, a preocupação sobre mudanças quando uma major é lançada, não muda, entretanto a frequência com que major versions são lançadas mudou.
Afinal, quando migrar?
Eu aqui estou considerando:
- Pequenos projetos
- Projetos grandes
- Empresas cuja burocracia é grande, como bancos e instituições financeiras em geral.
- SMB’s (pequenos e médios negócios)
- Free Lancers e profissionais liberais
- Empresas que cultuam o pensamento: Se está funcionando não mexa.
Minha recomendação é não pular nenhuma release.
Isso quer dizer, necessariamente, realizar migrações de tudo 1 vez por ano.
Migrar projetos deve ser uma tarefa anual, acontecendo em uma janela muito específica:
- De: 3 meses depois do lançamento de uma nova release
- Até: 3 meses antes do lançamento de uma nova release
Como podemos, desde 2018, ter como base novembro para o lançamento de novas releases do .NET, podemos considerar que todo projeto deve ser migrado entre março e agosto (6 meses).
| JAN | FEV | MAR | ABR | MAI | JUN | JUL | AGO | SET | OUT | NOV | DEZ |
|---|---|---|---|---|---|---|---|---|---|---|---|
| X | X | X | X | X | X | Release |
Durante esse período, há abundância de conteúdo que auxilie nessa migração. Nessa janela, a migração é menos hostil, ao contrário, é fácil, é dócil, e tende a ser uma jornada muito tranquila.
De um lado você está migrando apenas da versão anterior para a nova, sem grandes saltos. Isso facilita a migração e tona mais suave.
Em contrapartida, ao se aproximar da nova release, uma enxurrada de posts e lançamentos começam a atrapalhar a jornada.
Mas se não conseguiu realizar dentro de uma janela, pule para a próxima.
Custos e Questões
Sim, está claro que temos um custo aumentado com essa decisão, entretanto manter aplicações em versões legadas, dificulta todo o ciclo de vida da aplicação e potencializa a chance da aplicação ser considerada legado, bem cedo.
Isso quer dizer que parte da longevidade de uma aplicação diz respeito às suas tecnologias e à idade delas.
Quanto mais atual, menor o ímpeto em se reconstruir tudo do zero.
Ademais, estamos cuidado para que argumentos como:
- “Na versão atual não há como resolver isso sem xpto, mas não podemos usar”
- “Já criaram uma solução para isso, mas não podemos usar”
Os argumentos que demandariam refatoração, somente nos momentos críticos onde não se é mais possível realizar uma tarefa por conta da versão antiga, deixam de existir.
Um dos principais motivadores para quererem jogar uma aplicação no lixo e reescrever do zero, são resolvidos.
Então, embora pouco tangível, é minha abordagem e minha recomendação clara e límpida.
Outra característica importante é que o esforço de migração é substancialmente reduzido na medida que é feito nessa janela. Isso porque temos abundância de conteúdo e diluímos a complexidade na medida que não acumulamos migrações.
Conclusão
Fazer esse tipo de migração anualmente tem muito potencial para reduzir os custos no médio prazo. Além de tornar o produto ou projeto um ativo e diferencial na hora de ofertar vagas, já que poderá falar sobre estar nas últimas versões de uma tecnologia.
A redução do escopo de migração é substancial, principalmente pela abundância de soluções e recomendações.
Temos como benefício a diluição dos riscos, pois com menor escopo, temos menor superfície de migração.
Assim, para quem seguir essa recomendação, comente aqui, eu quero ver suas impressões ao longo do tempo.
Um ponto importante na atualização continua planejada é quanto a segurança. Os pacotes recebem correções ao serem notificados/identificado. Mas há mais, bugs, performance e suporte podem explodir ainda mais as preocupações quanto a atualização.
Vale lembrar que o mercado acaba exigindo mais e mais, profissionais se qualificam com as mais modernas possíveis, e problemas do passado em implementações passam a ser um estorvo na vida do codificador que busca uma linha de trabalho conhecida, eficaz e rotineira.
Atualizações constantes garante menor impacto as de mais longo prazo, também terão menor custo e risco.
É importante ter um calendário estratégico onde garanta a maturidade da atualização e possibilidade de testes de garantia.