No programás solo: GitHub Copilot + GitHub Codespaces = tu nuevo equipo de desarrollo

¡Hola! 👋 Y muchas gracias por estar del otro lado leyendo esta publicación. Fue creada para que puedas realizar el paso a paso de mi workshop “No programás solo: GitHub Copilot + GitHub Codespaces = tu nuevo equipo de desarrollo“, una clase de 90 minutos para que aprendas de manera práctica y divertida sobre estos servicios de GitHub. Y lo mejor… ¡no necesitás pagar nada! Todo lo podés hacer con tu cuenta gratuita.

La idea de esta página es simple: que en 7 pasos prácticos puedas conocer y aprender sobre Copilot y Codespaces, utilizando un proyecto de WordPress. Para esto necesitás:

Una cuenta de GitHub gratuita.
Un navegador moderno (Chrome, EDGE, Firefox, etc).
Muchas ganas de jugar con IA generativa, GitHub Copilot y GitHub Codespaces.

Y lo mejor: ¡no necesitás saber programar! Aunque se valora mucho conocimientos generales de desarrollo de software y docker.

¿Te animás a hacerlo? ¡Avanzá en el desafío!

Contenidos

1 🤓 ¿Quién soy y qué vamos a hacer?
2 📂 Introducción rápida: GitHub, Copilot y Codespaces
3 💡 ¿Qué vamos a hacer en este workshop?
4 💻 Mano a la obra: ¡a comenzar a trabajar!
5 🚀 Conclusiones y cierre: ¡dejame feedback!

🤓 ¿Quién soy y qué vamos a hacer?

Soy Pablo Di Loreto, trabajo desde el año 1998 en tecnología, desarrollo de software, educación y comunidades. Soy Microsoft MVP (Most Valuable Professional) desde hace 13 años, hoy reconocido en las categorías Microsoft Azure y Azure AI.

Interactúo con soluciones de IA desde el año 2017, cuando creamos junto con un gran equipo de trabajo Algie, el Bot de una gran ex compañía en la que trabajé.

Actualmente soy Director de Ingeniería en MODO, el ecosistema de pagos donde trabajamos articulando y dinamizando el ecosistema de pagos en Argentina junto a bancos, adquirentes, comercios, marcas y reguladores para que los usuarios tengan una propuesta integral dentro de sus pagos cotidianos.

En esta charla busco que puedas conocer e interactuar con tres soluciones infaltables si desarrollás (o intentás desarrollar) software:

GitHub: lugar donde vive tu código, con repositorios, issues, PRs, releases, etc.
GitHub Copilot: un asistente de IA que utiliza tecnología generativa para escribir código, y varias cosas más.
GitHub Codespaces: un entorno de desarrollo completo alojado en la nube, basado en Visual Studio Code.

¿Qué necesito saber antes de avanzar? Si bien vamos a recorrer paso a paso estas soluciones de GitHub (y no necesitás conocer sobre Copilot ni Codespaces previamente), es importante tener en cuenta que para disfrutar y aprovechar esta experiencia esperamos que conozcas sobre:

GitHub: es recomendable que hayas interactuado antes con GitHub. Sino, quizás te cueste un poquito más la experiencia.
WordPress: no te pedimos que sepas manejar WordPress a la perfección, pero si al menos que conozcas qué es y (mejor aún) que alguna vez hayas interactuado.
Docker y Desarrollo de Software: si bien esta charla se enfoca poco en la parte de código (lo vemos en alto nivel), es importante que conozcas lo básico de Docker, Docker Compose y algo de programación (y si es PHP, buenísimo!).

📂 Introducción rápida: GitHub, Copilot y Codespaces

Durante la charla, vamos a recorrer una introducción para que todos entendamos qué es GitHub, qué es GitHub Copilot y qué es GitHub Codespaces. La idea no es hacer una enciclopedia, sino que tengas el contexto justo para aprovechar al máximo el workshop 💡

GitHub

GitHub es el lugar donde vive tu código. Acá vas a poder:

Crear y mantener repositorios (públicos o privados).
Trabajar con branches, pull requests y revisiones de código.
Reportar y seguir tareas con issues.
Coordinar trabajo con otras personas, equipos y proyectos open source.

En el contexto de esta charla, GitHub va a ser:

El lugar donde vamos a crear el repositorio vacío del workshop.
La puerta de entrada para abrir nuestro entorno en GitHub Codespaces.
El motor que va a ejecutar nuestro workflow de CI para revisar los plugins de WordPress.

En resumen: GitHub es el “hub” donde se organiza todo lo que vamos a hacer hoy 🔧

GitHub Copilot

GitHub Copilot es tu asistente de IA generativa dentro del entorno de desarrollo. En lugar de escribir todo desde cero, Copilot puede:

Sugerirte líneas o bloques completos de código mientras escribís.
Generar archivos completos (por ejemplo, un docker-compose.yml o un README.md).
Ayudarte con funciones repetitivas o boilerplate.
Proponer soluciones a partir de prompts bien pensados (lo que le pedís y cómo se lo pedís).

En este workshop vamos a usar Copilot para:

Armar el entorno Docker de WordPress con MySQL y phpMyAdmin.
Crear archivos auxiliares como .gitignore, env.example y README.
Generar la base de un plugin de WordPress.
Aprovechar Copilot Instructions para que entienda mejor el contexto de nuestro proyecto.

Importante: Copilot no reemplaza tu criterio. Vos seguís siendo quien decide qué va y qué no va en tu código ✅

GitHub Codespaces

GitHub Codespaces es un entorno de desarrollo en la nube, basado en Visual Studio Code. ¿Qué significa esto en la práctica?

No necesitás tener nada instalado localmente (ni Docker, ni PHP, ni MySQL).
Podés abrir un repositorio y en minutos tener un entorno listo para trabajar.
Todo corre en un contenedor remoto, pero vos lo ves y lo usás como si fuera tu editor local.

En esta charla, Codespaces va a ser:

El lugar donde levantamos nuestro proyecto vacío.
El entorno donde Copilot va a escribir código y configuraciones con nosotros.
El espacio desde el cual vamos a ejecutar Docker y probar nuestro WordPress de demo.
El lugar donde configuramos el famoso enfoque de “Docker outside of Docker” y automatizamos tareas con comandos post-create y post-start.

La combinación de GitHub + Copilot + Codespaces nos permite, básicamente, arrancar un proyecto completo desde cero usando solo el navegador, una cuenta gratuita y buenas ideas 💭🚀

💡 ¿Qué vamos a hacer en este workshop?

La idea de este workshop es que no te quedes solo mirando la pantalla, sino que puedas hacerlo en paralelo conmigo (o después, a tu ritmo). Vamos a ir de cero a tener:

Un entorno de desarrollo en la nube.
Un WordPress corriendo en Docker.
Un plugin propio en WordPress (no te preocupes, no necesitás conocer cómo hacerlo).
Y un workflow de CI que revise tu código.

Todo usando solo el navegador, GitHub, Copilot y Codespaces 🚀

💻 Mano a la obra: ¡a comenzar a trabajar!

1️⃣ ¡Creá (si no la tenés) tu cuenta en GitHub!

Si ya tenés cuenta en GitHub, este paso lo salteás. Si no, el primer paso es:

Registrarte con un mail válido en github.com
Verificar tu cuenta.
Iniciar sesión.

Con eso ya tenés tu “identidad” lista para crear repos, abrir Codespaces y usar Copilot 👤

2️⃣ Crear un repositorio vacío

Vamos a crear un nuevo repositorio, aunque inicializado con un README:

Vas a completar las siguientes opciones mínimas:

Nombre: el que quieras.
Add README: lo habilitarás.

Este repo va a ser el punto de partida de todo lo que hagamos durante el workshop 📦

¡Sigamos avanzando! 💪

3️⃣ Abrir el repo en un Codespace

En vez de clonar el repo en tu computadora, vamos a comenzar a utilizar Codespaces: ¡vas a poder interactuar con tu repo sin necesidad de instalar nada de forma local!

Para eso vamos a buscar la sección de código en tu branch principal, y allí encontrarás la opción “Codespaces” y la posibilidad de crear un “Codespaces on main”:

Cuando hagas un clic allí, se abrirá una nueva solapa indicando que se está configurando tu Codespace:

Y en pocos segundos tendrás un Visual Studio Online con tu repo, hasta ahora casi vacío, y una interfaz que seguramente te resultará familiar:

¡Excelente! Ya tenés un entorno en la nube, listo para utilizar, con tu repo. Si bien aún es super básico, has dado grandes pasos para llegar hasta aquí 🤓. Te recomendamos explorar un poco la interfaz y conocer sus detalles: es muy similar a un Visual Studio instalado localmente, aunque algunas opciones faltan.

¡Sigamos avanzando! ⏩

4️⃣ ¡Hola Copilot! Armemos nuestro entorno de WordPress

En este punto, vamos a terminar de configurar Copilot y le vamos a pedir que nos ayude a crear un entorno de WordPress con Docker Compose.

🔵 Set up de Copilot

Lo primero que vamos a tener que hacer es finalizar la configuración de Copilot. Para eso haremos clic en “Finish Setup” que encontrarás en la parte inferior de Codespaces:

Y luego vamos a hacer un clic en “Set up Copilot”:

Cuando termine de configurarse (tardará pocos segundos) nos daremos cuenta porque nuestro Chat (barra lateral en Codespaces) se completa con el MODO de funcionamiento y el MODELO:

🔵 Elección de modo de trabajo y modelo

Nosotros vamos a trabajar en modo “Agente”, lo que significa que Copilot no solo va a responderte texto en el chat, sino que va a poder “operar” sobre tu proyecto: proponer cambios de archivos, crearlos, editarlos, renombrarlos y hasta ayudarte a organizar la estructura del repo en varios pasos.

En otras palabras: en vez de ser solo “pregunta–respuesta”, el agente se comporta como un miembro más del equipo, que entiende el contexto del repositorio y te acompaña durante todo el flujo del workshop, manteniendo el hilo de lo que venimos construyendo 🤝

Con respecto al modelo, vamos a aprovechar los créditos gratuitos de Claude Sonnet 3.5 para esta demo:

¿Puedo usar otro? ¡Sí! Por supuesto. Podrás utilizar el que quieras y comparar su performance cuando repitas esta experiencia.

🔵 Armado de entorno con ayuda de Copilot

¡Muy bien! Ahora vamos a comenzar a utilizar Copilot como ayuda para crear nuestro entorno. En este entorno vamos a incluir:

WordPress (última versión)
MySQL 8
phpMyAdmin
Montaje de la carpeta plugins-demo
Variables de entorno, .gitignore, env.example, y mejoraremos el README.

En el espacio de chat, vamos a copiar y pegar el siguiente prompt:

Quiero que me ayudes a crear un entorno completo para desarrollar mis plugins de WordPress. Para eso te voy a pedir que me ayudes a crear lo siguiente:

1) Un docker-compose.yml que incluya los siguientes servicios:
- wordpress:latest,
- mysql:8,
- phpmyadmin:latest

2) Un archivo .env.example que tenga dentro el template de variables de entorno necesarias para que todo esto funcione, como por ejemplo:

- WP_DB_NAME
- WP_DB_USER
- WP_DB_PASSWORD
- WP_DB_ROOT_PASSWORD

Prefiero que las credenciales siempre sean wp, idem a la base de datos, asi no nos complicamos en nombres o caracteres.

3) Un .gitignore acorde al entorno

4) Mejorame el README.md que tengo para reflejar lo que estamos haciendo en este repo.

5) Como esto es un entorno de desarrollo para WordPress, montá ./plugins-demo en /var/www/html/wp-content/plugins, la idea es que todo plugin que se instale / cree aparezca en mi repo (por eso te pido montarlo).

6) Necesito que contemples los puertos 8080 (para WP) y 8081 (para phpMyAdmin).

Haceme cualquier otra pregunta que necesites para poder avanzar eficientemente en este pedido, sino comenzá la creación.

La idea es que veas cómo, con un buen prompt, Copilot puede generar gran parte de la estructura del proyecto por vos 💡. En pocos segundos verás como nuestro agente se pone a trabajar:

De a poco veremos como se van creando archivos en nuestro repo, y tendremos la opción de aceptarlos:

¡Aceptemos los cambios e inspeccionemos lo que hizo por nosotros! Siempre puede haber errores, aunque los mismos dependen de que tan claros y efectivos sea nuestro prompt.

🔵 ¿Y esto funciona? ¡Probemoslo!

Antes de probar si esto funciona, necesitamos crear nuestro archivos de environment. El repo tiene un .env.example, y vamos a copiarlo y renombrarlo para que Docker sepa que hacer. Ingresaremos esto en nuestra terminal de Visual Studio Online en Codespaces:

cp .env.example .env

Debe lucir así:

¡Ahora sí! Vamos a probar ejecutar nuestro entorno de WordPress, es decir vamos a ejecutar nuestro Docker Dompose. Pero para… ¿cómo? ¿vamos a ejecutarlo ahí mismo? ¡Sí! GitHub Codespaces nos permite ejecutarlo, sin instalar nada en forma local. Para eso vamos a ingresar lo siguiente en nuestra terminal:

docker-compose up -d

Veremos como rápidamente comienza a ejecutar docker-compose up:

Esperaremos unos minutos y tendremos (o deberíamso tener) nuestro entorno listo para ejecutar. Nos daremos cuenta porque figura lo siguiente:

[+] Running 5/5
 ✔ Network no-programas-solo_default         Created                                                      xxs 
 ✔ Volume "no-programas-solo_mysql_data"     Created                                                      xxs 
 ✔ Container no-programas-solo-mysql-1       Started                                                      xxs 
 ✔ Container no-programas-solo-wordpress-1   Started                                                      xxs 
 ✔ Container no-programas-solo-phpmyadmin-1  Started                                                      xxs

Y veremos los puertos redireccionados en la solapa “Ports”, recordando que el puerto 8080 es WordPress y el 8081 es MyPHPAdmin:

¡Vamos a probar abrir WordPress! Haremos clic en el ícono del navegador web sobre la redirección de WordPress:

En el navegador veremos (probablemente) el siguiente error 😥

Pero… ¿por qué pasó esto? Bueno, en realidad todo está funcionando, pero el sitio web intenta hacer una redirección al puerto 8080 en la URL (fijate el recuadro rojo que marqué más arriba). Esto es porque, naturalmente, WordPress arma sus URLs internas usando el HTTP_HOST tal como lo ve dentro del contenedor, incluyendo el puerto :8080. El problema es que en GitHub Codespaces ese puerto ya está “escondido” detrás del proxy y la URL pública no necesita ni acepta :8080 explícito.

Resultado: WordPress intenta redirigirte a una dirección que combina el dominio de Codespaces con un :8080 extra, y eso rompe la navegación y el certificado. Por eso necesitamos “normalizar” esas variables de servidor y forzar las URLs correctas para que todo funcione bien en este contexto 🌐

¡Vamos a arreglarlo!

🔵 ¡Corrijamos las variables faltantes!

Vamos a ingresar a nuestro docker-compose.yml y buscaremos la sección “environment” del servicio llamado “wordpress”:

Y allí abajo agregaremos lo siguiente en environment:

      WORDPRESS_CONFIG_EXTRA: |
        $$host = $$_SERVER['HTTP_X_FORWARDED_HOST'] ?? $$_SERVER['HTTP_HOST'];
        $$host = preg_replace('/:\d+$/', '', $$host);

        // Normalizar server vars para Codespaces
        $$_SERVER['HTTP_HOST'] = $$host;
        $$_SERVER['SERVER_NAME'] = $$host;
        $$_SERVER['HTTPS'] = 'on';
        $$_SERVER['HTTP_X_FORWARDED_PROTO'] = 'https';
        $$_SERVER['HTTP_X_FORWARDED_PORT'] = '8080';
        $$_SERVER['SERVER_PORT'] = 8080;

        // URLs base correctas (sin :puerto extra)
        define('WP_HOME',    'https://' . $$host);
        define('WP_SITEURL', 'https://' . $$host);

El cambio debería quedar así visualmente, en nuestro caso hemos sacado los guiones de las variables simples de environment para poder agregar el nodo de WORDPRESS_CONFIG_EXTRA:

Y el archivo completo (en código, porsi lo necesitás) es el siguiente:

version: '3'

services:
  wordpress:
    image: wordpress:latest
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: mysql
      WORDPRESS_DB_USER: ${WP_DB_USER}
      WORDPRESS_DB_PASSWORD: ${WP_DB_PASSWORD}
      WORDPRESS_DB_NAME: ${WP_DB_NAME}
      WORDPRESS_CONFIG_EXTRA: |
        $$host = $$_SERVER['HTTP_X_FORWARDED_HOST'] ?? $$_SERVER['HTTP_HOST'];
        $$host = preg_replace('/:\d+$/', '', $$host);

        // Normalizar server vars para Codespaces
        $$_SERVER['HTTP_HOST'] = $$host;
        $$_SERVER['SERVER_NAME'] = $$host;
        $$_SERVER['HTTPS'] = 'on';
        $$_SERVER['HTTP_X_FORWARDED_PROTO'] = 'https';
        $$_SERVER['HTTP_X_FORWARDED_PORT'] = '8080';
        $$_SERVER['SERVER_PORT'] = 8080;

        // URLs base correctas (sin :puerto extra)
        define('WP_HOME',    'https://' . $$host);
        define('WP_SITEURL', 'https://' . $$host);
    volumes:
      - ./plugins-demo:/var/www/html/wp-content/plugins
    depends_on:
      - mysql

  mysql:
    image: mysql:8
    environment:
      - MYSQL_DATABASE=${WP_DB_NAME}
      - MYSQL_USER=${WP_DB_USER}
      - MYSQL_PASSWORD=${WP_DB_PASSWORD}
      - MYSQL_ROOT_PASSWORD=${WP_DB_ROOT_PASSWORD}
    volumes:
      - mysql_data:/var/lib/mysql

  phpmyadmin:
    image: phpmyadmin:latest
    ports:
      - "8081:80"
    environment:
      - PMA_HOST=mysql
      - PMA_USER=${WP_DB_USER}
      - PMA_PASSWORD=${WP_DB_PASSWORD}
    depends_on:
      - mysql

volumes:
  mysql_data:

¡Vamos a probarlo de nuevo! Ejecutaremos un docker-compose down, y luego un docker-compose up -d

docker-compose down
docker-compose up -d

¡Y ahora si! Volvemos a probar haciendo clic en el ícono del navegador web sobre la redirección de WordPress:

Y nos encontraremos con el asistente de configuración de WordPress funcionando muy bien:

🔵 ¡Configuramos WordPress!

Configuraremos nuestro WordPress completando el asistente y eligiendo una contraseña:

¡Listo! Tendremos WordPress ejecutándose en nuestro entorno de GitHub Codespaces listo apra iniciar sesión:

Y lo mejor: lo hemos hecho en gran parte con la asistencia de Copilot, aunque debimos hacer algunas correcciones para que funcione sin problemas. ¿Esto es malo? ¡No! Con esto reforzamos que Copilot es un copiloto, pero necesita supervisión y decisiones humanas, dado que es parte de nuestro equipo de desarrollo 😉.

Cuando inicies sesión, vas a ver tu panel de control de WordPress:

Y además, en tu Codespaces (repo) verás que se agregaron archivos en “plugins-demo” que corresponden a la instalación por defecto de WordPress:

¡Sigamos avanzando! 👉

5️⃣ ¡Hola Codespaces! Trabajemos en un entorno “Docker outside of Docker”

Hasta ahora usamos Codespaces casi como si fuera “una terminal remota con VS Code”. En este paso vamos a llevarlo un poco más lejos y convertirlo en un entorno de trabajo más automatizado.

La idea de “Docker outside of Docker” en Codespaces es:

Usar Docker desde dentro del Codespace.
Pero evitando que vos tengas que ejecutar manualmente siempre docker-compose up -d.
Y dejando que el entorno se prepare “solo” cada vez que se crea o se inicia.

🔵 Configurando `.devcontainer`

Vamos a crear la carpeta .devcontainer en nuestro repo, con un archivo devcontainer.json:

En este archivo vamos a:

Indicar la imagen/base que usamos en Codespaces.
Agregar un postCreateCommand para que, apenas se crea el Codespace:
- Se instalen las dependencias necesarias (si las hubiera).
- Se prepare el entorno.
Agregar un postStartCommand para que, cada vez que se inicie el Codespace:
- Se ejecute docker-compose up -d (o el comando equivalente que definamos).

El contenido del archivo debe quedar así:

{
  "name": "WP Demo (Docker Compose)",
  "features": {
    "ghcr.io/devcontainers/features/docker-outside-of-docker:1": {}
  },

  // 1) Sólo prepara .env en la creación
  "postCreateCommand": "[ -f .env ] || cp .env.example .env",

  // 2) Al iniciar el Codespace, espera al daemon y levanta Compose
  "postStartCommand": "bash -lc 'for i in {1..10}; do docker version && break || sleep 3; done; docker compose up -d'",
  "postStartCommand": "bash -lc 'source /usr/local/share/docker-init.sh && for i in {1..10}; do docker version && break || sleep 3; done; for i in {1..3}; do docker compose up -d && break || sleep 5; done'",


  "forwardPorts": [8080, 8081],
  "portsAttributes": {
    "8080": { "label": "WordPress" },
    "8081": { "label": "phpMyAdmin" }
  },
  "customizations": {
    "vscode": { "extensions": ["ms-azuretools.vscode-docker"] }
  }
}

🔵 ¿Qué contiene este archivo?

Este devcontainer.json es, básicamente, el “cerebro” de tu entorno en Codespaces. Le dice a GitHub cómo armar y comportarse cada vez que abrís este repo en un Codespace. Veamos, en criollo, qué hace cada parte:

"name": "WP Demo (Docker Compose)"
Es solo el nombre “amigable” de tu entorno. Te ayuda a identificarlo cuando tengas varios Codespaces.
"features": { "ghcr.io/devcontainers/features/docker-outside-of-docker:1": {} }
Acá estamos diciendo: “Quiero que este Codespace tenga soporte para Docker outside of Docker.”
Es lo que habilita que podamos usar Docker y Docker Compose desde adentro del Codespace, sin tener que instalar nada extra a mano.
"postCreateCommand": "[ -f .env ] || cp .env.example .env"
Este comando se ejecuta una sola vez, cuando el Codespace se crea por primera vez.
¿Qué hace?
- Si ya existe un .env, no toca nada.
- Si no existe, copia automáticamente .env.example a .env.
  Resultado: siempre tenés tu archivo de variables listo, sin tener que acordarte de crearlo ✅
"postStartCommand": "bash -lc 'source /usr/local/share/docker-init.sh && for i in {1..10}; do docker version && break || sleep 3; done; for i in {1..3}; do docker compose up -d && break || sleep 5; done'"
Este comando se ejecuta cada vez que el Codespace arranca.
En resumen:
- Espera a que Docker esté listo.
- Intenta levantar los contenedores con docker compose up -d.
- Reintenta un par de veces si algo tarda un poquito.
  Resultado: cuando entrás al Codespace, tu entorno ya está levantado o en proceso de levantarse, sin que tengas que escribir el comando a mano 👌
"forwardPorts": [8080, 8081]
Le dice a Codespaces qué puertos queremos exponer:
- 8080 → WordPress
- 8081 → phpMyAdmin
"portsAttributes": { "8080": { "label": "WordPress" }, "8081": { "label": "phpMyAdmin" } }
Esto no cambia el funcionamiento técnico, pero mejora mucho la experiencia:
en la pestaña Ports vas a ver cada puerto con un nombre claro, en vez de solo un número.
"customizations": { "vscode": { "extensions": ["ms-azuretools.vscode-docker"] } }
Acá le pedimos a Codespaces que instale automáticamente la extensión de Docker para VS Code, para tener:
- Vista de contenedores.
- Imágenes.
- Logs.
  Todo integrado en la interfaz del editor.

💡 En conclusión rápida: este archivo hace que tu Codespace no sea “solo un editor remoto”, sino un entorno inteligente, que:

Prepara las variables de entorno.
Espera a Docker.
Levanta Docker Compose.
Expone los puertos correctos con nombres claros.
Y te instala las herramientas que necesitás.

Todo eso para que vos te puedas concentrar en desarrollar plugins y jugar con Copilot, y no en acordarte de comandos y configuraciones cada vez que abrís el repo 🚀

🔵 Rebuild de GitHub Codespaces para ver los cambios

Vamos a apretar Control + Shift + P (si estás en Windows) para hacer un Rebuild de nuestro GitHub Codespaces, y buscaremos el comando “Rebuild”:

¿Qué hace esto? Básicamente, le estamos diciendo a Codespaces: “📦 Volvé a crear el entorno desde cero usando la configuración nueva del .devcontainer.”

Cuando hacés un Rebuild:

Codespaces relee el devcontainer.json.
Reconstruye la imagen y aplica las features (en nuestro caso, Docker outside of Docker).
Vuelve a ejecutar el postCreateCommand y el postStartCommand según corresponda.
Te deja el entorno limpio, actualizado y alineado con la última configuración que definiste.

Es como apagar y volver a encender la máquina… pero con la garantía de que se va a levantar siguiendo exactamente las reglas que acabás de escribir ⚙️🚀.

Elegirás la opción “Full Rebuild” para volver a comenzar:

Y luego verás como comienza el reinicio y reconfiguración completa, la cual tardará unos minutos:

Cuando termine, verás algo similar a esto:

🔵 ¡Volvamos a probar WordPress!

Luego del Rebuild, volverás a probar ingresar a WordPress como lo has hecho antes:

🎈 IMPORTANTE: no te olvides que todo puede fallar. Si encontrás un error en el rebuild, volvelo a hacer. Y por otro lado, deberás volver a configurar tu WordPress, dado que hiciste un full rebuild y ya no tienes los datos de MySQL en tu codespaces.

6️⃣ Copilot Instructions para el proyecto

Hasta ahora Copilot nos viene ayudando con lo que ve “en el momento”: el archivo abierto, algo del repo y el prompt que le escribís. Con Copilot Instructions para el proyecto vamos a hacer algo así como:

“Sentate, Copilot, que te voy a contar de qué trata este repo y cómo quiero que trabajes acá adentro.”

🔵 ¿Qué es Copilot Instructions?

Copilot Instructions son instrucciones persistentes que le dan contexto extra a Copilot sobre tu proyecto.
No es un mensaje suelto en el chat, sino una especie de guía de comportamiento para ese repo.

Sirve para decirle cosas como:

De qué trata este repositorio.
Qué tecnologías usamos.
Qué carpetas son importantes.
Qué estilo y buenas prácticas queremos seguir.

A partir de ahí, cada vez que Copilot te ayude, va a tener todo eso en mente 🧠

🔵 ¿Cómo lo configuramos en este workshop?

Dentro de Codespaces / VS Code, vamos a:

Abrir el panel de GitHub Copilot (barra lateral).
Buscar la parte de configuración y elegir la opcion “Instructions”:

Esto abrirá una sección en VS Code donde te da la posibilidad de crear un nuevo archivo de instrucciones:

Te preguntará donde crearlo, elegirás en ./gitthub/instructions”:

Te pedirá un nombre, y le pondrás “plugins”:

Una vez creado, elegirás el contexto en tu chat incluyendo el archivo recién creado de instructions:

🔵 Completar las instrucciones con Copilot

Ahora que tenemos el archivo de instrucciones generado, vamos a completarlo. Vamos a utilizar a Copilot para poder hacerlo, e ingresarás el siguiente prompt (o uno similar que quieras ingresar) para poder hacer y cumplir esta tarea:

Quiero que completes el archivo de instrucciones de este proyecto que tengo abierto.

Este repositorio es un ambiente de demo para desarrollar y probar plugins de WordPress dentro de GitHub Codespaces, usando Docker Compose. Por favor:

1. Analizá el repositorio (especialmente docker-compose.yml, .devcontainer y la carpeta plugins-demo) para entender el entorno.

2. Escribí una explicación breve (en español) de:
a. Que este proyecto corre WordPress en Docker (con MySQL y phpMyAdmin).
b. Que se usa GitHub Codespaces como entorno de desarrollo.
c. Que todos los plugins personalizados deben ir en la carpeta plugins-demo.

3. Definí un estándar simple para los plugins de WordPress que creemos en este repo, usando solo 5 bullets, por ejemplo:
a. Archivo principal con encabezado de plugin válido (nombre, descripción, autor, versión).
b. Código dentro de funciones o clases con prefijo único, evitando el espacio global.
c. Comentarios en inglés.
d. Uso de funciones de traducción __() o _e() para textos visibles.
e. Buenas prácticas básicas de seguridad de WordPress (sanitizar y escapar valores).

Cuando finalice, tendrás tu archivo de instrucciones completado según las instrucciones ingresadas en el chat:

¡Sigamos avanzando!

7️⃣ Creando un Plugin de WordPress con ayuda de Copilot

Ahora que tenemos el entorno funcionando y las instrucciones de proyecto listas, vamos a crear nuestro primer plugin de demo: “Hola Copilot” 🎉

La idea del plugin es muy sencilla:

Mostrar un saludo y un agradecimiento por haber hecho este workshop.
Tener una página de configuración en el admin de WordPress.
Permitir que el usuario escriba su nombre.
Si hay nombre: “Hola, [tu nombre]. Gracias por ser parte de este workshop con GitHub Copilot y Codespaces 🚀”
Si no hay nombre configurado: “Hola. Gracias por ser parte de este workshop con GitHub Copilot y Codespaces 🚀”

🔵 Creación del plugin

Para crearlo, dentro de la carpeta plugins-demo, le podemos pedir algo así a Copilot en el chat:

Creá un plugin de WordPress llamado ‘Hola Copilot’ dentro de plugins-demo en el repo.
El plugin debe tener:

Un shortcode para agregar a posts.

Un archivo principal con encabezado de plugin válido.

Una página de configuración en el admin para guardar un nombre (es decir una variable).

Un mensaje que salude usando ese nombre si existe, o un mensaje genérico si no.

Valida que no hay problemas de permisos en la carpeta para crear el plugin, y si lo hay arreglalo.

Una vez ingresado el pedido, aguardaremos unos minutos que termine su creación por el copiloto. Notarás que probablemente te solicite permisos para ejecución de ciertas opciones, por la nauraleza de nuestro pedido:

Cuando termine, vamos a ver que tenemos un nuevo pluigo plugin creado y listo para activar.

🔵 Activación del plugin

En WordPressVamos a activar el plugin desde la página de plugins:

Y luego buscaremos la opción del plugin. En nuestro caso, está dentro de Settings:

🔵 Uso del Plugin

Vamos a usar el plugin dentro de un post. Vamos a utilizar el shortcode, que en nuestro caso es [hola_copilot]. No sabes el tuyo? Preguntale al chat!

Vamos a editar el post predeterminado de “Hello world”:

Agregarás el shortcode:

¡Y listo! Podemos ver como queda:

🔵 Mejora del Plugin

Si no nos gusta como qquedó el plugin (como en nuestro caso), podemos mejorarlo con un pedido en nuestro chat:

El plugin está bien pero quiero que sea mas colorido, contenido centrado y agradeciendo por participar en el workshop de GitHub Copilot y GitHub Codespaces. Un estilo festivo, con emoticones.

Y, en nuestro caso, el resultado fue mejor:

Cerramos el ejercicio con un plugin funcional creado en equipo entre vos y Copilot 💪

🚀 Conclusiones y cierre: ¡dejame feedback!

Si llegaste hasta acá, ya viste que no programás solo… pero tampoco programás “en automático”.
Durante este workshop trabajamos con GitHub Copilot y GitHub Codespaces para:

Crear un entorno completo de desarrollo con Docker.
Levantar WordPress y phpMyAdmin sin instalar nada localmente.
Configurar instrucciones para que la IA entienda mejor nuestro proyecto.
Crear un plugin simple (Hola Copilot) pensado para aprender, probar y experimentar.

Pero lo más importante no es la herramienta, sino cómo la usamos.

🧠 La IA no te reemplaza: te complementa

Si hay una idea que quiero que te lleves es esta:

Copilot no viene a reemplazarte. Hoy viene a complementarte.

Podés pensarlo como:

Tu pair programming: alguien que propone código, pero vos decidís qué se acepta y qué no.
Un acelerador de tareas repetitivas, no un reemplazo de tu criterio.
Un asistente que puede escribir, pero que necesita que vos seas clarísimo en las descripciones funcionales.

Cuanto mejor describís:

Qué querés lograr,
Qué restricciones tenés,
Qué estándar querés seguir,

El prompt es parte del diseño funcional. No es magia, es comunicación.

☁️ Codespaces: se termina el “en mi máquina funciona”

Con GitHub Codespaces vimos que:

Podemos tener un entorno estandarizado para todo el equipo.
El devcontainer y el docker-compose son nuestra “receta” compartida.
Se termina el clásico “a mí me anda, en tu máquina no sé”.

Un Codespace bien configurado significa:

Mismo entorno,
Mismos puertos,
Mismo flujo de trabajo,

Eso baja fricción y nos permite enfocarnos en diseñar soluciones, no en pelear con instalaciones.

🏦 ¿Y qué estamos haciendo en MODO con todo esto?

En MODO estamos en plena revolución cultural hacia un enfoque AI First.

Eso significa:

Todos los chapters y equipos están explorando cómo usar IA en su día a día.
No solo para “jugar” con código, sino para:
- Automatizar procesos y flujos de negocio.
- Reducir tareas repetitivas.
- Mejorar tiempos de entrega y calidad.
El uso de IA es consciente y construido en equipo, no algo aislado de una sola persona.

Queremos innovar, sí, pero:

Cuidando la seguridad de la información.
Manteniendo la consistencia de nuestras soluciones.
Alineados a los estándares técnicos y de negocio.

📏 ¿Cómo sabemos si lo estamos haciendo bien? Métricas y seguimiento

No alcanza con decir “usamos IA”. Tenemos que poder medir cómo la estamos usando.
Algunas métricas que miramos (o deberíamos mirar cada vez más) son:

Usuarios que usan directamente herramientas de IA (como Copilot).
Pull Requests asistidos por IA.
Líneas de código generadas por IA, pero siempre contrastadas con:
- Calidad,
- Cobertura de tests,
- Vulnerabilidades.
Impacto en las métricas DORA (lead time, frecuencia de despliegues, MTTR, change fail rate).

La idea es que la IA no solo “escriba más rápido”, sino que nos ayude a:

Entregar mejor.
Aprender más.
Fallar menos (y recuperar más rápido cuando fallamos).

💬 Tu feedback importa

Este workshop y este post son parte de un camino. Si algo de lo que vimos te sirvió, te disparó ideas o te gustaría profundizar en alguna parte (más demos, más métricas, más prácticas de AI First), contame.

0 0 votes

Article Rating