Lidar com vários ambientes para vários projectos num único computador?

Vejamos um exemplo de um ambiente de trabalho típico numa software house. Tem alguns clientes que têm ambientes diferentes. Alguns preferem MySQL, outros preferem Postgres. Uma versão da sua aplicação precisa de Java 11, e outro Java 17. O frontend precisa do npm 12 ou 16 porque você usa versões diferentes do angular. Finalmente, tem aquele conjunto tridimensional que contém combinações de todas as suas versões de BD, backend e frontend. Parece mau, mas um dia o seu chefe diz...

Raízes de um ambiente multiverso

A situação descrita acima não é invulgar. A migração entre versões de línguas ou de estruturas, as actualizações de bases de dados ou simplesmente requisitos diferentes provenientes dos clientes podem virar do avesso todas as configurações. Devemos ter uma solução que ajude nós gerir essas mudanças, uma que corresponda a alguns pressupostos e/ou requisitos e/ou objectivos:

• fácil de utilizar - comando único para alterar uma configuração ou uma versão,
• biblioteca rica - deve suportar várias tecnologias e "coisas" (bibliotecas, estruturas, aplicações),
• extensível - deve oferecer a possibilidade de adicionar os seus plugins.

Neste artigo, centrar-me-ei em três áreas. A primeira são as ferramentas para Java e JVM. A segunda são as ferramentas de uso geral. A terceira é como usar doca para atingir os nossos objectivos.

​

Sou Java e trabalho na JVM

Quando se é um Programador Java ou, mais geralmente, trabalha com Tecnologias JVM, então pode utilizar SDKMAN!. Esta é uma ferramenta muito boa e fácil de utilizar que suporta muitas bibliotecas, estruturas e linguagens.

O processo de instalação do SDKMAN! É bastante simples. Tens de correr:

curl -s "https://get.sdkman.io" | bash

e depois

source "$HOME/.sdkman/bin/sdkman-init.sh"

Agora pode gerir os seus Java, Scala e Maven versões.

Gerir versões - exemplo

Neste exemplo, vamos instalar e atualizar a versão de algumas ferramentas. Este é apenas um pequeno subconjunto de ferramentas disponíveis.

Instalação

Vamos supor que o seu novo projeto utilizações Java 17. Não tem nenhum Java instalada. Pretende instalá-la e, além disso, adicionar uma ferramenta Maven Daemon para tornar as compilações mais rápidas. Portanto, também é necessário instalar o Maven. Para fazer isso, é necessário executar três comandos simples:

$ sdk install java 17-open

$ sdk install maven 3.8.4

$ sdk instalar mvnd 0.7.1

No final da instalação de cada ferramenta, ser-lhe-á perguntado se a quer tornar predefinida:

Deseja que Java 17-open seja definido como padrão? (Y/n):

Isto é importante quando instala uma nova versão de uma biblioteca ou de uma linguagem, porque o SDKMAN! irá definir essa versão predefinida como global para todos os terminais do utilizador atual.

Verificação de versões e atualização

De tempos a tempos, o SDKMAN! tem de atualizar os índices. Durante este processo, poderá receber uma mensagem a indicar que existem novas versões das ferramentas que utiliza. Podemos verificar quais versões estão disponíveis digitando sdk ls. Para sdk ls maven:

Versões disponíveis do Maven

================================================================================

    3.8.6 3.3.3

    3.8.5 3.3.1

3.8.4 3.2.5

    3.8.3 3.2.3

    3.8.2 3.2.2

    3.8.1 3.2.1

    3.6.3 3.1.1

    3.6.2 3.1.0

    3.6.1 3.0.5

    3.6.0 3.0.4

    3.5.4

    3.5.3

    3.5.2

    3.5.0

    3.3.9



================================================================================

versão local

atualmente em uso

================================================================================

Como podemos ver acima, o Maven tem uma versão mais recente do que a que utilizamos. O mesmo acontece com o mvnd (0.8.2) e Java (19-open). Vamos atualizar tudo. Para o fazer, só precisamos de chamar o comando install mas, desta vez, não utilizamos um especificador de versão:

$ sdk install maven

$ sdk instalar mvnd

$ sdk instalar java

Mas algo de errado aconteceu. Maven e mvnd têm versões corretas, mas Java tem versão 17.0.5-tem. Isso deve-se ao facto de a versão "mais recente" da ferramenta ser controlada pelo seu fornecedor e não pelo SDKMAN! quem é esse fornecedor? Um fornecedor no SDKMAN! é alguém que pode publicar uma versão. No entanto, digamos que finalmente instalamos 19-abertoe tornámo-la predefinida, mas por alguma razão, precisamos de utilizar 17-aberto.

Versões locais e gestão de versões por terminal

​
Podemos configurar um padrão versão de uma ferramenta que é global para todos os projectos e terminais. Mas quando precisamos de uma versão específica, temos duas formas de o fazer. A primeira é utilizar o sdk use sempre que quisermos usar uma versão específica de uma ferramenta no terminal atual. A segunda é preparar uma lista de versões em um .sdkmanrc que é armazenado com o projeto.

Enquanto a primeira opção se destina a uma única utilização, a segunda foi concebida para trabalhar com equipas e partilhar configurações entre equipa membros.

Prós e contras do SDKMAN!

O SDKMAN! é muito fácil de utilizar e possui uma biblioteca rica de ferramentas, estruturas e linguagens suportadas. Funciona em Linux, MacOS e Windows. Por outro lado, esta ferramenta está centrada na JVM e requer a aceitação do autor para ser um fornecedor. Além disso, a mecânica do .sdkmanrc é muito fraco e pode atrasar significativamente o processo de mudança de diretórios.

Gostaria de utilizar muitas outras línguas

Se precisar de utilizar muitas línguas e ferramentas, deve consultar asdf. Esta ferramenta está focada em ferramentas de "alto nível". Enquanto no SDKMAN! pode encontrar muitas ferramentas específicas de Java, como o Bpipe ou o Znai, o asdf oferece muito mais ferramentas, mas não tão específicas. Claro que algumas dessas ferramentas se sobrepõem, por exemplo, Java, Tomcat ou mvnd estão disponíveis em ambas.

Quando se pretende utilizar asdf, é necessário ter git e enrolar instalado. Depois disso, é só:

git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.10.2

e adicionar estas linhas em ~/.bashrc file:

. $HOME/.asdf/asdf.sh

. $HOME/.asdf/completions/asdf.bash

Agora pode instalar plugins e ferramentas nas suas versões favoritas.

Gestão baseada em plugins

Ao contrário do SDKMAN! asdf utiliza plugins para gerir ferramentas. Portanto, antes de instalar uma ferramenta, é necessário instalar um plug-in. Vamos voltar ao nosso projeto de exemplo e tentar configurar o ambiente usando asadfsdf.

Primeiro, precisamos de instalar os plug-ins:

asdf plugin add java

asdf plugin add maven

asdf plugin add mvnd

Depois podemos instalar as nossas ferramentas:

asdf install java openjdk-17

asdf install maven 3.8.4

asdf install mvnd 0.7.1

E, mais uma vez, ao contrário do SDKMAN! asdf não altera nada no nosso ambiente. Quando tentamos utilizar o java, recebemos uma mensagem de erro como:

Não está definida nenhuma versão para o comando Java

Considere adicionar uma das seguintes versões no seu ficheiro de configuração em ~/.tool-versions

java openjdk-17

Precisamos de criar o ficheiro .versões de ferramentas no diretório inicial para gerir as versões predefinidas.

Versões locais e globais

Atualização de versões de software com asdf é bastante simples. Basta instalar uma nova versão. Como este processo não afecta o ambiente, podemos fazê-lo em qualquer altura e em qualquer local do sistema de ficheiros. Quando queremos usar uma versão específica de algum software, precisamos criar no diretório do projeto um .versões de ferramentas que pode ser partilhado entre os membros da equipa. Não se esqueça de que tem de garantir que todos os membros da equipa têm asdf e os plugins instalados. A lista de plugins pode ser encontrada aqui.

Conflitos de versões

asdf não suporta apenas linguagens de programação, frameworks e ferramentas como vim ou kubernetess. Ele também suporta bancos de dados. Nesse caso, poderíamos instalar várias versões de, por exemplo, Postgres, mas apenas uma instância poderia ser executada. Isso deve-se ao facto de asdf executa comandos diretamente no seu sistema operativo sem qualquer camada de separação. Isso leva a problemas como "porta já em uso" e conflitos de recursos.

Prós e contras

asdf é uma ferramenta muito boa se quiser trabalhar num ambiente poliglota. Suporta muitas ferramentas, linguagens e estruturas. A arquitetura baseada em plug-ins facilita muito a sua extensão. No entanto, algumas das ferramentas que tem na biblioteca precisam de trabalho adicional durante a instalação para fornecer todas as dependências necessárias. asdf não funciona no Windows, mesmo em WSL.

Por último, mas não menos importante - Docker

Quando falo do conflito portuário acima, muitos de vós conhecem a solução.

Docker pode ajudar-nos em alguns casos. Menciono-o por dever de ofício, porque esta ferramenta é tão grande e complexa que não podemos discuti-la num só artigo.

Juntamente com o Docker, devemos usar um docker-compose ferramenta que nos dá a possibilidade de coordenar ambientes com vários contentores.

Prós e contras do Docker

O Docker ajuda-nos a gerir ferramentas que necessitam de alguns recursos específicos, como portas ou ficheiros. Separa as instâncias em contentores e dá-nos controlo total sobre elas. No entanto, o Docker é uma ferramenta que introduz muita complexidade ao nosso ambiente de trabalho e pode ser problemática em alguns casos. Um desses casos de uso do Docker em um teste é descrito em um dos nossos artigo.

Resumindo

Sei que não descrevi todas as ferramentas que podem ser utilizadas para gerir as versões das ferramentas. Existem muitas outras, tais como jEnv que poderia substituir o SDKMAN,

ou NVM que podemos usar para gerenciar o npm ou o RVM para Rubi. Concentrei-me em ferramentas que "testei no campo de batalha" e que posso recomendar a qualquer pessoa.