Hosting y deploy
Lección 11 de 26 del curso «Vibe coding». Gratis, con animaciones y un test.
Hosting: una computadora que no duerme
Ejemplo: armaste con la IA un sitio para tu banda. Por ahora solo abre en tu laptop. Cierras la tapa y el sitio desaparece. El hosting es una computadora en la nube que está encendida día y noche y entrega tu sitio a cualquiera que abra el enlace. En el esquema es la nube con el servidor. No necesitas tu propio servidor: el servicio de hosting lo mantiene por ti.
Deploy: publicar una versión nueva
Deploy es publicar una versión nueva del sitio para que la gente la vea. Antes los archivos se subían al servidor a mano. Ahora es más fácil: conectas una vez tu repositorio de GitHub al hosting. Desde entonces, cada push a main, o sea enviar commits a la rama principal, lanza el deploy solo. En el esquema la flecha va de GitHub, pasa por el build y llega al sitio en vivo. Subiste fotos del concierto, hiciste push y pronto el sitio se actualiza.
Build: del proyecto a archivos listos
El navegador solo entiende HTML, CSS y JavaScript. Pero un proyecto hecho con IA suele usar un framework, o sea un esqueleto listo con reglas cómodas, y hay que procesarlo. Eso es el build: el hosting ejecuta un comando de build, por ejemplo npm run build, y deja los archivos listos en una carpeta de salida, por ejemplo dist. La barra de progreso del esquema es este paso. Normalmente el hosting adivina solo esta configuración.
¿Falló el build? El sitio sigue vivo
Tranqui. Si el build falla con un error, el hosting no publica la versión rota. La gente sigue viendo la anterior, la que funciona: es la nota roja del esquema. Qué hacer: abre el log del build, el registro donde el hosting anota cada paso. Busca líneas rojas cerca del final. Copia el error completo y dáselo a la IA, como en la lección sobre cómo pedir tareas. Lo arreglas, haces push y el build arranca de nuevo.
Una vista previa por cada rama
¿Te acuerdas de las ramas y los Pull Request? Un hosting conectado a GitHub suele hacer el build de cada rama por separado y darle un enlace de vista previa: una copia del sitio que no toca el sitio en vivo. Ejemplo: en una rama pruebas una página nueva con las fechas de conciertos. Abres la vista previa en el celular y le pasas el enlace al baterista. A todos les gusta: haces merge a main y el sitio en vivo se actualiza solo.
Sitio estático o con servidor
Un sitio estático es solo frontend: páginas listas, iguales para todos. El sitio de una banda con fotos y fechas es justo así, y es el más fácil de hospedar. Si necesitas hacer algo oculto al navegador, como recibir inscripciones o guardar una clave de IA, te harán falta funciones de servidor: pequeñas piezas de backend que el hosting ejecuta cuando se las piden. Muchos hostings hacen las dos cosas.
Ponte a prueba
- ¿Qué es un deploy?
Respuesta correcta: Publicar una versión nueva del sitio para la gente. El deploy sube la versión nueva al hosting, donde todos la ven. Un commit solo la guarda en Git, y el dominio se compra aparte. - El build falló con un error. ¿Qué ven los visitantes?
Respuesta correcta: La versión anterior, que funcionaba. Un build roto no se publica, así que la versión anterior sigue en vivo. Tú lees el log y lo arreglas. - Quieres mostrarle a un amigo una página nueva sin tocar el sitio en vivo. ¿Qué usas?
Respuesta correcta: El enlace de vista previa de la rama. La rama tiene su propia copia del sitio en otro enlace. Un push a main cambiaría el sitio en vivo al instante.
← La terminal en 10 minutos Cloudflare: Pages, Workers y protección →