Una pipeline di integrazione continua (CI) deve rispondere a una domanda concreta: questa modifica può essere integrata nella codebase condivisa senza introdurre difetti noti né violare i requisiti concordati? Per rispondere, è opportuno definire verifiche ripetibili, ordinarne l’esecuzione e fare in modo che ogni errore fornisca informazioni utili.
CI non significa distribuire automaticamente ogni modifica. È la pratica di integrare frequentemente le modifiche e convalidarle in modo automatizzato. La continuous delivery prepara in modo continuativo una release distribuibile; il continuous deployment aggiunge la pubblicazione automatica in produzione quando sono soddisfatte le condizioni stabilite. Un’applicazione può adottare CI senza automatizzare la delivery, oppure automatizzarla fino a un ambiente di test mantenendo un’approvazione prima della produzione.
Definisci il contratto della pipeline
Prima di scegliere gli strumenti, specifica che cosa riceve l’esecuzione, che cosa deve produrre e quali condizioni la fanno fallire. Una configurazione utile documenta almeno:
- Input: la modifica da convalidare, la configurazione pertinente e le dipendenze dichiarate dal progetto.
- Ambiente: sistema e requisiti di esecuzione, configurazione di PHP e servizi necessari per i test. Deve essere sufficientemente simile tra un’esecuzione e l’altra affinché i risultati siano confrontabili.
- Risultato: stato finale, report di test e analisi e, se pertinente, un artefatto identificabile che possa essere convalidato in seguito.
- Condizioni di errore: quali errori bloccano l’integrazione, quali generano avvisi e chi può accettare un’eccezione temporanea.
L’installazione deve partire dalla configurazione delle dipendenze versionata e rispettare il lockfile, anziché risolvere silenziosamente nuove versioni a ogni esecuzione. In questo modo si riduce una fonte di differenze tra gli sviluppatori e CI. È inoltre necessario dichiarare i requisiti di piattaforma e le estensioni previste dall’applicazione, verificando che l’ambiente di esecuzione li soddisfi.
Evita che la pipeline dipenda da file locali, servizi personali o passaggi manuali non documentati. Se una verifica richiede un database, una cache o un altro servizio, definisci come avviarlo, quali dati richiede e come ripulirlo. Il contratto non deve necessariamente riprodurre interamente la produzione, ma deve rendere esplicite le differenze che possono influire sul risultato.
Ordina le verifiche in base al costo e alla capacità di rilevamento
Una sequenza pratica inizia con le convalide rapide e termina con quelle che richiedono più tempo o infrastruttura. La priorità non è accumulare attività, ma rilevare i problemi il prima possibile senza perdere una copertura significativa.
- Installazione riproducibile: risolvi le dipendenze a partire dalla definizione e dal lockfile del progetto. Se questa fase fallisce, il resto dei risultati non è affidabile.
- Formattazione e convenzioni: verifica le regole di formattazione o di stile concordate. Questi controlli sono rapidi e impediscono che differenze di presentazione arrivino a una revisione più costosa.
- Analisi statica: individua incompatibilità ed errori rilevabili senza eseguire tutti i flussi dell’applicazione. Adegua le regole al codice e alla configurazione effettiva del progetto.
- Test: esegui prima i test unitari e aggiungi test di integrazione o end-to-end in base al rischio coperto e ai servizi necessari.
- Convalida dell’artefatto: verifica che il pacchetto o l’immagine generati contengano tutto il necessario per l’esecuzione ed escludano file di sviluppo, dati locali e segreti.
Non tutte le applicazioni richiedono gli stessi test né lo stesso ordine. Se un’analisi statica richiede molto più tempo di un piccolo test unitario, può essere opportuno eseguire entrambe le verifiche in parallelo dopo l’installazione delle dipendenze. Anche le attività indipendenti possono essere eseguite in parallelo per ridurre i tempi di attesa, purché condividano una base riproducibile e i relativi risultati siano associati alla stessa modifica.
Al contrario, non è opportuno parallelizzare alla cieca passaggi che modificano la stessa directory o dipendono da risultati precedenti. Separa la preparazione comune dalle attività successive, limita la concorrenza dei servizi condivisi e rendi chiare le dipendenze tra le fasi. L’obiettivo è accelerare il feedback senza rendere imprevedibile la pipeline.
Decidi cosa blocca e cosa viene eseguito in seguito
Come regola iniziale, blocca l’integrazione quando fallisce una verifica rilevante per la sicurezza della modifica: installazione, analisi concordata, test richiesti o convalida del pacchetto. Un’attività informativa — per esempio, una verifica ancora in fase di valutazione — può segnalare i risultati senza bloccare per un periodo definito. Deve avere un responsabile, una data di revisione e un criterio per diventare obbligatoria; altrimenti, gli avvisi diventano permanenti e perdono valore.
Le verifiche rapide dovrebbero fornire feedback tempestivo a ogni modifica. I test costosi possono essere eseguiti in parallelo, in una fase successiva o con una frequenza diversa se i tempi o l’infrastruttura lo giustificano. Tuttavia, riservare tutta la convalida importante al periodo successivo all’integrazione lascia una finestra in cui le modifiche non sono state verificate. Definisci cosa è richiesto prima dell’integrazione e cosa resta come convalida aggiuntiva, considerando l’impatto di un errore rilevato in ritardo.
Un’esecuzione riuscita non equivale a un deploy approvato. CI verifica la modifica e può generare un artefatto; il processo di delivery decide come promuoverlo, verso quale ambiente e con quali controlli. Mantenere esplicito questo confine evita che un’attività di convalida pubblichi accidentalmente in produzione. Se è previsto il deploy automatico, definisci separatamente le condizioni, le approvazioni, la strategia di rollout e il meccanismo di rollback.
Proteggi la configurazione e i segreti
I segreti non devono essere inseriti nel repository, nei file di configurazione di esempio né nei report delle esecuzioni. Usa il meccanismo di gestione dei segreti dell’ambiente CI, limita la loro disponibilità alle sole attività che ne hanno bisogno ed evita di concedere credenziali di produzione a verifiche che richiedono soltanto servizi isolati.
Controlla anche i log: un’eccezione, un test fallito o un comando diagnostico possono stampare variabili sensibili. Mascherare i valori è utile, ma non sostituisce la prevenzione della loro scrittura nei log. Usa dati di test che non espongano informazioni reali e definisci una procedura per revocare le credenziali se compaiono in un log o in un artefatto.
Rendi diagnosticabili gli errori
Uno stato rosso senza contesto costringe a ripetere il lavoro e trasforma CI in una scatola nera. Conserva i report di test e analisi, l’output necessario per identificare il passaggio fallito e gli identificativi delle versioni delle dipendenze o dell’artefatto. Evita invece di registrare dati personali, segreti o dump indiscriminati dell’ambiente.
Quando un test fallisce in modo intermittente, non contrassegnarlo come riuscito riprovandolo senza limiti. Registra quali test sono instabili, con quale frequenza e in quali condizioni; indaga su cause come concorrenza, dipendenze esterne, stato condiviso o timeout. Se un test instabile viene temporaneamente isolato, documenta il rischio, assegna un responsabile e fissa una data per ripristinarne la funzione di blocco.
È inoltre opportuno distinguere un errore del codice da un problema infrastrutturale. Segnala se non è stato possibile avviare servizi, recuperare dipendenze o completare un’attività per mancanza di risorse. Un nuovo tentativo può essere ragionevole in caso di interruzione transitoria, ma deve essere limitato e visibile; nascondere il primo errore rende più difficile rilevare i problemi ricorrenti.
Adatta CI a un’applicazione legacy
In un sistema datato, attivare di colpo regole rigorose può bloccare modifiche utili e incoraggiare eccezioni incontrollate. Inizia con una baseline: identifica quali test superano l’esecuzione oggi, quali errori preesistenti segnala l’analisi e quanto dura ogni fase. Non presentare come regressione un problema già esistente, ma non permettere nemmeno che la baseline diventi una scusa a tempo indeterminato.
- Rendi obbligatorie per prime le verifiche riproducibili e già stabili, come l’installazione e un insieme affidabile di test.
- Registra i problemi esistenti e richiedi che le nuove modifiche non li aggravino, se lo strumento e il progetto consentono questo confronto.
- Aggiungi test nelle aree a maggior rischio di modifica e amplia gradualmente la copertura.
- Riduci le eccezioni con modifiche piccole e facili da revisionare; assegna un responsabile e una data a ogni eccezione temporanea.
- Misura i tempi e le cause degli errori per ottimizzare fasi specifiche, invece di eliminare convalide senza sapere quale rischio coprissero.
Una buona integrazione continua in PHP non si definisce dal numero di fasi, ma da risultati riproducibili e comprensibili. Se il team sa spiegare cosa convalida ogni passaggio, cosa blocca l’integrazione e come indagare un errore, la pipeline aiuta a decidere sulla base di evidenze quando una modifica è pronta per avanzare.
