devops-deployer

Sebyone S.r.l. — https://sebyone.it · proprietary, © 2026 Sebyone S.r.l. Version 2.0.0 · Author: Paolo Lo Giacco p.logacco@sebyone.it

Strumento di deploy parametrico: un solo script, molti progetti, due runtime. Ogni progetto è descritto da un file di configurazione, e l'estensione del file decide come viene pubblicato:

Config	Modalità	Runtime
conf/<progetto>.dep	bare	app sul server (nginx + PHP-FPM / systemd)
conf/<progetto>.ddep	docker	app in container (Docker Compose)

./deployer.sh <progetto>              # deploy
./deployer.sh <progetto> --rollback   # torna al deploy precedente
./deployer.sh --update                # aggiorna lo strumento
./deployer.sh --help                  # tutti i comandi, autore e versione

Questo repository è la copia canonica dello strumento: le modifiche si fanno qui, e sui server si allineano con --update.

• docs/DEPLOYER.md — riferimento dello strumento: tutti i parametri, i profili STACK, i prerequisiti, troubleshooting, changelog.
• docs/ONBOARDING-PROGETTO.md — come rendere un nuovo progetto compatibile: cartelle, config, e i tool postdeploy / testenv da fornire.

---

Comandi e opzioni

<progetto> è il nome base della config, oppure il percorso a un file .dep/.ddep.

Comandi

Comando	Effetto
./deployer.sh <progetto>	Pubblica il progetto
./deployer.sh <progetto> --rollback	Ripubblica il commit del deploy precedente
./deployer.sh <progetto> --history	Mostra i deploy registrati e il target di --rollback
./deployer.sh --update	Aggiorna lo script stesso dal repository Sebyone
./deployer.sh --list	Elenca i progetti configurati con la loro modalità
./deployer.sh --help, -h	Riferimento completo: descrizione, autore, versione, licenza, comandi, passi, esempi
./deployer.sh --version, -v	Stampa la versione

Opzioni di deploy

Opzione	Modalità	Effetto
--no-db	entrambe	Aggiornamento di solo codice: salta i comandi marcati db: in POST_INSTALL/POST_UP (migrazioni, seed). Il database non viene toccato.
--no-git	entrambe	Pubblica il codice già su disco, senza fetch.
--no-rollback	entrambe	In caso di errore lascia l'albero alla versione fallita, invece di ripristinare il commit precedente (il default è ripristinare).
--dry-run	entrambe	Stampa i passi senza cambiare nulla.
--no-build	docker	Riavvia i container senza ricostruire l'immagine.

Le opzioni si possono combinare e stanno in qualunque posizione: ./deployer.sh shareforces --no-db --dry-run.

Un secondo --rollback va un passo più indietro, non torna al commit difettoso: il rollback viene registrato a sua volta nello storico. E il rollback ripristina solo il codice — le migrazioni non vengono annullate, va dichiarato in ROLLBACK_CMDS (vedi DEPLOYER.md).

Codici di uscita e variabili d'ambiente

Codice	Significato
0	Deploy (o rollback, update, list, help) riuscito
1	Errore: passo fallito, opzione sconosciuta, config non trovata
2	Invocazione senza progetto (stampa l'uso breve)

--help scrive su stdout ed esce 0, così si può passare a less o grep; l'uso breve degli errori va su stderr.

Variabile	Default	Significato
DEPLOYER_CONF_DIR	<script-dir>/conf	Cartella delle configurazioni
DEPLOYER_STATE_DIR	<script-dir>/.state	Storico dei deploy (serve a --rollback)

---

Novità della 2.0.0

La 2.0.0 unifica bare/deploy.sh (v1.10.0) e docker/ddeploy.sh (v1.0.0) in un unico deployer.sh, con una sola versione da tenere allineata:

• Un solo script, due modalità — l'estensione della config (.dep / .ddep) seleziona la modalità. Config, checkout git, rollback, --no-db, verifiche e --update sono codice condiviso: solo i passi specifici del runtime divergono.
• Rollback — se un passo fallisce dopo che il codice è stato sostituito, il commit che era in produzione viene ripristinato e rimesso in servizio. --rollback lo fa a richiesta, --history mostra i deploy registrati.
• --update — scarica l'ultima versione dello script dal repository Sebyone, la valida (shebang, sintassi, versione dichiarata) e la sostituisce tenendo un .bak. Un download troncato o una pagina d'errore non arrivano mai sul file in esecuzione.
• Docker: incongruenze risolte — PROJECT_ROOT ora è obbligatorio ed esplicito (la v1 lo indovinava come "3 livelli sopra lo script", che con lo strumento installato in /opt/deployer diventava /); l'.env può non essere richiesto (ENV_FILE_REQUIRED); build/up/post-up/healthcheck falliti fanno rollback; PROJECT_ROOT inesistente e compose mancante danno errori azionabili invece di comportamenti impliciti.
• HTTP_CHECK — verifiche fatte dall'host con curl, con retry: provano che il servizio risponde attraverso porta pubblicata, reverse proxy e TLS, cosa che un check dentro il container non può dimostrare. Disponibile in entrambe le modalità.
• --dry-run — stampa i passi senza cambiare nulla.

Migrare dalla 1.x

Le cartelle bare/ e docker/ non esistono più: script e template stanno in root. Sul server:

cd /opt/deployer
sudo wget -O deployer.sh \
  https://raw.githubusercontent.com/sebyone/devops-deployer/main/deployer.sh
sudo chmod +x deployer.sh
sudo mkdir -p conf
sudo mv bare/conf/*.dep docker/conf/*.ddep conf/ 2>/dev/null   # sposta le config
sudo rm -rf bare docker                                        # via il vecchio
./deployer.sh --list                                           # verifica

I .dep esistenti funzionano senza modifiche: stack, toggle DO_*, POST_INSTALL, VERIFY, WRITABLE_DIRS e RUNTIME_DIRS sono invariati, e il rollback è attivo di default senza dover configurare nulla.

I .ddep richiedono una modifica obbligatoria: aggiungere PROJECT_ROOT con il percorso assoluto del checkout del progetto. Senza, il deploy si ferma subito con un errore esplicito invece di risolvere i percorsi da /.

# nel .ddep, aggiungere:
PROJECT_ROOT="/opt/www/progetto"

Cambia anche il nome dei comandi: ./deploy.sh <p> e ./ddeploy.sh <p> diventano entrambi ./deployer.sh <p>.

---

Installazione sul server

sudo mkdir -p /opt/deployer/conf
cd /opt/deployer
sudo wget -O deployer.sh \
  https://raw.githubusercontent.com/sebyone/devops-deployer/main/deployer.sh
sudo chmod +x deployer.sh

Repository privato. sebyone/devops-deployer è privato: il wget diretto funziona solo se il file è raggiungibile (repo reso accessibile o URL con token). In alternativa, clona con una deploy key: git clone git@github.com:sebyone/devops-deployer.git /opt/deployer. Con un token: wget --header="Authorization: token <TOKEN>" -O deployer.sh <raw-url>. Lo stesso vale per --update: se il download restituisce una pagina HTML anziché lo script, viene rifiutato e lo strumento resta quello installato.

Verifica:

./deployer.sh --version    # deployer.sh v2.0.0 — Sebyone S.r.l.
./deployer.sh --help       # riferimento completo: comandi, opzioni, esempi
./deployer.sh --list       # elenco progetti configurati, con la loro modalità

Da qui in avanti aggiungi un file di configurazione per ogni progetto da pubblicare.

---

Strumento vs progetto

Lo strumento è generico e non contiene logica di un progetto specifico:

devops-deployer/
├── deployer.sh            lo script (unica versione, entrambe le modalità)
├── conf/
│   ├── example.dep        template bare — copialo in conf/<progetto>.dep
│   └── example.ddep       template docker — copialo in conf/<progetto>.ddep
├── docs/
│   └── DEPLOYER.md        documentazione completa + changelog
└── README.md

Ogni progetto che usa lo strumento fornisce, nel proprio repository:

1. La configurazione — conf/<progetto>.dep (bare) e/o conf/<progetto>.ddep (docker), partendo da conf/example.*.
2. I tool di progetto richiamati dalla config — tipicamente tools/testenv.php (self-test ambiente) e tools/postdeploy.sh (provisioning/azioni): sono specifici del progetto (estensioni, DBMS, cartelle scrivibili, build) e lo strumento li invoca, non li contiene.
3. (bare) i vhost nginx del progetto; (docker) Dockerfile / docker-compose.yml / entrypoint del progetto.

Regola pratica: se un file sa cos'è il progetto → sta nel repo del progetto (config e tools/…). Se è la meccanica del deploy uguale per tutti → sta qui.

Guida completa all'onboarding di un nuovo progetto — struttura delle cartelle, contratto che i tool devono rispettare, esempi e errori tipici: docs/ONBOARDING-PROGETTO.md.

---

Deploy di più progetti

Sul server, un solo deployer.sh pubblica quanti progetti vuoi. Scarica i template una volta e copiali per ciascun progetto:

cd /opt/deployer/conf
sudo wget -O example.dep \
  https://raw.githubusercontent.com/sebyone/devops-deployer/main/conf/example.dep
sudo wget -O example.ddep \
  https://raw.githubusercontent.com/sebyone/devops-deployer/main/conf/example.ddep

sudo cp example.dep  shareforces.dep     # un progetto bare
sudo cp example.ddep altroprogetto.ddep  # un progetto docker
sudo nano shareforces.dep                # REPO_SSH_URL, TARGET_PATH, STACK, POST_INSTALL…

Campi minimi:

• bare (.dep) — REPO_SSH_URL, TARGET_PATH, STACK (profilo: php-laravel, php-nginx, static-nginx, node-spring-nginx, python-nginx, none). Tutto il resto eredita i default dello stack.
• docker (.ddep) — PROJECT_ROOT, SERVICE e un COMPOSE_FILE esistente.

Poi pubblica — lo stesso comando per entrambe le modalità:

cd /opt/deployer
sudo ./deployer.sh shareforces              # deploy completo (con migrazioni)
sudo ./deployer.sh shareforces --no-db      # solo codice/asset: non tocca il DB
sudo ./deployer.sh altroprogetto            # progetto docker, stesso script
sudo ./deployer.sh altroprogetto --no-build # redeploy senza rebuild
sudo ./deployer.sh shareforces --dry-run    # mostra i passi, non cambia nulla

Se qualcosa va storto:

sudo ./deployer.sh shareforces --history    # i deploy registrati
sudo ./deployer.sh shareforces --rollback   # torna al precedente

Aggiornare lo strumento:

cd /opt/deployer && sudo ./deployer.sh --update

Parametri, passi, stack e troubleshooting: DEPLOYER.md.