Índice:

Mantendo constância na atualização do projeto

Índice:

Uma rotina simples te ajudará a não procrastinar e deixar seus projetos desatualizados.

Introdução

É muito comum deixarmos de atualizar as dependências de um projeto, ou fazer isso com intervalos de tempos muito grandes, onde há tantos pacotes e bibliotecas para se atualizar, com inúmeras breakings changes acumuladas, que às vezes chega a compensar fazer o projeto de novo. 

Acredito que, em algum momento da sua vida, você enfrentou ou enfrentará alguma situação parecida.

Para evitar que isso aconteça, neste artigo vamos ver uma rotina simples e eficaz que te ajudará a manter todos os projetos devidamente atualizados.

Entendendo os níveis de migrações

Temos três tipos de atualizações:

  • Major: Quando há uma grande atualização do projeto, e consequentemente traz algumas breaking changes
  • Minor: Quando há uma atualização do projeto ou implementação de uma feature, mas não necessariamente afeta o código atual
  • Patches: Quando há a correção de algum bug, ou uma pequena melhoria de alguma feature já existente

Lembrando que breaking changes são alterações que, quando feitas, alteram a forma de implementação atual da biblioteca. E, ao atualizar, quebra o funcionamento do código antigo.

Yarn upgrade-interactive

Existe uma ferramenta muito interessante no yarn, que é o upgrade-interactive, onde ele verifica o seu package.json e mostra todas as modificações possíveis a serem feitas, e quais os tipos de cada atualização do projeto.

Rodamos o seguinte comando no nosso projeto:

yarn upgrade-interactive --latest --exact

Onde o comando “—latest” indica para o yarn pesquisar a última versão de cada pacote, e “—exact” indica para ele travar a versão que será atualizada.

O output será esse:

Como podemos ver, existem os três tipos de migrações que comentamos e você pode selecionar as que você deseja atualizar.

OBS: Se você utiliza o npm, ele não possui uma ferramenta nativa como essa do yarn, e você terá que utilizar uma outra dependência para realizar algo parecido, como o npm-check.

Rotina simples de atualização

Um dos maiores problemas na atualização de projetos é justamente o “deixar para depois”. Isso porque o número de major versions se torna tão grande que, quando atualizadas, quebram todo o código do projeto a ponto de não compensar nem alterar e você ter que fazer tudo de novo.

Então, uma rotina simples e importante de ser feita, é verificar periodicamente em cada projeto da sua empresa, seja a cada 15 dias ou uma vez por mês, se há ou não atualizações.

Testes servem para alguma coisa?

Lembra-se de quando pensamos em fazer ou não diversos testes e quais são a sua utilidade? Pois então, sem eles, como vamos verificar se o nosso projeto continua funcionando depois de atualizar as suas dependências? Vamos rodar o projeto e ficar clicando e olhando se todas as páginas estão funcionando de maneira certa? Vamos executar todas as requisições de api possíveis do nosso backend? 

Já pensou no trabalho que seria fazer isso toda vez que atualizamos uma dependência? Por isso, mais uma vez, conseguimos entender o porquê de os testes serem tão importantes. E mesmo que na hora não pareça, precisamos nos lembrar que um projeto não é só “para aquela hora”, um projeto é para a vida inteira muitas vezes.

Por isso, você deve pensar em todas as etapas, incluindo a manutenção futura, que pode garantir de maneira muito simples, ao atualizar nossas dependências e simplesmente rodar os nossos testes.

A atualização faz parte do projeto?

Claro que sim! Um dos grandes males que startups, pequenas e médias empresas podem cometer, é aquele fomo de mil e um MVPs, que se tornam inúmeros projetos e que dentro do tempo da equipe, só existe tempo para novos projetos.

O que fatalmente vai acontecer, é que chegará o momento em que ao tentar dar manutenção e usar qualquer feature mais atual em um projeto antigo, eles simplesmente começarão a explodir de tantas inconsistências e incompatibilidades.

Então, como um bom gerente de projetos ou uma pessoa consciente de sua equipe, incentive sua equipe a criar uma cultura onde os projetos nunca terminam e que sempre precisam ser atualizados. Pode parecer que com um ou dois projetos isso não é um problema, mas quando você menos esperar, já tem cinco, seis e sete rodando ao mesmo tempo e, é claro, eles sempre resolvem quebrar todos juntos de uma vez.

E qual a melhor forma de atualizar?

Com certeza as major versions são as mais trabalhosas, mas uma dica simples e eficaz, é começar pelo mais fácil.

Crie um branch do seu projeto, atualize todas os patches versions, verifique e rode os testes. Se estiver tudo ok, comite e passe para as minor versions. Repita o processo e, se estiver tudo certo, comite.

Por fim, faça o mesmo processo com as majors. O ideal é que você leia a documentação do que está sendo feito nas majors (sempre há um guia de migração) e é importante entender se as melhorias podem ser utilizadas no projeto. Então, o ideal é atualizar e testar uma por uma das major versions.

Conclusão

Como vocês podem ver, atualizar um projeto não é nada de outro mundo, mas apenas uma rotina simples que pode evitar que você acabe entrando em pânico por que tudo quebrou, e ter que reescrever seu código inteiro. Obviamente, atualizar major versions não é necessariamente simples e, às vezes, vai dar um pouco de trabalho, mas não quer dizer que não deve ser feito. 

Afinal, não adianta adiar o inadiável.

Publicado por:
Compartilhe:

Posts relacionados

entrega de software

No atual cenário de desenvolvimento de software, a pressão por eficiência e velocidade de entrega nunca foi tão intensa. Empresas de todos os tamanhos estão buscando maneiras de acelerar o

Estimativas de projetos de software

Quando falamos em gestão de um time de engenharia de software, os principais desafios que vem à cabeça são como estimar as atividades, e como lidar com as expectativas dos

Introdução ao Shape-up

Se você trabalha na área de engenharia de software, e se interessa por gestão de projetos, com certeza já deve ter ouvido falar na metodologia Shape-up ou no produto desenvolvido