Al desarrollar código, a menudo es necesario probarlo antes de enviarlo al entorno de desarrollo o producción. Sin embargo, esperar una implementación con acciones de GitHub o implementaciones de la pila CDK con CDK lleva mucho tiempo.
Estas tareas que consumen mucho tiempo acaban con la velocidad de iteración, que es un factor crítico si desea desarrollar código de forma eficaz. Esto se debe a que necesita probar sus implementaciones correctamente para asegurarse de que funcionen. Luego, después de cada cambio, debes probarlo nuevamente.
Con los últimos agentes de codificación, desarrollar scripts de prueba locales completos es súper rápido y es algo que hago todos los días mientras escribo código como científico de datos.
En este artículo, le explicaré por qué necesita crear una configuración de prueba local eficiente ejecutando una imagen de Docker y enviando eventos de prueba. También mostraré cómo lo hago yo mismo y cómo me ayuda a convertirme en un ingeniero más eficiente.
Hablaré principalmente sobre cómo trabajar con Infraestructura como código (IaC), porque eso es principalmente con lo que trabajo en el día a día. Sin embargo, el concepto de ejecutar su código localmente de manera eficiente se aplica a toda la programación.
Por qué necesitas ejecutar código localmente
En primer lugar, quiero explicar por qué necesitamos ejecutar el código localmente. La respuesta simple es que:
La velocidad de iteración es uno de los aspectos más importantes para llevar el código de trabajo a producción de manera eficiente.
Cuanto más rápido puedas iterar tu código, mejor. Cuando desarrolla una nueva funcionalidad (o repara una funcionalidad antigua), desea probar rápidamente si funciona y luego corregir el código de forma iterativa hasta que funcione según lo previsto.
Si tiene que esperar entre 5 y 15 minutos para que se implemente su código antes de probarlo, tiene un problema grave. Cada vez que no puedes solucionar un problema de una sola vez, pierdes entre 5 y 15 minutos simplemente esperando la implementación.
En su lugar, deberías ejecutar tu código localmente. Por ejemplo, si está trabajando con IaC, como AWS CDK, puede crear y ejecutar imágenes de Docker localmente, esencialmente replicando el entorno de producción, pero en su propia computadora. De esta manera, el ciclo de iteración es simple y el tiempo que lleva construir la imagen de Docker y ejecutar el código.
La creación de la imagen de Docker suele ser muy rápida, teniendo en cuenta que Docker almacena en caché compilaciones anteriores. Por lo tanto, es probable que dedique la mayor parte de su tiempo a ejecutar el código con entradas de prueba y verificar que la salida sea la esperada.
Si está trabajando en una aplicación web, debería (y probablemente ya lo esté haciendo) ejecutar la aplicación localmente antes de implementar su código. No debería haber ninguna diferencia al trabajar con IaC.
Cómo desarrollar localmente como si fuera un entorno de producción
Un aspecto importante al desarrollar localmente es que puede replicar fielmente el entorno de producción. Si está escribiendo IaC, creando imágenes de Docker y ejecutando la imagen de Docker localmente:
Está probando exactamente con el mismo código, con las mismas rutas de entrada, y si refleja su archivo .env en el archivo .env de producción, también refleja todas las variables. Por lo tanto, ejecutar imágenes de Docker localmente es el camino a seguir si puede hacerlo.
Cree scripts locales con agentes de codificación
Antes del lanzamiento de agentes de codificación como Cursor y Claude Code, generalmente era una tarea tediosa configurar el código para ejecutar todo localmente. Necesitaba crear la imagen de Docker correctamente, configurarla para que se ejecutara con su archivo .env, etc. O tal vez desee ejecutar su código localmente como un servidor FastAPI, en cuyo caso enfrentó desafíos similares.
Sin embargo, esto ya no es un problema. Para comenzar a ejecutar localmente, normalmente le doy al Cursor las siguientes instrucciones:
Cree un script de shell para ejecutar este código localmente. El script de shell debe ejecutar la imagen de la ventana acoplable y tener un indicador opcional –build, que crea la imagen de la ventana acoplable antes de ejecutarla. La imagen de la ventana acoplable debería cargar variables de entorno desde el archivo .env.
Esto crea un script de shell eficiente que puede utilizar. Me gusta la etiqueta opcional –—build, porque a veces lleva mucho tiempo crear la imagen de Docker y no siempre necesito crearla antes de ejecutarla.
Además, los siguientes factores me permiten ejecutar el script fácilmente:
Nunca almaceno secretos reales en .env. Solo almaceno referencias secretas, que luego mi código recoge de AWS Secrets Manager. Por lo tanto, puedo enviar mi archivo env sin preocuparme de filtrar secretos. Además, esto también facilita que otros ejecuten los scripts. Cuando extraigo el código de GitHub, creo otro archivo con eventos de prueba, donde puedo enviar eventos fácilmente a la imagen de Docker en ejecución. De esta manera, puedo comprobar fácilmente la entrada y la salida. Implemento los scripts de prueba en Git, para que todos los demás también tengan acceso a ellos. Esto incluye el archivo env como se mencionó, ya que no contiene ningún secreto.
Ahora tiene la configuración exacta que necesita para ejecutar y probar su código localmente. Cada vez que realiza cambios, reconstruye la imagen de Docker y envía los eventos de prueba, asegurándose de que todo funcione según lo previsto.
Recomiendo configurar estos scripts de prueba locales para todos sus repositorios y enviarlos a Git para compartirlos. Tener acceso a estos scripts hará que todo tu equipo sea más eficiente como programadores.
Más consejos para ejecutar localmente
También quiero compartir dos consejos adicionales para ser aún más eficiente, teniendo en cuenta estos archivos de prueba locales:
Ejecute y pruebe la imagen de Docker con enlaces de confirmación previa. Otorgue a su agente de codificación acceso a estos scripts.
Ganchos de compromiso previo
Los enlaces de confirmación previa son código que se ejecuta antes de cada confirmación en git. Los ganchos de precompromiso típicos incluyen:
Corre negro. para formatear Ejecute mypy para seguridad de tipos Ejecute pruebas de pytest para asegurarse de que todas las pruebas pasen
Tener un gancho de confirmación previa garantiza que nunca olvidará ejecutar dichos comandos antes de enviar su código. Esto es increíblemente útil y supone un gran ahorro de tiempo. Es difícil para mí contar la cantidad de veces que olvidé ejecutar el formato en negro antes de confirmar, y las pruebas de implementación terminan fallando 5 minutos después, lo que me cuesta mucho tiempo.
Si compilar, ejecutar y probar la imagen de Docker no requiere mucho tiempo, recomiendo agregar esto también a los enlaces de confirmación previa. De esta manera, garantiza que antes de enviar cualquier código, ha probado que el código se ejecuta en un entorno de producción y que obtiene el resultado esperado para una entrada determinada. Implementar esto como un gancho de confirmación previa probablemente le ahorrará mucho tiempo en el futuro.
Dar acceso al cursor a los scripts de prueba
El segundo consejo es que siempre proporciono acceso al Cursor y al Código Claude para ejecutar mis scripts de prueba. Luego le digo a Cursor que ejecute los scripts de prueba después de realizar cambios y antes de finalizar su implementación actual.
Hacer que su agente de codificación ejecute y pruebe imágenes de Docker aumentará enormemente la cantidad de veces que podrá realizar una implementación de una sola vez.
Esto le ahorrará mucho tiempo cuando su agente de codificación implemente una función y luego tenga que ejecutar y probar manualmente la imagen de Docker. Si ahora encuentra un error, debe pegarlo en su agente de codificación y el ciclo se repite hasta que el código funcione.
Esto es una pérdida de tiempo y algo que debes esforzarte por evitar. Darle acceso a su agente de codificación a los scripts de prueba es esencialmente como entregarle una herramienta a su agente de codificación, lo que mejora enormemente el rendimiento en las tareas de ingeniería de software. No puedo enfatizar lo suficiente cuánto tiempo me ahorra esto.
Conclusión
En este artículo, analicé cómo se pueden crear entornos de producción realistas localmente mediante la creación de scripts para crear, ejecutar y probar imágenes de Docker localmente. Hacer esto reduce la velocidad de iteración, que es un componente crítico para ser un programador eficiente. Además, cubrí cómo hago esto en la práctica: solicitando al Cursor que cree los scripts de prueba y algunos eventos de ejemplo que puedo ejecutar en la imagen de Docker. Luego doy acceso a Cursor y Claude Code para ejecutar estos scripts, lo que hace que mi programación sea mucho más eficiente.
Creo que tener una velocidad de iteración rápida es fundamental para casi todas las tareas de ingeniería de software y es algo por lo que debes esforzarte. Crear archivos de prueba locales y darle acceso a su agente de codificación aumenta mucho la velocidad de iteración, por lo que creo que hacerlo yo mismo ha aumentado enormemente mi productividad como programador.
👉 Mis recursos gratuitos
🚀 10 veces su ingeniería con LLM (curso gratuito por correo electrónico de 3 días)
📚 Obtenga mi libro electrónico gratuito sobre Modelos de lenguaje de visión
💻 Mi seminario web sobre modelos de lenguaje de visión
👉 Encuéntrame en las redes sociales:
📩 Suscríbete a mi newsletter
🧑💻 Ponte en contacto
🐦X/Twitter
✍️ Medio