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 trabajo para Loft Labs y tenemos un producto de desarrollo remoto (RDE) : DevPod . Quería comprender nuestra propuesta de valor, ya que estaré en FOSDEM operando el stand de DevPod .
El problema
Como exdesarrollador, recuerdo vívidamente el esfuerzo que suponía configurar el entorno de desarrollo de cada desarrollador. Al principio de mi carrera, el arquitecto tenía que configurar mi equipo de desarrollo de forma tediosa, para que fuera similar a su configuración. Más adelante, hice lo mismo repetidamente con los miembros de mi equipo. La gama de posibles discrepancias que afectan al desarrollo es prácticamente infinita: el sistema operativo, por supuesto, la versión y el tipo de los SDK ( por ejemplo , Eclipse Temurin vs. SapMachine de Java), los ganchos de Git, etc. Cada proyecto implicaba sudor, esfuerzo y esfuerzo.
A lo largo de los años, he visto algunos enfoques interesantes para reproducir entornos de desarrollo. Al principio, surgieron 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 donde el ponente mencionó que la usaba para configurar máquinas antes de sus sesiones de formación.
Las arquitecturas de aplicaciones han evolucionado significativamente con los años, volviéndose más complejas y sofisticadas. Hace años, era probable que la única dependencia de la infraestructura fuera una base de datos SQL. En el ecosistema JVM, teníamos la suerte de contar con JDBC, una API compatible con todas las bases de datos SQL. Bastaba con 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 se necesitaba una instancia de Oracle dedicada para cada desarrollador.
Los tiempos han cambiado. Es habitual 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 estas aplicaciones ya utilizan tecnología basada en contenedores, como 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 de los RDE es almacenar todo lo posible en la nube y compartirlo con todos los desarrolladores. Además, se busca que funcionen con los proveedores de nube más comunes y los IDE más utilizados. Cuando surge esta necesidad, es hora de que los actores de la industria se unan en torno a un estándar. Microsoft creó el estándar Development Container para su complemento de desarrollo VS Code Remove precisamente con este propósito.
Un contenedor de desarrollo (o contenedor dev, para abreviar) permite utilizarlo como un entorno de desarrollo completo. Puede utilizarse para ejecutar una aplicación, separar herramientas, bibliotecas o entornos de ejecución necesarios para trabajar con un código base y facilitar la integración y las pruebas continuas. Los contenedores dev pueden ejecutarse local o remotamente, en una nube privada o pública, y en diversas herramientas y editores de soporte.
La Especificación de Contenedores de Desarrollo busca enriquecer los formatos existentes con configuraciones, herramientas y ajustes comunes específicos para el desarrollo, a la vez que ofrece una opción de contenedor único, simplificada y sin orquestación, para que puedan utilizarse como entornos de programación o para la integración y las pruebas continuas. Además de los metadatos principales de la especificación, esta también permite a los desarrolladores compartir y reutilizar rápidamente los pasos de configuración de los contenedores mediante Características y Plantillas.
— ¿
Qué son los contenedores de desarrollo?
El archivo de configuración es [Nombre del devcontainer.jsonarchivo]. Puede encontrar la referencia del esquema aquí . Los productos VS Code, Visual Studio e IntelliJ pueden usar este devcontainer.jsonarchivo. En cuanto al proveedor, GitHub Codespaces, CodeSandbox y DevPod lo admiten.
Presentamos 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 requiere configuración del servidor. Descarga la aplicación de escritorio o la CLI para empezar.
- Sin opiniones: entorno de desarrollo repetible para cualquier infraestructura, cualquier IDE y cualquier lenguaje de programación.
DevPod está diseñado para ser intuitivo y sencillo, lo que lo hace muy fácil de usar. Decidí escribir esta publicación porque me impresionó el producto y para ordenar mis ideas.
El primer paso es instalar DevPod. Estoy en Mac; hay una receta de Homebrew.
brew install devpodUna vez instalado, puedes iniciarlo desde la CLI o la GUI. Prefiero usar GUI al principio para comprender mejor las opciones disponibles.
DevPod ofrece proveedores: ubicaciones donde ejecutar los contenedores. El valor predeterminado es Docker. Puedes agregar proveedores adicionales, como Cloud Providers y clústeres de Kubernetes.
Para esta publicación, usaré Docker; estoy usando OrbStack. Ahora, vayamos al meollo del asunto. Vayamos al menú de espacios de trabajo. Si ya has creado espacios de trabajo, deberían aparecer aquí. Como es nuestra primera visita, crearemos uno. Haz clic en el botón «Crear espacio de trabajo» . Probemos con uno de los ejemplos de inicio rápido, por ejemplo , Rust. Mi IDE preferido es IntelliJ IDEA, pero puedes elegir el tuyo. Una vez que hayas seleccionado una imagen, un IDE y un proveedor, haz 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, confiados en que todos los miembros del equipo usan la misma versión de Rust.
Tenga en cuenta que la primera vez que use esta configuración, DevPod también descargará el cliente JetBrains. Sin embargo, la descarga se retrasa una sola vez.
Lo mismo ocurre con los ganchos pre-commit de Git, por ejemplo. Si prefieres desarrollar en otro IDE, selecciónalo al iniciar y listo. Al terminar tu trabajo del día, detén el contenedor. Si trabajas en la nube, ahorras dinero. Al día siguiente, reanuda el contenedor y continúa con tu trabajo.
Conclusión
DevPod es una herramienta útil que permite a tu(s) equipo(s) de desarrollo compartir la misma configuración de máquina sin complicaciones. En esta entrada de blog introductoria, mostré una pequeña parte de lo que puedes hacer. Te animo a aprovechar su potencial si te enfrentas a entornos de desarrollo heterogéneos.
