El desarrollo remoto se simplifica con DevPod: una herramienta gratuita de código abierto

Llegué relativamente tarde al tema de los entornos de desarrollo remoto (también conocidos como entornos de desarrollo en la nube). La razón principal es que no he trabajado en un equipo de desarrollo durante más de seis años. Sin embargo, ahora estoy trabajando para Loft Labs y tenemos un producto de entorno de desarrollo remoto: DevPod . Quería entender nuestra propuesta de valor, ya que estaré en FOSDEM operando el stand de DevPod .

El problema

Como ex desarrollador, recuerdo vívidamente el dolor de configurar el entorno de desarrollo de cada desarrollador. Al principio de mi carrera, el arquitecto tuvo que configurar mi máquina de desarrollo dolorosamente, por lo que era similar a su configuración. Más tarde, hice lo mismo para los miembros de mi equipo en repetidas ocasiones. El alcance de posibles discrepancias que afectan el desarrollo es prácticamente infinito: sistema operativo, por supuesto, versión y sabor de los SDK, por ejemplo , Eclipse Temurin vs SapMachine de Java, ganchos de git, etc. Fue sudor, esfuerzo y sangre en cada proyecto.

A lo largo de los años, he visto algunos enfoques interesantes para reproducir entornos de desarrollo. Al principio, surgían de las máquinas virtuales, luego de los contenedores. Creo que Vagrant fue la primera herramienta que me llamó la atención: asistí a una charla en 2012 en la que el orador mencionó que la usaba para configurar máquinas antes de sus sesiones de capacitación.

Las arquitecturas de aplicaciones han evolucionado significativamente a lo largo de los años y se han vuelto más complejas y sofisticadas. Hace años, lo más probable era que la única dependencia de la infraestructura fuera una base de datos SQL. En el ecosistema JVM, teníamos la suerte de tener JDBC, una API que funcionaba en todas las bases de datos SQL. Todo lo que había que hacer era escribir SQL estándar y se podía configurar la instancia de la base de datos en tiempo de ejecución. Con bases de datos integradas como Apache Derby y H2 , no era necesaria una instancia Oracle dedicada para cada desarrollador.

Los tiempos han cambiado. No es raro que las aplicaciones necesiten una base de datos SQL, una base de datos NoSQL, un clúster de Kafka y algunos servicios de aplicación adicionales. Las organizaciones que desarrollan dichas aplicaciones ya están utilizando alguna tecnología relacionada con contenedores, por ejemplo , Docker o Kubernetes, para gestionar esta complejidad.

Sin embargo, no resuelve el problema inicial: ¿cómo se alinean el IDE, sus complementos, los SDK, los ganchos de Git y todo lo demás? Probablemente lo hayas adivinado por el título: Entornos de desarrollo remoto.

Contenedores de desarrollo

En la introducción, mencioné que los RDE se denominan entornos de desarrollo en la nube. La idea principal detrás de los RDE es almacenar todo lo que se pueda en una nube y compartirlo con todos los desarrolladores. Además, se desea que funcionen en los proveedores de nube más extendidos y en los IDE más utilizados. Cuando surge esa necesidad, es hora de que los actores de la industria se reúnan en torno a un estándar. Microsoft inició el estándar Development Container para su complemento de desarrollo VS Code Remove con este propósito exacto.

Un contenedor de desarrollo (o contenedor dev para abreviar) le permite utilizar un contenedor como un entorno de desarrollo con todas las funciones. Se puede utilizar para ejecutar una aplicación, para separar herramientas, bibliotecas o entornos de ejecución necesarios para trabajar con una base de código y para ayudar en la integración y las pruebas continuas. Los contenedores de desarrollo se pueden ejecutar de forma local o remota, en una nube privada o pública, en una variedad de herramientas y editores de soporte.

La especificación de contenedores de desarrollo busca encontrar formas de enriquecer los formatos existentes con configuraciones, herramientas y ajustes específicos de desarrollo comunes, a la vez que ofrece una opción de contenedor único simplificada y sin orquestación, de modo que se puedan utilizar como entornos de codificación o para la integración y las pruebas continuas. Más allá de los metadatos básicos de la especificación, la especificación también permite a los desarrolladores compartir y reutilizar rápidamente los pasos de configuración de los contenedores a través de funciones y plantillas.

--¿Qué son los contenedores de desarrollo?

El archivo de configuración es devcontainer.json . Puede encontrar la referencia del esquema aquí . Los productos VS Code, Visual Studio e IntelliJ pueden aprovechar un archivo devcontainer.json . Del lado del proveedor, GitHub Codespaces, CodeSandbox y DevPod lo admiten.

Presentando DevPod

DevPod es una solución que aprovecha devcontainer.json . Implementa tres propiedades principales:

• Código abierto: sin ataduras a ningún proveedor. 100 % gratuito y de código abierto, creado por desarrolladores para desarrolladores.

• Solo cliente: no se necesita configuración del lado del servidor. Descargue la aplicación de escritorio o la CLI para comenzar.

• Sin opiniones: entorno de desarrollo repetible para cualquier infraestructura, cualquier IDE y cualquier lenguaje de programación.

DevPod está diseñado para ser fácil de usar y sencillo, lo que hace que sea muy fácil de usar. Decidí escribir esta publicación porque me impresionó el producto y para ordenar mis pensamientos.

El primer paso es instalar DevPod. Estoy en Mac; hay una receta de Homebrew.

 brew install devpod

Una vez instalado, puedes iniciarlo desde la CLI o la GUI. Prefiero las GUI al principio para entender mejor las opciones disponibles.

DevPod ofrece proveedores: ubicaciones donde ejecutar los contenedores. El valor predeterminado es Docker. Puede agregar proveedores adicionales, incluidos proveedores de la nube y clústeres de Kubernetes.

Para esta publicación, mantendré Docker; estoy usando OrbStack. Ahora, vayamos al meollo del asunto. Vayamos al elemento de menú de espacios de trabajo. Si ya ha creado espacios de trabajo, deberían aparecer aquí. Como es nuestra primera visita, crearemos uno. Haga clic en el botón btn:[Crear espacio de trabajo]. Probemos uno de los ejemplos de inicio rápido, es decir , Rust. Mi IDE de elección es IntelliJ IDEA, pero puede elegir el suyo. Una vez que haya seleccionado una imagen, un IDE y un proveedor, haga clic en Crear espacio de trabajo.

En este punto, DevPod descargará la imagen y abrirá el proyecto que se ejecuta en OrbStack en IntelliJ.

A partir de ahora, podemos comenzar a trabajar felizmente en nuestro proyecto Rust, seguros de que todos los miembros del equipo utilizan la misma versión de Rust.

Tenga en cuenta que la primera vez que utilice esta configuración, DevPod también descargará el cliente JetBrains. Sin embargo, se trata de un retraso de descarga único.

Lo mismo se aplica a los ganchos de pre-commit de Git, por ejemplo. Si prefieres desarrollar dentro de otro IDE, selecciónalo en el momento del lanzamiento y listo. Cuando termines con el trabajo del día, detén el contenedor. Si estás trabajando en la nube, ahorras dinero. Al día siguiente, reanuda el contenedor y continúa con tu trabajo.

Conclusión

DevPod es una herramienta muy útil que permite que los equipos de desarrollo compartan la misma configuración de máquina sin problemas. En esta publicación de blog introductoria, mostré una pequeña parte de lo que puede hacer. Lo aliento a aprovechar su poder si se enfrenta a entornos de desarrollo heterogéneos.

Para ir más allá:

• Contenedores de desarrollo
• DevPod: entornos de desarrollo de código abierto como código
• Comparación de Gitpod, Codespaces, Coder y DevPod para 2024