# Deploy — Gestionale Orto & Animali

Deploy **incrementale** verso l'hosting OVH (subdomain), eseguito **in locale**.
In produzione non c'è SSH né compilazione: si caricano solo i file risultanti.

## Prerequisiti (in locale)
- PHP CLI, Composer, **Tailwind CLI standalone** (`tailwindcss` nel PATH).
- Per SFTP: nessuna estensione richiesta (si usa `phpseclib3`, dev-dependency già
  installata). Per FTPS: estensione PHP `ext-ftp`.

## Configurazione (`.env`)
```
DEPLOY_PROTOCOL=sftp           # sftp | ftps | local
DEPLOY_HOST=ftp.<dominio-ovh>
DEPLOY_PORT=22                 # 22 sftp, 21 ftps
DEPLOY_USER=...
DEPLOY_PASS=...
DEPLOY_REMOTE_PATH=/home/<sito>/www   # document root del subdomain
```
> `local` copia i file in `DEPLOY_REMOTE_PATH` sul filesystem locale: utile per
> test o per generare una cartella di staging da caricare a mano.

## Uso
```bash
php deploy/deploy.php            # build + upload incrementale
php deploy/deploy.php --dry-run  # mostra cosa verrebbe caricato (nessun build, nessun upload)
php deploy/deploy.php --full     # forza l'upload completo (ignora il manifest)
php deploy/deploy.php --no-build # salta composer/tailwind, carica i file così come sono
```

## Cosa fa
1. `composer install --no-dev --optimize-autoloader`
2. build Tailwind → `public/assets/app.css` minificato
3. calcola lo `sha1` di ogni file e lo confronta con **`deploy/manifest.json`**:
   carica **solo i file cambiati o nuovi**. Primo deploy (manifest assente) o
   `--full` = upload completo, **`vendor/` incluso**.
4. aggiorna `deploy/manifest.json` con lo stato caricato.

## Cosa viene caricato / escluso
**Incluso:** `public/`, `src/`, `templates/`, `vendor/`, `database/`,
`composer.json`, `composer.lock`, `.env.example`, e i `.gitkeep` di `storage/`
(per creare le cartelle in produzione).

**Escluso:** `.env` (mai sovrascrivere quello di produzione), `.git/`,
`node_modules/`, `deploy/`, `tests/`, sorgenti Tailwind (`assets/`, `tailwind.config.js`),
documentazione di sviluppo (`*.md` di root), e i **contenuti runtime** di
`storage/` (`uploads/`, `logs/`, `cache/`) — così gli allegati e i log di
produzione non vengono toccati.

> Lo script **non cancella** file dal remoto: rimuovere a mano gli eventuali file
> non più necessari.

## Migrazioni DB
Le migrazioni **non** vengono applicate dallo script. In produzione si incolla
l'SQL in **phpMyAdmin** nell'ordine indicato in
`database/migrations/CHANGELOG.md` (prima le migrazioni, poi i seed).

## Note
- Dopo un deploy con build, `vendor/` resta in modalità `--no-dev`: per
  ripristinare gli strumenti di sviluppo in locale esegui di nuovo
  `composer install`.
- Proteggere in produzione (via `.htaccess` o document root dedicata) le cartelle
  non pubbliche: `/src`, `/templates`, `/vendor`, `/database`, `/storage`, e il file `.env`.