Qué significa realmente "desplegar desde Git"
Durante casi toda la historia del sector, desplegar significaba que una persona ejecutaba una secuencia a mano: construir en local, copiar ficheros a un servidor, ejecutar una migración, reiniciar un proceso y confiar en no haber olvidado nada. Cada paso era una oportunidad de hacerlo un poco distinto a la vez anterior — y la diferencia entre "en mi máquina funciona" y un sitio de producción roto vivía justo en esos pasos.
El despliegue desde Git sustituye esa secuencia por una regla: la rama es la fuente de verdad, y lo que hay en ella es lo que se ejecuta. No subes nada. Haces push y la plataforma repite la misma construcción exactamente igual, siempre. La repetibilidad es el objetivo — no la comodidad.
Qué pasa entre tu push y la aplicación en vivo
La cadena es corta y conviene conocerla, porque cuando algo va mal quieres saber qué eslabón mirar.
Tu push llega al repositorio, que nos avisa. Comprobamos si ese repositorio y esa rama concretos están conectados a una aplicación; si lo están, arranca una construcción. La construcción se ejecuta en un entorno aislado — tu código nunca comparte proceso con el de nadie más — y produce una imagen de contenedor a partir de tu Dockerfile. Solo cuando la imagen está lista la plataforma arranca la nueva versión y retira la anterior. Si la construcción falla, no se reemplaza nada: la versión anterior sigue sirviendo tráfico, que es justo el comportamiento que quieres a las 2 de la madrugada.
El acceso es efímero por diseño: la credencial que se usa para leer tu repositorio se genera en el momento del despliegue en lugar de almacenarse, así que no hay un token guardado en nuestra base de datos que pueda sobrevivir a su utilidad.
Qué necesita tu repositorio
Una cosa, sobre todo: un **Dockerfile**. Es la receta que convierte tu código fuente en una imagen ejecutable — imagen base, dependencias, paso de construcción y comando de arranque. Si tu proyecto todavía no lo tiene, escribirlo es una tarea de una sola vez y el mismo fichero te sirve en tu portátil.
Dos detalles son los que más tiempo ahorran. Primero, tu aplicación debe escuchar en el puerto que le indicaste a la plataforma, y en todas las interfaces (`0.0.0.0`) y no solo en `localhost` — un contenedor que se ata a localhost es inalcanzable desde fuera de sí mismo. Segundo, todo lo secreto (URLs de base de datos, claves de API) va en variables de entorno, no dentro de la imagen: las imágenes se reconstruyen y se mueven de un sitio a otro, y un secreto incrustado en una es un secreto que no puedes rotar.
Un proyecto multiservicio funciona igual a través de un fichero Compose — cada servicio que no tenga una imagen ya construida necesita un Dockerfile construible, y la pila levanta ya conectada entre sí.
Ramas: mantén producción lejos de tu trabajo diario
Aquí es donde los equipos se hacen daño, y la solución es una decisión más que una funcionalidad. Si producción está conectada a la rama en la que desarrollas, cada commit a medias se publica. Conecta producción a una rama en la que solo fusiones cuando de verdad quieras — habitualmente `main` mientras el trabajo diario ocurre en ramas de funcionalidad, o una rama `production` dedicada si `main` es donde iteras.
La prueba mental útil: "si hago push ahora mismo, ¿me quedo tranquilo con que los visitantes lo vean?". Si la respuesta es no alguna vez para la rama conectada, la rama está mal, no el proceso.
Un flujo de publicación que mantiene producción aburrida
# gundelik is: feature dalinda
git checkout -b feature/yeni-fiyatlandirma
git commit -am "pricing page"
git push origin feature/yeni-fiyatlandirma # deploy TETIKLEMEZ
# yayina hazir oldugunda
git checkout main
git merge feature/yeni-fiyatlandirma
git push origin main # deploy BU push ile baslarCuando un push no aparece
El despliegue parece magia hasta que en silencio no hace nada, así que diagnostica en el mismo orden en que corre la cadena.
Empieza por el final: ¿llegó a arrancar alguna construcción? Si no aparece ninguna construcción para tu push, el eslabón roto es la conexión — el repositorio o la rama no son los que están conectados, o la integración perdió el acceso (una instalación revocada, un repositorio renombrado o transferido). Si una construcción arrancó y falló, el log de construcción te dice exactamente dónde; las causas más habituales son un paso del Dockerfile que funciona en local gracias a un fichero que tu `.dockerignore` excluye, o una instalación de dependencias que necesita una credencial que la construcción no tiene. Si la construcción salió bien pero sigues viendo la versión anterior, casi con seguridad estás viendo una respuesta cacheada y no una aplicación desactualizada — pide la página con un rompecachés o mira la cabecera de estado de caché antes de sospechar del despliegue.
Un caso poco obvio que conviene conocer: volver a lanzar un despliegue para un commit que ya falló no lo arregla por sí solo. El commit es la entrada; si la entrada no cambia, el resultado tampoco. Haz push de una corrección — aunque sea un commit vacío — en lugar de reintentar el mismo.
Consultar el estado y forzar un despliegue desde la terminal
# calisan uygulamanin durumu
cdnctl container apps list --account <uuid>
# son deploy ne yapti
cdnctl container apps logs --account <uuid> --app <app_uuid>
# elle yeniden dagit (ayni commit)
cdnctl container apps deploy --account <uuid> --app <app_uuid>Lo que ganas cuando se vuelve aburrido
La verdadera recompensa del despliegue desde Git no es la velocidad, es que desplegar deja de ser un acontecimiento. Cuando publicar es un push, los cambios pequeños salen por su cuenta en lugar de acumularse en una entrega mensual arriesgada — y los cambios pequeños son los que puedes depurar, porque cuando algo se rompe sabes exactamente qué commit lo hizo.
También convierte la vuelta atrás en una operación normal en vez de una emergencia: la imagen anterior sigue ahí, y volver a ella es un despliegue como cualquier otro. Los equipos que publican a diario no son más valientes que los que publican una vez al mes; simplemente han hecho que cada despliegue individual sea lo bastante pequeño como para resultar poco interesante.
Preguntas frecuentes
¿Necesito un Dockerfile o la plataforma puede adivinar cómo construir mi aplicación?
Necesitas un Dockerfile. No adivinamos una construcción por ti — el fichero es explícito sobre la imagen base, las dependencias y el comando de arranque, que es justo por lo que la construcción es reproducible. El mismo fichero construye igual en tu máquina.
¿Qué le pasa a la aplicación en ejecución mientras se construye una nueva versión?
Sigue sirviendo. La nueva versión reemplaza a la anterior solo después de que la imagen se haya construido correctamente; una construcción fallida deja producción exactamente como estaba.
¿Puedo desplegar sin hacer push, por ejemplo para volver a lanzar la última versión?
Sí. Un despliegue se puede lanzar a mano desde el panel o con cdnctl, usando el mismo commit. Es útil después de cambiar una variable de entorno, que no crea un commit nuevo.
¿Cómo mantengo los secretos fuera del repositorio?
Ponlos en variables de entorno de la aplicación, no en el Dockerfile ni en el código. Todo lo que se incrusta en una imagen viaja con esa imagen y no se puede rotar sin reconstruirla.
Hice push pero no pasó nada. ¿Dónde miro primero?
Comprueba si llegó a arrancar alguna construcción. Que no haya construcción indica un problema de conexión (rama equivocada, acceso revocado, repositorio renombrado). Una construcción fallida apunta al log de construcción. Una construcción correcta con un sitio que parece antiguo suele significar que estás viendo una respuesta cacheada.