Original article: Please, Everyone, Put Your Entire Development Environment in Github
Detenme si esto suena familiar...
Quieres iniciar con un nuevo framework/tiempo de ejecución. Así que instalas dicho framework/tiempo de ejecución.
Entonces, abres la terminal y ... comando no encontrado(command not found). Gran suspiro.
Revisitas los documentos que sugieren que has hecho algunos cambios a la configuración de perfil. De lo cual no estás seguro cómo hacerlo, así que vas a StackOverflow, donde encuentras una respuesta de "user92902399" que parece como si pudiera ser legítimo (quién sabe); así que copias y pegas eso en tu terminal y le ruegas a dios que no borre tu disco duro, y le envíes tu historial de búsqueda al presidente por correo.
Ahora el comando del tiempo de ejecución funciona. Pero falla. El error es críptico.
Regresas a Google.
Esta vez no hay respuesta clara en StackOverflow, a pesar de que varias personas tienen un problema similar. Encuentras un issue de Github que pareciera que podría estar relacionado. En algún lado, en el medio de una masa de gente diciendo "¡Gracias, esto funciona!" y "Esto no funciona para nada", alguien utiliza la palabra "Python".
Revisas tu versión de Python, y suficientemente seguro, este framework/tiempo de ejecución no es compatible con el que tienes instalado. Estás a punto de degradarlo, cuando te das cuenta de que la última vez que miraste en la dirección general de la instalación de Python, te tomó un día hacerlo funcionar nuevamente y todavía no está seguro de cómo lo hiciste.
¿Sabes qué? Este nuevo framework/tiempo de ejecución probablemente no sea tan bueno. Definitivamente no vale la pena tanto esfuerzo. ¡Oh mira! Una publicación de blog sobre cómo nunca debes usar declaraciones ternarias. ¿En qué estabas trabajando antes? A quien le importa.
¿Un poco demasiado parecido a lo que hiciste? Así es como es intentar configurar un nuevo proyecto, framework o tiempo de ejecución. Cada vez. Esto es parte de la razón por la que todos los desarrolladores, en un momento dado, miraron a alguien sin comprender, a mitad de un Cheeto, y dijeron: "funciona en mi máquina".
Funciona en TODAS las máquinas
La raíz del problema es que, para que el código funcione, hay un entorno completo que también debe configurarse correctamente. Este es un problema difícil de resolver. Lo que necesitamos es una forma de aislar el entorno de desarrollo y luego enviarlo con el código para que funcione en todas las máquinas. Y debemos hacerlo sin tener que enviar un sistema operativo completo.
La clave está en la palabra "aislar". Resulta que tenemos una forma de aislar y enviar entornos completos. Se llama "Docker". Puedes crear un contenedor con cualquier configuración y luego enviarlo a cualquier otra persona. Todo lo que necesitas ahora es una forma de desarrollar en ese contenedor como si fuera su máquina local.
Tú puedes.
En este artículo, te mostraré cómo puedes usar algunos archivos de configuración para empaquetar, y enviar todo tu entorno de desarrollo sin tu mal gusto en dubstep.
Todo esto gracias a la nueva extensión de contenedores de desarrollo para VSCode.
VS Code y contenedores de desarrollo
El concepto básico detrás de contenedores de desarrollo (Dev containers), es que especifiques un archivo Docker, que a su vez especifica todas las dependencias y pasos de configuración necesarios para obtener la configuración correcta del entorno de desarrollo. VS Code activará ese contenedor, instalará un pequeño servidor en él y luego se conectará de nuevo a tu instancia de VS Code. Lo que esto significa, es que ahora estás desarrollando dentro de un entorno preconfigurado. Pero para ti, es solo VS Code.
Para mostrarte cómo funciona esto, voy a crear un contenedor en el cual desarrollar la API de backend de un proyecto en el que trabajé llamado theurlist.com. El backend de este proyecto está escrito en C# y se ejecuta en Azure Functions. Para ejecutarlo localmente, tendría que instalar el .NET Core tiempo de ejecución, CLI de Azure Functions y la extensión Azure Functions VS Code.
El primer paso es instalar la extensión Dev Containers. Esto agregará un pequeño ícono en la esquina inferior izquierda de tu VSCode.
También necesitarás tener instalado Docker. Los contenedores de Docker no funcionan muy bien si no tienes Docker. Puede descargar la Community Edition aquí.
Con la extensión instalada, necesitas agregar los archivos de configuración adecuados a este proyecto. Es decir, un "Dockerfile" que especifique el contenedor en el que se cargará el proyecto. La extensión viene con un montón de entornos preconfigurados. Para agregar uno al proyecto, abre la paleta de comandos y selecciona "Dev Containers: Add Development Container Configuration Files" ("Contenedores de Desarrollo: Agregar archivos de configuración de contenedor de desarrollo").
Este proyecto utiliza Azure Functions y C#, por lo que seleccionarás esa definición de container.
Tan pronto como lo hagas, VS Code agregará una carpeta ".deployment" con "Dockerfile" y un archivo "devcontainer.json" dentro. También preguntará inmediatamente si quieres volver a abrir el proyecto en un contenedor. Decimos que no, y dejas que VS Code se relaje por un minuto mientras miramos estos archivos.
Primero vamos a mirar en el "Dockerfile".
Configuración Dockerfile
El "Dockerfile" especifica lo que habrá en el contenedor. Si lo abres, puedes ver que hay bastante allí. Es un poco detallado. Pero podemos analizar las partes importantes.
Lo primero que hace es incorporar la última versión de .NET Core SDK.
Luego instala algunas utilidades en el contenedor. Específicamente, instala ...
- Git (Fuente de controles)
- procps (utilidad de inspección de procesos)
- curl (utilidad HTTP)
- apt-transport-https (utilidad HTTPS)
- gnupg2 (una herramienta de encriptado)
- lsb-release (Imprime información específica de Linux)
Todo esto es para crear un entorno que tenga todas las herramientas oscuras que un desarrollador pueda necesitar para ejecutar este proyecto y poder registrarlo dentro y fuera del control de código fuente.
Luego, instala las herramientas principales de Azure Functions. Configura todas las ubicaciones de repositorio necesarias antes de la instalación. Estas son todas las cosas que un desarrollador tendría que hacer antes de poder ejecutar este proyecto.
El otro archivo de la carpeta ".devcontainer" es el archivo "devcontainer.json".
El archivo devcontainer.json
Este archivo especifica algunas configuraciones adicionales para el entorno de desarrollo remoto. Específicamente...
- Indica que el "Dockerfile" debe usarse para construir el contenedor.
- Se asegura de que el puerto "7071" se reenvíe desde el contenedor para que puedas acceder a él en "localhost: 7071". Este es el puerto en el que Azure Functions se ejecuta localmente.
- Especifica las extensiones que se deben instalar en el contenedor. Dado que en realidad no estás usando VS Code localmente, sus extensiones no se instalan automáticamente. Especificarlos en este archivo asegura que estén allí cuando se abre el proyecto.
Y con eso, podemos abrir la paleta de comandos y seleccionar "Dev Containers: Reopen folder in container".
VS Code se recargará y comenzará a construir el contenedor para este proyecto.
La primera vez que hace esto, tarda uno o dos minutos porque las imágenes base deben extraerse y construirse. Una vez hecho esto por primera vez, las cargas posteriores son mucho más rápidas, ya que la imagen existe en tu máquina.
En el caso de este proyecto, una vez que se construye el contenedor, VS Code se propone restaurar las dependencias de C#, lo cual se realiza con la extensión C# que se incluyó en el archivo de configuración "devcontainer.json".
Cuando todo haya terminado, puedes ejecutar este proyecto simplemente presionando F5. Y así, la aplicación está en funcionamiento.
Piensa en lo que habríamos tenido que hacer para obtener esta configuración localmente ...
- Instalar .NET Core
- Instalar las Functions Core Tools
- Instalar la extensión VS Code Functions
- Instalar la extensión VS Code C#
Con los contenedores de desarrollo, nada de eso es necesario. Podemos configurar y enviar un entorno de desarrollo completo en dos archivos de texto.
Por favor, pon tu entorno de desarrollo en Github
Así que aquí está mi humilde súplica: en lugar de describir 15 pasos en un README de Github para configurar tu proyecto para que se ejecute, coloca todo tu entorno de desarrollo en Github. Eso significa registrar en esa carpeta ".devcontainers". Si un desarrollador usando tu proyecto no tiene VS Code o la extensión "Dev Containers", no sucede nada. No puedes perder.
Estoy emocionado porque siento que los días de configuraciones del infierno están llegando a su fin. Y además, piensa en todas las personas que salvaremos de los artículos dogmáticos sobre sentencias ternarias.