window.pipedriveLeadboosterConfig = { base: 'leadbooster-chat.pipedrive.com', companyId: 11580370, playbookUuid: '22236db1-6d50-40c4-b48f-8b11262155be', versión: 2, } ;(function () { var w = window if (w.LeadBooster) { console.warn('LeadBooster ya existe') } else { w.LeadBooster = { q: [], on: function (n, h) { this.q.push({ t: 'o', n: n, h: h }) }, trigger: function (n) { this.q.push({ t: 't', n: n }) }, } } })() ¿Manejar múltiples entornos para múltiples proyectos en una sola máquina? - The Codest
The Codest
  • Quiénes somos
  • Servicios
    • Desarrollo de software
      • Desarrollo Frontend
      • Desarrollo backend
    • Staff Augmentation
      • Desarrolladores frontales
      • Desarrolladores de backend
      • Ingenieros de datos
      • Ingenieros de la nube
      • Ingenieros de control de calidad
      • Otros
    • Asesoramiento
      • Auditoría y consultoría
  • Industrias
    • Fintech y Banca
    • E-commerce
    • Adtech
    • Tecnología sanitaria
    • Fabricación
    • Logística
    • Automoción
    • IOT
  • Valor para
    • CEO
    • CTO
    • Gestor de entregas
  • Nuestro equipo
  • Case Studies
  • Saber cómo
    • Blog
    • Meetups
    • Seminarios en línea
    • Recursos
Carreras profesionales Póngase en contacto
  • Quiénes somos
  • Servicios
    • Desarrollo de software
      • Desarrollo Frontend
      • Desarrollo backend
    • Staff Augmentation
      • Desarrolladores frontales
      • Desarrolladores de backend
      • Ingenieros de datos
      • Ingenieros de la nube
      • Ingenieros de control de calidad
      • Otros
    • Asesoramiento
      • Auditoría y consultoría
  • Valor para
    • CEO
    • CTO
    • Gestor de entregas
  • Nuestro equipo
  • Case Studies
  • Saber cómo
    • Blog
    • Meetups
    • Seminarios en línea
    • Recursos
Carreras profesionales Póngase en contacto
Flecha atrás VOLVER
2022-12-01
Desarrollo de software

¿Manejar varios entornos para varios proyectos en una sola máquina?

Bartłomiej Kuczyński

Hay un medio de oro para manejar muchos entornos para un gran número en una sola máquina? ¡Nuestro experto en Java Bartłomiej conoce la respuesta!

Echemos un vistazo a un entorno de trabajo típico en un empresa de software. Tiene varios clientes con entornos diferentes. Algunos prefieren MySQL, otros Postgres. Una versión de su aplicación necesita Java 11, y otra Java 17. Frontend necesita npm 12 o 16 porque utiliza diferentes versiones de angular. Finalmente, tienes ese array tridimensional que contiene combinaciones de todas tus DBs, backend, y versiones frontend. Suena mal, pero un día tu jefe dice...

cómics<em>con</em>jefe

Raíces de un entorno multiversal

La situación descrita anteriormente no es algo infrecuente. Migraciones entre versiones de lenguajes o frameworks, actualizaciones de bases de datos o simplemente diferentes requerimientos provenientes de los clientes pueden poner patas arriba todas las configuraciones. Deberíamos tener una solución que nos ayude a gestionar esos cambios, una que se ajuste a unos supuestos y/o requisitos y/o objetivos:

  • fácil de usar - comando único para cambiar una configuración o una versión,
  • rica biblioteca - debe ser compatible con múltiples tecnologías y "cosas" (bibliotecas, marcos de trabajo, aplicaciones),
  • extensible - debería ofrecer la posibilidad de añadir sus plugins.

En este artículo, me centraré en tres áreas. La primera son las herramientas para Java y JVM. La segunda son las herramientas de propósito general. La tercera es cómo utilizar docker para lograr nuestros objetivos.

​

Soy Java y trabajo en JVM

Cuando eres un Desarrollador Java o, de forma más general, trabaja con Tecnologías JVMpuede utilizar ¡SDKMAN!. Se trata de una herramienta muy agradable y fácil de usar que admite muchas bibliotecas, marcos de trabajo y lenguajes.

El proceso de instalación de ¡SDKMAN! Es bastante sencillo. Tienes que correr:

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

y luego

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

Ahora puedes gestionar tu Java, Scala y Maven versiones.

Gestión de versiones - ejemplo

En este ejemplo, instalaremos y actualizaremos la versión de unas pocas herramientas. Esto es sólo un pequeño subconjunto de las herramientas disponibles.

Instalación

Supongamos que su nuevo proyecto utiliza Java 17. Usted no tiene ningún Java instalada. Quieres instalarla y, además, añadir una herramienta Maven Daemon para hacer las construcciones más rápidas. Por lo tanto, es necesario instalar Maven, también. Para ello, es necesario ejecutar tres comandos simples:

$ sdk install java 17-open

$ sdk install maven 3.8.4

$ sdk install mvnd 0.7.1

Al final de la instalación de cada herramienta, se le preguntará si desea convertirla en predeterminada:

¿Desea que Java 17-open se establezca como predeterminado? (S/n):

Esto es importante cuando se instala una nueva versión de una librería o de un lenguaje, ya que SDKMAN! establecerá esa versión por defecto como global para todos los terminales del usuario actual.

Comprobación de versiones y actualización

De vez en cuando, SDKMAN! necesita actualizar los índices. Durante este proceso, es posible que reciba un mensaje indicándole que hay nuevas versiones de las herramientas que utiliza. Podemos comprobar qué versiones están disponibles escribiendo sdk ls. Para sdk ls maven:

Versiones disponibles de 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



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

versión local

actualmente en uso

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

Como vemos arriba, Maven tiene una versión más nueva que la que usamos. Lo mismo ocurre con mvnd (0.8.2) y Java (19-open). Vamos a actualizarlo todo. Para ello, sólo tenemos que llamar al comando install pero en esta ocasión, no utilizamos un especificador de versión:

$ sdk install maven

$ sdk install mvnd

$ sdk install java

Pero algo malo ocurrió. Maven y mvnd tienen versiones correctas, pero Java tiene versión 17.0.5-tem. Esto se debe a que "la versión más reciente" de la herramienta está controlada por su proveedor y no por SDKMAN! ¿Quién es este proveedor? Un vendedor en SDKMAN! es alguien que puede publicar una versión. Sin embargo, digamos que finalmente instalamos 19-abiertoy lo hicimos por defecto, pero por alguna razón, necesitamos usar 17-abierto.

Versiones locales y gestión de versiones por terminal

​
Podemos configurar un por defecto versión de una herramienta que es global para todos los proyectos y terminales. Pero cuando necesitamos una versión específica, tenemos dos formas de hacerlo. La primera es utilizar el sdk use cada vez que queramos utilizar una versión específica de una herramienta en el terminal actual. La segunda es preparar una lista de versiones en un .sdkmanrc que se almacena con el proyecto.

Mientras que la primera opción es de uso individual, la segunda está pensada para trabajar en equipo y compartir configuraciones entre equipo miembros.

Ventajas e inconvenientes de SDKMAN

SDKMAN! es muy fácil de usar y cuenta con una rica biblioteca de herramientas, marcos de trabajo y lenguajes compatibles. Funciona en Linux, MacOS y Windows. Por otro lado, esta herramienta está centrada en JVM y requiere la aceptación del autor para ser proveedor. Además, la mecánica de .sdkmanrc es muy pobre y podría ralentizar considerablemente el proceso de cambio de directorios.

Me gustaría utilizar muchas otras lenguas

Si necesita utilizar muchos idiomas y herramientas, debería echar un vistazo a asdf. Esta herramienta se centra en herramientas de "alto nivel". Mientras que en SDKMAN! puedes encontrar muchas herramientas específicas para Java, como Bpipe o Znai, asdf ofrece muchas más herramientas pero no tan específicas. Por supuesto, algunas de esas herramientas se solapan, por ejemplo Java, Tomcat o mvnd están disponibles en ambas.

Cuando desee utilizar asdfnecesita tener git y rizo instalado. Después de eso, sólo:

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

y añade estas líneas en ~/.bashrc file:

. $HOME/.asdf/asdf.sh

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

Ahora puedes instalar plugins y herramientas en tus versiones favoritas.

Gestión basada en plugins

A diferencia de SDKMAN!, asdf utiliza plugins para gestionar las herramientas. Por lo tanto, antes de poder instalar una herramienta, es necesario instalar un plugin. Volvamos a nuestro proyecto de ejemplo e intentemos configurar el entorno utilizando asadfsdf.

En primer lugar, tenemos que instalar plugins:

asdf plugin add java

asdf plugin add maven

asdf plugin add mvnd

Entonces podremos instalar nuestras herramientas:

asdf install java openjdk-17

asdf install maven 3.8.4

asdf install mvnd 0.7.1

Y una vez más, a diferencia de SDKMAN!, asdf no cambia nada en nuestro entorno. Cuando tratamos de usar java, obtenemos un mensaje de error como:

No hay versión para el comando Java

Considere añadir una de las siguientes versiones en su archivo de configuración en ~/.tool-versions

java openjdk-17

Necesitamos crear el archivo .versiones-herramienta en el directorio de inicio para gestionar las versiones por defecto.

Versiones local y global

Actualización de versiones de software con asdf es bastante simple. Simplemente instalamos una nueva versión. Como este proceso no afecta al entorno, podríamos hacerlo en cualquier momento y en cualquier lugar del sistema de archivos. Cuando queremos utilizar una versión específica de algún software, necesitamos crear en el directorio del proyecto un archivo .versiones-herramienta que puedan compartir los miembros del equipo. Recuerde que debe garantizar que todos los miembros del equipo tienen asdf y plugins instalados. La lista de plugins que puedes encontrar aquí.

Conflictos de versión

asdf no sólo soporta lenguajes de programación, frameworks y herramientas como vim o kubernetess. También soporta bases de datos. En tal caso, podríamos instalar varias versiones de, por ejemplo, Postgres, pero sólo podría ejecutarse una instancia. Esto se debe a que asdf ejecuta comandos directamente en tu sistema operativo sin ninguna capa de separación. Esto conlleva problemas como "puerto ya en uso" y conflictos de recursos.

Ventajas e inconvenientes

asdf es una herramienta muy buena si quieres trabajar en un entorno políglota. Soporta muchas herramientas, lenguajes y frameworks. Su arquitectura basada en plugins hace que sea muy fácil ampliarla. Sin embargo, algunas de las herramientas que tiene en la biblioteca necesitan un trabajo adicional durante la instalación para proporcionar todas las dependencias necesarias. asdf no funciona en Windows, ni siquiera en WSL.

Por último, pero no por ello menos importante: Docker

Cuando hablo del conflicto portuario más arriba, muchos de ustedes conocen la solución.

Docker podría ayudarnos en algunos casos. Lo menciono por obligación, porque esta herramienta es tan grande y compleja que no podemos hablar de ella en un solo artículo.

Junto con Docker, deberíamos utilizar un docker-compose que nos da la posibilidad de coordinar entornos multicontenedor.

Ventajas e inconvenientes de Docker

Docker nos ayuda a gestionar herramientas que necesitan algunos recursos específicos, como puertos o archivos. Separa instancias en contenedores y nos da un control total sobre ellas. Sin embargo, Docker es una herramienta que introduce mucha complejidad en nuestro entorno de trabajo y puede ser problemática en algunos casos. Uno de esos casos de uso de Docker en una prueba se describe en uno de nuestros anteriores artículo.

Resumen

Sé que no he descrito todas las herramientas que se pueden utilizar para gestionar las versiones de las herramientas. Hay muchas más, como jEnv que podría sustituir a SDKMAN,

o NVM que podemos utilizar para gestionar npm o RVM para Ruby. Me he centrado en herramientas que he "probado en el campo de batalla" y que puedo recomendar a cualquiera.

Artículos relacionados

Desarrollo de software

9 errores que hay que evitar al programar en Java

¿Qué errores deben evitarse al programar en Java? En el siguiente artículo responderemos a esta pregunta.

The Codest
Rafal Sawicki Desarrollador Java
Soluciones para empresas y escalas

¿Cómo puede Java ayudar a su empresa?

Antes de empezar, me gustaría recordarte una cosa importante. Java no es sólo un lenguaje de programación.

Bartlomiej Kuczynski
Desarrollo de software

Contenedores de pruebas - ¿Cómo facilitar las pruebas?

¿Buscas una manera de hacer tests de forma más sencilla? ¡Te hemos pillado! Consulta el siguiente artículo y aprende cómo hacerlo posible.

Bartlomiej Kuczynski
Desarrollo de software

Herramientas Javascript en acción

Descubre algunas herramientas de recuperación JavaScript para subir de nivel en tu juego de programación. Más información sobre ESLint, Prettier y Husky.

The Codest
Reda Salmi React Promotor
Desarrollo de software

Asíncrono y monohilo JavaScript?

JavaScript es un lenguaje monohilo y, al mismo tiempo, también no bloqueante, asíncrono y concurrente. Este artículo le explicará cómo sucede.

Lukasz Kolko

Suscríbase a nuestra base de conocimientos y manténgase al día de la experiencia del sector informático.

    Quiénes somos

    The Codest - Empresa internacional de desarrollo de software con centros tecnológicos en Polonia.

    Reino Unido - Sede central

    • Oficina 303B, 182-184 High Street North E6 2JA
      Londres, Inglaterra

    Polonia - Centros tecnológicos locales

    • Parque de oficinas Fabryczna, Aleja
      Pokoju 18, 31-564 Cracovia
    • Embajada del Cerebro, Konstruktorska
      11, 02-673 Varsovia, Polonia

      The Codest

    • Inicio
    • Quiénes somos
    • Servicios
    • Case Studies
    • Saber cómo
    • Carreras profesionales
    • Diccionario

      Servicios

    • Asesoramiento
    • Desarrollo de software
    • Desarrollo backend
    • Desarrollo Frontend
    • Staff Augmentation
    • Desarrolladores de backend
    • Ingenieros de la nube
    • Ingenieros de datos
    • Otros
    • Ingenieros de control de calidad

      Recursos

    • Hechos y mitos sobre la cooperación con un socio externo de desarrollo de software
    • De EE.UU. a Europa: ¿Por qué las startups estadounidenses deciden trasladarse a Europa?
    • Comparación de los polos de desarrollo de Tech Offshore: Tech Offshore Europa (Polonia), ASEAN (Filipinas), Eurasia (Turquía)
    • ¿Cuáles son los principales retos de los CTO y los CIO?
    • The Codest
    • The Codest
    • The Codest
    • Privacy policy
    • Condiciones de uso del sitio web

    Copyright © 2025 por The Codest. Todos los derechos reservados.

    es_ESSpanish
    en_USEnglish de_DEGerman sv_SESwedish da_DKDanish nb_NONorwegian fiFinnish fr_FRFrench pl_PLPolish arArabic it_ITItalian jaJapanese ko_KRKorean nl_NLDutch etEstonian elGreek es_ESSpanish