Consegnare il software esistente a un nuovo team
Verifichi il passaggio di consegne, dalla versione del codice sorgente chiaramente identificata fino a una piccola modifica reversibile nell’ambiente di test.
Lasci che il nuovo team segua il percorso
Il passaggio diventa concreto quando il nuovo team sa preparare l’applicazione con propri account autorizzati e verificare una modifica concordata. Un archivio sorgente e una dimostrazione del team precedente non forniscono ancora tutte le prove.
Colleghi prima la versione in uso a una revisione sorgente identificata. Registri file necessari, dipendenze, versioni degli strumenti e percorso verso un risultato eseguibile. SLSA distingue sorgenti, altri input, build e artefatti distribuiti. Il nuovo team può così ricostruire quali input hanno prodotto la versione consegnata.
Esempio: una modifica di testo dall’avvio al ripristino
Lo scenario è inventato. Un modulo di assistenza viene consegnato alla versione v2.3.0. Il nuovo team deve precisare l’aiuto «Nota di consegna» in «Accesso e consegna». Campi dati e schema del database restano invariati nell’esempio. La tabella descrive riscontri attesi, non un test eseguito.
Passo | Attività concordata | Riscontro atteso |
|---|---|---|
Accedere ai sorgenti | Recuperare revisione documentata e file aggiuntivi con proprio account autorizzato. | La revisione consegnata è identificata; sono accessibili anche pacchetti privati e contenuti aggiuntivi necessari del repository. |
Preparare l’ambiente | Seguire istruzioni di runtime, installazione pacchetti e configurazione di prova. | L’applicazione di test parte senza accessi di produzione o file privati del precedente sviluppatore. |
Verificare una piccola modifica | Cambiare l’aiuto e percorrere il salvataggio esistente con dati sintetici. | Appare il nuovo testo; il salvataggio concordato continua a funzionare. |
Annullare la modifica | Annullare la modifica di testo in prova e seguire l’avvio documentato. | Tornano testo originale e flusso del modulo già verificato. |
L’ultima riga dimostra solo il ritorno per quella modifica. Ripristino del database o passaggio in produzione richiedono verifiche proprie adeguate.
Aggiunga gestione operativa e punti aperti
Documenti nomi di configurazione, percorsi sicuri per ottenere segreti, fonti di pacchetti privati e configurazione di build, compreso un lockfile adatto. I veri segreti non vanno nell’archivio sorgente. Verifichi anche grandi file separati e repository incorporati, se usati.
Chiarisca accessi e responsabilità per rilascio, monitoraggio, backup e guasti. Il trasferimento di un repository GitHub conserva associazioni come webhook, segreti e chiavi di rilascio. Verifichi espressamente quali collegamenti e accessi devono restare. Il trasferimento non li rimuove da solo.
Se un passo fallisce, registri requisito mancante, ruolo responsabile e prossimo riscontro. Separi punti aperti e risultati dimostrati. Concordi quando il nuovo team assume ogni attività e chi resta disponibile fino ad allora.
Fonti
Scritto da
- Katharina WeberRedattrice per software e tecnologiaKatharina Weber cura per ASES gli articoli sullo sviluppo software. Scrive delle questioni che le aziende affrontano nella scelta del software, nello sviluppo di nuove applicazioni e nella modernizzazione dei sistemi esistenti.
Continuate a leggere
Tutti gli articoli
Sviluppo software con ASES
Software su misura, app web e mobile