Passaggio software: che cosa deve saper fare il nuovo team

Un passaggio software completo dovrebbe valutarsi dalla capacità di un altro gruppo di installare l'applicazione, apportare una modifica mirata e distribuirla in un ambiente di test. Il codice sorgente è necessario. La prova indipendente rivela se sono state trasmesse anche le conoscenze complementari.

Per il committente, la domanda concreta è quanto dipenda ancora da una persona o da un computer specifico. Un archivio scaricabile non risponde.

Un ambiente pulito rivela le lacune

In un esempio immaginario, il nuovo gruppo riceve la versione approvata R-1 di un portale ordini. Sul vecchio portatile tutto parte. Su un sistema di test pulito mancano però la versione esatta dell'ambiente di esecuzione, l'inizializzazione del database vuoto e il significato di due variabili d'ambiente. Il codice è arrivato; parte dell'installazione resta incerta.

Anche un lungo documento generale può lasciare questa lacuna. Serve una guida che permetta di seguire i passaggi realmente necessari. I principi Twelve-Factor separano configurazione variabile e codice e favoriscono ambienti di sviluppo e produzione simili. Offrono un orientamento, non un verbale completo di passaggio per ogni tecnologia.

Una piccola modifica come prova

Nell'esercizio, R-1 viene installata con dipendenze definite. Il gruppo crea un database di test vuoto, usa credenziali artificiali e completa l'ordine T-31. Le chiavi di produzione non vanno nel repository o nelle istruzioni.

Poi cambia l'etichetta «Riferimento» in «Riferimento cliente», ricostruisce l'applicazione e la distribuisce nel test. Infine ripristina la versione precedente. Il piccolo intervento verifica che installazione, modifica, distribuzione e ritorno siano compresi insieme. Non dimostra la padronanza di ogni funzione futura.

Se il gruppo precedente deve fornire passaggi mancanti, li aggiunga alla consegna e li riprovi. Una spiegazione orale risolve il momento; la lacuna è colmata stabilmente quando il sapere resta disponibile per il tentativo successivo.

Quando basta un perimetro più ristretto

Per un'estensione limitata di una piattaforma già gestita insieme, consegnare il codice modificato può essere un passo intermedio utile. Ricreare tutto l'ambiente operativo potrebbe essere sproporzionato. Devono essere chiare le conoscenze e gli accessi già presenti e chi continua a curarli.

Anche servizi simulati sono legittimi quando la prova non deve usare collegamenti reali. Indichi quale parte rimane quindi non verificata. Un pagamento simulato non dimostra un collegamento di produzione funzionante.

Per un cambio completo di gruppo, la prova indipendente è il criterio più forte. Rende visibile il lavoro restante prima che il precedente referente non sia più disponibile. Il verbale dovrebbe indicare versione utilizzata, processo completato e dipendenze aperte.

Fonti

• The Twelve-Factor App: Config

• The Twelve-Factor App: Dev/prod parity