Llevar un proyecto PHP desde tu máquina local hasta un servidor público puede sonar complejo, pero con Heroku el proceso se reduce a unos cuantos comandos y clics. A continuación se explica cómo preparar las variables de producción, subir datos a una base de datos remota y publicar una aplicación funcional en minutos.

¿Cómo preparar las variables de entorno para producción?

El primer paso consiste en separar la configuración local de la de producción. A partir del archivo de variables locales que ya existía, se crea una copia específica para producción [01:15]. Con el comando cp variables_local variables_prod.sh se genera el nuevo archivo y se edita con los datos reales del servidor remoto: host, nombre de la base de datos, usuario, contraseña y puerto.

Para los valores sensibles como el salt —la cadena aleatoria que refuerza la seguridad de contraseñas y tokens— se recurre a un generador como Random.org [02:05]. Se concatenan varias cadenas y se cierra con un carácter especial para obtener un salt robusto. Una vez guardado, se cargan las variables con source local/variables_prod.sh, lo que sobreescribe las variables de la sesión actual.

¿Cómo verificar que las variables están activas?

Basta con ejecutar echo $SALT para confirmar que la terminal ya trabaja con los valores de producción [02:50]. Si el valor mostrado coincide con el que se configuró, todo está listo para conectarse a la base de datos remota.

¿Cómo poblar la base de datos de producción con datos existentes?

Con la conexión apuntando al servidor remoto, se ejecuta el esquema SQL que define las tablas del proyecto [03:20]. Pueden aparecer errores por caracteres especiales del copy-paste, pero se corrigen manualmente. Una vez creadas las tablas, el comando show tables confirma que la estructura existe y SELECT * FROM books muestra que aún está vacía.

Para cargar los datos se utiliza el script Platzibooks, que lee un archivo CSV, crea autores y libros, y los inserta uno a uno en la base de datos [04:15]. El proceso es más lento que en local porque la latencia de red influye, pero al finalizar se verifican 215 libros y 150 autores en producción [05:40].

¿Qué es el Procfile y por qué Heroku lo necesita?

El Procfile es un archivo que se coloca en la raíz del proyecto y le indica a Heroku qué stack tecnológico usar y hacia dónde apuntar el servidor web [07:30]. Para un proyecto PHP con Apache, su contenido es:

web: vendor/bin/heroku-php-apache2 web/

Esta única línea crea un servidor Apache que sirve el directorio web/. Después de añadirlo al repositorio con git add Procfile y hacer push, el proyecto queda preparado para el despliegue.

¿Cómo crear y desplegar la aplicación en Heroku?

Desde el panel de Heroku se crea una nueva aplicación y se conecta al repositorio de GitHub donde vive el código [06:30]. La integración permite despliegues automáticos o manuales.

Antes de lanzar, se registran las variables de configuración en la sección Settings de Heroku [07:00]. Cada variable —DB_HOST, DB_USER, DB_PASS, DB_NAME, DB_PORT y SALT— se ingresa con su valor de producción. Heroku las inyecta como variables de entorno al momento de ejecutar la aplicación.

Al hacer clic en Deploy Branch, Heroku construye el proyecto usando el stack Heroku-22, instala las dependencias del composer y publica la aplicación [08:30]. Un error común aparece cuando las líneas de debug quedan activas: el módulo de depuración no existe en producción y el deploy falla [09:00]. La solución es comentar esas líneas en index.php, hacer commit y redesplegar. En aproximadamente quince segundos la aplicación queda en línea.

¿Qué pasa con el SSL en Heroku?

Durante las pruebas, el navegador puede advertir que el certificado SSL no es válido [10:50]. Esto ocurre porque no se configuró HTTPS en Heroku, algo que se resuelve con un solo clic en el panel. Mientras tanto, se puede continuar accediendo por HTTP para verificar la funcionalidad.

Tras crear un usuario, iniciar sesión y votar un libro, se confirma que login, registro, votación y consulta de promedios funcionan correctamente en producción [10:20].

El Active Record que utiliza el framework G2 demostró ser extremadamente eficiente: carga relaciones entre tablas, ejecuta queries complejos y popula objetos con rapidez [11:50]. Esa velocidad obliga a tener precaución con bases de datos muy grandes para no sobrecargar la memoria, pero representa un problema positivo porque evidencia el rendimiento del sistema.

Si ya probaste el despliegue o tienes alguna duda sobre la configuración de variables o el Procfile, comparte tu experiencia en los comentarios.