Parte 12

Ricostruite il vostro ambiente, non la vostra memoria

L’automazione più preziosa non è sempre una mansione di applicativa. A volte è la capacità di arrivare su un nuovo account hosting, posare un piccolo Core, eseguire una ricetta esplicita e recuperare strumenti e abitudini di cui vi fidate.

Il vostro ambiente è una ricetta più stato

Moduli installati, pacchetti d’interfaccia, startup script e preferenze descrivono come si comporta il terminale. File del progetto e database sono un altro livello di stato. Separare queste idee rende migration e recupero molto più semplici.

Scrivete che cosa deve essere ricreato automaticamente e che cosa deve essere ripristinato da un backup. Una ricetta di installazione descrive strumenti e valori predefiniti sicuri; non deve trascinare dati applicativi o credenziali su un nuovo host.

Prima della ricetta, ispezionate l’ambiente che usate già

core dà il quadro compatto Core/UI/moduli, install -l elenca moduli e pacchetti installati, include mostra lo storage dei pacchetti d’interfaccia e upgrade -c controlla le versioni senza scrivere.

Questo inventario separa «credo di aver bisogno di questi strumenti» da una distinta davvero riproducibile. Eliminate le abitudini obsolete prima di fissarle nell’automazione dell’installazione.

core

install -l

include

upgrade -c

`setup.lil` è un bootstrap una tantum, non uno startup script permanente

Il Core attuale nota un normale setup.lil accanto a lil.php, lo esegue dopo l’autorizzazione quando necessario e lo rimuove solo dopo il successo di tutti gli statement. Se manca Installer completo, Core può scaricarlo e riprendere l’operazione install originale.

Mantenete esplicita la preparazione dell’ambiente. Un’installazione multipla con install resta compatta e leggibile; una versione esatta con -v è utile quando volete riprodurre intenzionalmente una configurazione precisa. Non inserite in questo file password, chiavi private o credenziali di database specifiche del progetto.

install help history upgrade dir pwd md mf edit find stat hash run

`autoload.lil` serve a piccole azioni ricorrenti all’inizio della sessione

run controlla autoload.lil una volta per sessione autorizzata e non lo rimuove. È adatto a controlli leggeri o alla preparazione dell’ambiente che devono ripetersi, non a un’installazione una tantum.

upgrade -auto check è un buon esempio: gestisce un piccolo blocco in autoload.lil e controlla gli aggiornamenti una volta per sessione. L’aggiornamento automatico è una scelta più incisiva e resta facoltativo; negli ambienti importanti è spesso meglio controllare, revisionare e solo dopo aggiornare.

upgrade -auto check

upgrade -info

Riproducibilità significa sapere quale libertà avete scelto

install <mod> seleziona la versione pubblica compatibile corrente; install <mod> -v <ver> richiede uno specifico numero pubblicato. Entrambe le forme rispettano la generazione Core attiva e le dipendenze del modulo.

Le precedenti tappe della generazione 1 restano nella cronologia solo come riferimento e non sono più destinazioni di installazione. La versione supportata è quella corrente. Dal prossimo rilascio, le versioni numerate saranno mantenute come destinazioni esatte finché un rilascio non verrà esplicitamente ritirato.

install hash -i

install hash -v 1.1.3

L’interfaccia del browser è un livello di pacchetti, non l’ambiente di esecuzione dei comandi

include gestisce pacchetti CSS/JavaScript componibili come lil, hotkeys e code. La modalità di sessione è temporanea; -s crea composizione persistente in .lil.css e .lil.js.

La separazione è utile quando cambiate host: i moduli PHP possono essere corretti anche se manca il vostro UI package preferito. Ricostruite prima la funzionalità, poi la presentazione. Se l’interface livello si confonde, kill -include resetta quel livello senza eliminare Core.

include -l

include lil -i

include -lil -s

Una ricetta di installazione è completa solo dopo un test in un ambiente usa e getta

La prova migliore è una clean installation: distribuite un Core nuovo, eseguite la ricetta e confrontate core, install -l e upgrade -c con l’ambiente che volevate riprodurre.

Il test scopre dipendenze invisibili: un comando installato a mano mesi fa, un pacchetto interfaccia dimenticato o un’estensione disponibile su un host e non su un altro. La riproducibilità si scopre ricostruendo, non dichiarandola.