Deploy di un’applicazione Symfony

Nota

Il deploy può essere un’attività complessa e variegata, a seconda dell’ambiente e delle necessità. Questa ricetta non vuole essere esaustiva, ma offrire le idee e i requisiti più comuni per il deploy.

Basi per i deploy su Symfony

I tipici passi durante il deploy di un’applicazione Symfony includono:

  1. Caricare il nuovo codice su un server;
  2. Aggiornare le dipendenze (tipicamente eseguito tramite Composer, potrebbe anche essere fatto prima di caricare);
  3. Eseguire le migrazioni della base dati, oppure compiti simili, per aggiornare strutture dati modificate;
  4. Pulire (e forse più importante, scaldare) la cache.

Un deploy può anche includere altro, come:

  • Assegnazione di un tag a una versione del codice, come rilascio nel proprio repository di gestione dei sorgenti;
  • Creazione di un’area di stage temporanea, per costruire il proprio ambiente aggiornato “offline”;
  • Esecuzione dei test disponibili, per assicurarsi la stabilità del codice e/o del server;
  • Rimozione dei file non necessari da web, per mantenere pulito l’ambiente di produzione;
  • Pulizia dei sistemi di cache esterni (come Memcached o Redis).

Come eseguire il deploy

Ci sono molti modi per eseguire il deploy di un’applicazione Symfony. Meglio iniziare con poche strategie di base e poi incrementare.

Trasferimento semplice di file

La forma più semplice di deploy consiste nel copiare i file manualmente tramite ftp/scp (o metodi simili). Ci sono degli svantaggi, perché manca il controllo sul sistema mentre l’aggiornamento è in corso. Questo metodo inoltre richiede di eseguire dei passi manuali dopo il trasferimento dei file (vedere Azioni comuni post-deploy)

Uso di un controllo dei sorgenti

Se si usa un controllo dei sorgenti (come Git o SVN), si può semplificare rendendo l’installazione una copia del repository. Quando si è pronti per aggiornare, basta recuperare l’ultimo aggiornamento dal sistema di controllo dei sorgenti.

Questo rende l’aggiornamento più facile, ma occorre ancora prendersi cura di alcuni passi in modo manuale (vedere Azioni comuni post-deploy).

Uso di script e di altri strumenti

Ci sono alcuni strumenti di alta qualità, che facilitano i deploy. Alcuni di questi sono stati adattati in modo specifico ai requisiti di Symfony.

Capifony
Fornisce un insieme specializzato di strumenti basati su Capistrano, adattati in modo specifico per i progetti symfony e Symfony.
sf2debpkg
Aiuta a costruire un pacchetto Debian nativo per un progetto Symfony.
Magallanes
Simile a Capistrano, ma scritto in PHP, potrebbe essere più facile per uno sviluppatore PHP da estendere in base alle necessità.
Fabric
Questa libreria, scritta in Python, fornisce un insieme basilare di operazioni per eseguire comandi da terminale in locale o in remoto, nonché caricamento e scaricamento di file.
Bundle
Ci sono molti bundle che aggiungono strumenti di deploy direttamente alla console di Symfony.
Script di base
Ovviamente si può usare il terminale, Ant o altri strumenti di script per il deploy di un progetto.
Fornitori di PaaS

Il ricettario di Symfony include varie ricette per alcuni dei più noti fornitori di PaaS:

Azioni comuni post-deploy

Dopo il deploy del codice sorgente, ci sono alcune azioni comuni che occorrerà intraprendere:

A) Verificare i requisiti

Verificare che il server soddisfi i requisiti, eseguendo:

$ php app/check.php

B) Configurare il file app/config/parameters.yml

Questo file non dovrebbe essere incluso nel deploy, ma gestito tramite utilità automatiche fornite da Symfony.

C) Aggiornare i venditori

I venditori possono essere aggiornati prima del trasferimento del codice (aggiornando la cartella vendor/, quindi trasferendola insieme al codice sorgente) oppure successivamente. In ogni modo, aggiornare i venditori come si fa normalmente:

$ composer install --no-dev --optimize-autoloader

Suggerimento

L’opzione --optimize-autoloader rende l’autoloader di Composer più performante, costruendo una “mappa di classi”. L’opzionoe --no-dev assicura che i pacchetti di sviluppo non siano installati in ambiente di produzione.

Attenzione

Se si ottiene un errore “class not found”, potrebbe essere necessario eseguire export SYMFONY_ENV=prod in precedenza, in modo che gli script post-install-cmd girino in ambiente prod.

D) Pulire la cache di Symfony

Assicurarsi di pulire (e riscaldare) la cache di Symfony:

$ php app/console cache:clear --env=prod --no-debug

E) Esportare le risorse di Assetic

Se si usa Assetic, si vorranno esportare le risorse:

$ php app/console assetic:dump --env=prod --no-debug

F) Altre cose!

Ci possono essere molte altre cose che si potrebbe dover fare, a seconda dell’ambiente:

  • Eseguire migrazioni sulla base dati
  • Pulire la cache di APC
  • Eseguire assets:install (già compreso in composer.phar install)
  • Aggiungere/modificare script in cron
  • Inviare risorsa a un CDN
  • ...

Ciclo di vita dell’applicazione: integrazione continua, QA, ecc.

Sebbene questa ricetta copra i dettagli tecnici del deploy, l’intero ciclo di vita del portare codice da sviluppo a produzione potrebbe avere molti passi ulteriori (si pensi al deploy in stage, QA, esecuzione di test, eccetera).

L’uso di stage, test, QA, integrazione continua, migrazioni di basi dati e la capacità di tornare indietro in caso di fallimento sono caldamente consigliati. Ci sono strumenti semplici e più complessi e si può rendere il deploy semplice (o sofisticato) quanto si vuole

Non dimenticare che il deploy di un’applicazione coinvolge anche l’aggiornamento di ogni dipendenza (tipicamente via Composer), migrazioni della base dati, pulizia della cache e altre possibili questioni, come inviare risorse a un CDN (vedere Azioni comuni post-deploy).