Procedura - Change e release del servizio

Scopo

Definire le modalità minime con cui Flowvenue introduce modifiche controllate a codice, configurazioni, dipendenze e pipeline che concorrono all’erogazione del servizio su cloud (inclusi ambienti di sviluppo, collaudo e produzione), e come si gestiscono rilasci ed emergency change, in coerenza con il modello operativo reale (repository Git, revisione tra pari, CI/CD verso AWS).

La procedura non sostituisce impegni contrattuali specifici con un singolo cliente (es. finestre di deploy, approvazioni aggiuntive): in tali casi prevale quanto concordato per iscritto.

Perimetro

• Applicativo Flowvenue, servizi ausiliari nel perimetro di erogazione, infrastruttura come codice o parametri di deploy ove gestiti dal team prodotto.
• Esclusi dalla disciplina “change/release” di questa procedura: solo aggiornamenti di contenuto commerciale/marketing che non modificano logica applicativa, configurazioni di sicurezza né pipeline (gestiti secondo processi interni dedicati).

Ruoli (funzioni, non nominativi)

Ruolo	Responsabilità tipica
Richiedente / autore change	Propone la modifica, descrive impatto e rischi noti, mantiene la PR.
Reviewer	Esegue revisione tecnica; può richiedere evidenze (test, screenshot, note).
Approvatore merge	Autorizza l’ingresso nel ramo protetto (merge), in linea con regole del repository.
Owner rilascio in produzione (ove distinto)	Valida il momento del deploy in produzione e la presenza di note di rilascio per cambiamenti rilevanti.

I nominativi e la distribuzione effettiva sono definiti nella governance interna e possono essere condivisi in due diligence su richiesta formale.

Change standard (flusso ordinario)

1. Proposta: branch dedicata e pull request (PR) verso il ramo integrazione / release concordato nel repository.
2. Revisione: almeno un reviewer (due ove richiesto dalle regole del repo) verifica correttezza, regressioni ovvie, impatti su sicurezza e osservabilità.
3. Controlli automatici: esecuzione dei workflow di CI previsti (build, test, lint, scan ove attivi) prima del merge.
4. Approvazione: merge solo se i controlli obbligatori sono superati e le eventuali condizioni del branch (approvazioni, conversazioni risolte) sono soddisfatte.
5. Deploy: promozione verso collaudo e produzione solo tramite pipeline autorizzata (nessun deploy manuale non tracciato in produzione salvo emergency di cui sotto).
6. Tracciabilità: la PR, i commit e l’esito della pipeline costituiscono la prova del change approvato.

Release e deployment

• Per rilasci significativi (nuove capacità, correzioni strutturali, modifiche a dipendenze critiche): predisporre note di rilascio sintetiche (changelog, descrizione in PR o documento collegato) accessibili al team e, ove utile, al cliente secondo accordi commerciali.
• Tag o identificatori di versione: usare la convenzione del repository (es. versione semantica o tag di deploy) per correlare artefatto e ambiente.
• Rollback: in caso di errore post-deploy, ripristinare la revisione precedente nota funzionante tramite la stessa catena di pipeline o meccanismo equivalente documentato internamente; registrare l’intervento nel sistema di tracking usato per l’incidente di servizio.

Emergency change (eccezione controllata)

Si parla di emergency change quando è necessario intervenire urgentemente per sicurezza (es. vulnerabilità sfruttabile), continuità gravemente compromessa o obblighi normativi immediati, e il flusso PR completo introdurrebbe ritardo ingiustificato.

1. Autorizzazione: un membro con competenza tecnica e uno con responsabilità di prodotto/sicurezza (possono coincidere in organizzazioni ridotte) concordano l’intervento per canale tracciabile (es. ticket, email aziendale, strumento di chat aziendale con storico).
2. Esecuzione: applicazione della modifica con il mezzo più rapido ancora auditabile (commit diretto o PR “fast-track” con merge immediato dopo verifica minima).
3. Retroazione documentale: entro 1 giorno lavorativo (o prima se possibile): descrizione sintetica del motivo, dell’intervento e dell’esito; apertura PR di chiusura o aggiornamento note se il codice non è già passato per review completa.
4. Post-mortem leggero: per interventi su produzione, valutare una retrospettiva sintetica in tracking interno.

Cosa resta fuori da questa scheda (riferimenti)

• Incidenti di sicurezza e data breach: Procedura - Incident response, Procedura - Data breach e notifica.
• Configurazione sicura e hardening: Procedura - Configurazione sicura e hardening.
• Valutazione fornitori / componenti: Procedura - Vendor due diligence e ciclo ISMS ove applicabile.

Output attesi

• PR approvate e merge tracciati; esiti pipeline conservati secondo policy di retention dello strumento.
• Note di rilascio per cambiamenti rilevanti.
• Per emergency: traccia di autorizzazione e retro-documentazione entro i tempi sopra.

Riesame

La procedura è riesaminata almeno annualmente o quando cambiano in modo rilevante strumenti (CI, cloud, branching) o il modello di servizio.

Ultimo aggiornamento: Aprile 2026