Cosa è già implementato

L'evoluzione di Fliclic non consiste nell'aggiungere il maggior numero possibile di funzioni. Consiste nel rendere più coerenti, isolate e verificabili le attività che servono davvero a uno sviluppatore, senza trasformare proposte o test circoscritti in garanzie universali.

Questa pagina usa quattro categorie: implementato, verificato in runtime, in evoluzione e non disponibile. La distinzione vale più di una roadmap promozionale, perché permette di capire che cosa si può usare oggi e che cosa richiede ancora lavoro o decisioni.

Il codice analizzato comprende workflow per:

• creazione ed eliminazione degli ambienti;
• sospensione, riattivazione e manutenzione;
• installazione WordPress e riconfigurazione della copia;
• duplicazione di ambienti e database;
• creazione ed eliminazione di database;
• cambio versione PHP e aggiornamento dei parametri PHP/FPM;
• applicazione e aggiornamento delle quote filesystem;
• misurazione periodica di file, inode e database;
• backup HOT e STOP, con snapshot e artefatti compressi;
• cancellazione dei backup secondo stato e scadenza;
• ripristino fotografico di backup compatibili;
• gate tecnico per l'accesso web ai database;
• normalizzazione sicura dei metadata negli alberi tenant.

“Implementato” descrive il codice corrente. Non certifica da solo che ogni nodo esegua esattamente la stessa build o che ogni combinazione di dati e stato sia stata testata.

Verificato in runtime e documentato

Le evidenze conservate nel progetto includono:

• mitigazione e regressione della race filesystem che coinvolgeva symlink e operazioni privilegiate;
• creazione, installazione WordPress, duplicazione e riconfigurazione nei due ambienti documentati;
• applicazione e mantenimento di Project ID, ereditarietà e quote;
• backup HOT e STOP e leggibilità degli artefatti;
• restore fotografico con più database target, un database successivo da eliminare e credenziali cambiate nel tempo;
• benchmark delle fasi di restore e correzione dei colli di bottiglia;
• monitoraggio di un secondo tenant durante la rimozione dei reload PHP-FPM dal restore;
• connessioni TLS e privilegi limitati per gli account di automazione del database centrale.

Queste prove hanno ambiente, build e perimetro. Non dimostrano automaticamente tutti i CMS, ogni stato precedente, ogni nodo, un'interruzione di corrente reale o qualsiasi combinazione di motore SQL e applicazione.